similar to: [RFC PATCH] nv50: adjust blit_3d logic

This fixes some unwanted scaling when the output is multisampled. Also increases nvc0 maximum supported texture size to be able to work with a 32k texture. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.0 10.1" <mesa-stable at lists.freedesktop.org> --- Ran the EXT_framebuffer_multisample tests, they improve a lot. The remaining failures are probably due to

Make sure to normalize the z coordinates as well as the x/y ones when there are mipmaps present. Fixes 3d mipmap generation, which now uses the blit path. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedesktop.org> --- Did a full piglit run on nva8 and nve7 without regressions. The cubemap array mipmap generation test still fails,

On 17/01/14 02:23, Ilia Mirkin wrote: > Fixes fbo-drawbuffers-none glClearBuffer piglit test. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > > Only tested on nv50, but implementations seem similar enough. > > src/gallium/drivers/nouveau/nv50/nv50_surface.c | 17 +++++++++-------- > src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 17

On 23/01/14 20:15, Ilia Mirkin wrote: > On Thu, Jan 23, 2014 at 3:11 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: >> On 17/01/14 02:23, Ilia Mirkin wrote: >>> Fixes fbo-drawbuffers-none glClearBuffer piglit test. >>> >>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> >>> --- >>> >>> Only tested on nv50, but

Fixes fbo-drawbuffers-none glClearBuffer piglit test. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Only tested on nv50, but implementations seem similar enough. src/gallium/drivers/nouveau/nv50/nv50_surface.c | 17 +++++++++-------- src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 17 +++++++++-------- 2 files changed, 18 insertions(+), 16 deletions(-) diff --git

On Thu, Jan 23, 2014 at 3:11 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: > On 17/01/14 02:23, Ilia Mirkin wrote: >> Fixes fbo-drawbuffers-none glClearBuffer piglit test. >> >> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> >> --- >> >> Only tested on nv50, but implementations seem similar enough. >> >>

The 2D engine should be usable in more cases, but this fixes MS blits between textures with the same MS settings. Otherwise a single sample is selected to be the target texel value. This allows other tests to work that render to a RB and then blit that to a texture for input into a shader that uses sampler2DMS to verify it. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> ---

--- This is still a WIP. Just wanted to get people's opinions. It's also not bullet-proof. Unfortunately nouveau_bo_wait [which is in turn called by nouveau_bo_map] can trigger a kick, so technically we have to have a lock around any nouveau_bo_map. My strategy here was to add locks around all the user-accessible APIs while leaving all the internal stuff unlocked. When waiting for a

Unfortunately there's only one RT_ARRAY_MODE setting for all attachments, so clears were previously truncated to the minimum number of layers any attachment had. Instead set the RT_ARRAY_MODE to 512 (the max number of layers) before doing the clear. This fixes gl-3.2-layered-rendering-clear-color-mismatched-layer-count. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> ---

Different textures may be bound to each slot for each stage. So we need to be able to upload ms parameters for each one without stages overwriting each other. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.1 10.2" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp | 4 ++++

May I ask why you're doing 512x512 instead of 1024x1024? These are already scaled up coordinates, so 1024x1024 should work no? Or is it because of the seams on the edges? Do those not also appear with 512x512 or does it sample outside of the box? Separately, why not use this approach on nv40 as well? I can't imagine the blitter would be faster... does this result in lower quality? On

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- docs/GL3.txt | 2 +- docs/relnotes/10.4.html | 1 + src/gallium/drivers/nouveau/nv50/nv50_context.h | 3 +- src/gallium/drivers/nouveau/nv50/nv50_query.c | 56 +++++++++++++++++++++---- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-

As I mentioned on IRC, I think that some color formats are compressible. Would be nice to figure out which... e.g. trace the blob, or just try stuff. On Thu, Jan 1, 2015 at 9:56 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > We enable compression only for some supported formats > > Suggested-by: Ilia Mirkin <imirkin at alum.mit.edu> >

rendercheck -f a8r8g8b8 passes as much as on a GK208, and xv appears to work. Very lightly tested. Instead of sticking coordinates into pushbufs, the vertex shader is modified to read them from a constbuf, indexed by vertex id. This approach could be used for all nvc0 generations, but I didn't want to rock the boat. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> ---

Looks reasonable, some minor comments below. On 10/16/2016 02:06 AM, Ilia Mirkin wrote: > rendercheck -f a8r8g8b8 passes as much as on a GK208, and xv appears to > work. Very lightly tested. > > Instead of sticking coordinates into pushbufs, the vertex shader is > modified to read them from a constbuf, indexed by vertex id. This > approach could be used for all nvc0 generations,

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/nvc0/nvc0_context.h | 7 +- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 20 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 3 + src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 27 +++--

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/nvc0/nvc0_context.h | 7 +- src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 +- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 20 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_screen.h | 3 + src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 27 ++++-

rendercheck -f a8r8g8b8 passes as much as on a GK208, and xv appears to work. Very lightly tested. Instead of sticking coordinates into pushbufs, the vertex shader is modified to read them from a constbuf, indexed by vertex id. This approach could be used for all nvc0 generations, but I didn't want to rock the boat. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Note: this

We do not have a generic blitter on nv3x cards, so we must use the sifm object for color resolving. This commit divides the sources and dest surfaces in to tiles which match the constraints of the sifm object, so that color resolving will work properly on nv3x cards. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -Use 1024x1024 blocks -Use the sifm on both nv3x

We enable compression only for some supported formats Suggested-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 23 +++++++++++++++++++++-- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 7 +++++++ 2 files changed, 28 insertions(+), 2 deletions(-) diff --git