similar to: [PATCH] nv50: use 2d blit when src/dst have same number of samples

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

--- So... this fixes a whole bunch of EXT_framebuffer_multisample tests, and the ones that still fail appear to do so due to some resolve error, rather than some "this is the wrong image" type errors. Perhaps it needs a 2d-style "move coordinates over a sub-texel" logic. But I'm unclear what these vertices are, I arrived at this through trial-and-error.

On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > > On 28-08-15 11:02, Ilia Mirkin wrote: >> >> On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdegoede at redhat.com> >> wrote: >>> >>> Hi, >>> >>> On 27-08-15 20:19, Ilia Mirkin wrote: >>>> >>>>

On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi Ilia > > On 31-08-15 18:30, Ilia Mirkin wrote: >> >> On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede at redhat.com> >> wrote: > > > <snip> > > >>> Interestingly enough nv30_screen_get_param returns 0 for >>>

Need to adjust coordinates since the shader receives the array index as depth in z, but the TEX instruction expects it to be the second coordinate for a 1D array texture. This fixes fbo-generatemipmap-array. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_surface.c | 6 ++++++ 1

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

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

On 03.01.2015 00:20, Ilia Mirkin wrote: > On Fri, Jan 2, 2015 at 6:09 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> >> Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> >> ---

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 | 4 ++-- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 11 +++++++++-- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git

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> >

On Fri, Jan 2, 2015 at 6:09 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> > Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> > --- > src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 23

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,

This has two purposes : - cleaner code - reduce the diff between nv30 and nv40 exa for a possible nvfx_exa merge ? The main differences seem to be that nv30 uses rect texture format (and does not support repeat on that). Then there are some minor changes in TX_FORMAT RT_FORMAT and TEX_FILTER usage. And NVAccelInitNVx0TCL look complete different. Tested with: ./rendercheck -t

OK, so there's a bunch of stuff in here. The geometry stuff is based on the work started by Bryan Cain and Christoph Bumiller. Patches 01-12: Add support for geometry shaders and fix related issues Patches 13-14: Make it possible for fb clears to operate on texture attachments with an explicit layer set (as is allowed in gl 3.2). Patches 15-17: Make ARB_texture_multisample work

https://bugs.freedesktop.org/show_bug.cgi?id=91756 Bug ID: 91756 Summary: glean test vertProg1 segfaulting X server in exaHWCopyNtoN Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal Priority: medium Component:

There were reports of issues with gallium-nine. It's unclear whether mesa/st uses these, the patches did not produce any piglit changes. However they seem right... Ilia Mirkin (2): nv50,nvc0: add missing depth/stencil formats to tile flag selection nv50,nvc0: fix 3d blit logic for odd depth/stencil formats src/gallium/drivers/nouveau/nv50/nv50_blit.h | 21 ++++++++++++++-------

The nvc0 texfetch instruction expects the sample id to be in the second source (usually used for the offset) rather than as part of the texture coordinate. This fixes all the sampler2DMS/Array tests on nvc0. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.1" <mesa-stable at lists.freedesktop.org> --- Tested on nvc1 with a full piglit run, no regressions,

Add 3d resource parameters to virtio_gpu_object_params struct and use it for virtio_gpu_cmd_resource_create_3d() calls. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 10 +++++++++- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 25 ++++++++++--------------- drivers/gpu/drm/virtio/virtgpu_vq.c | 16 +++++++++++++--- 3 files changed, 32

Add 3d resource parameters to virtio_gpu_object_params struct. With that in place we can use it for virtio_gpu_cmd_resource_create_3d() calls. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Noralf Tr?nnes <noralf at tronnes.org> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 10 +++++++++- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 25 ++++++++++---------------

This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers as specified by glDrawBuffers). This implementation is highly based on a larger commit by Christoph Bumiller <e0425955 at student.tuwien.ac.at> in his gallium-nine branch. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nv50/nv50_defs.xml.h | 1 +