similar to: commit 0a1479c829 breaks glsl-fs-lots-of-tex.shader_test on nv50/nvc0

Tested with: MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5 ./shader_runner ../tests/spec/arb_gpu_shader5/execution/built-in-functions/fs-bitfieldReverse.shader_test -> green output, so this should be ok the test was not change though... On 29.05.2014 21:47, Ilia Mirkin wrote: > Can you verify that you tested how the HW handles this, as well as > exactly how you did it (i.e. how did you

Hi Christoph, bin/shader_runner tests/spec/glsl-1.40/uniform_buffer/fs-struct-copy-complicated.shader_test -auto bin/shader_runner tests/spec/glsl-1.40/uniform_buffer/vs-struct-copy-complicated.shader_test -auto bin/shader_runner tests/spec/glsl-1.50/uniform_buffer/gs-struct-copy-complicated.shader_test -auto Now all segfault. I reverted 2e9ee44797 ("nv50/ir/ra: some register spilling

https://bugs.freedesktop.org/show_bug.cgi?id=68344 Priority: medium Bug ID: 68344 Assignee: nouveau at lists.freedesktop.org Summary: [piglit] shaders/glsl-fs-texture2d-dependent-4 randomly passes or fails on NVAA/NV50 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified

Hello, I've been debugging a few different tessellation shader issues with nouveau, but let's start small. I see this issue on my GK208 with high frequency, and I *think* I've seen it once or twice on my GF108, but it's exceedingly rare, if it does happen. I don't have a GK10x to test on, unfortunately, but I assume it'll have the same issue as the GK208. The issue is

https://bugs.freedesktop.org/show_bug.cgi?id=68348 Priority: medium Bug ID: 68348 Assignee: nouveau at lists.freedesktop.org Summary: [piglit] shaders/glsl-array-bounds-02 (+even nrs) produces TRAP , TRAP_MP - TP0: Unhandled ustatus 0x00000001 QA Contact: xorg-team at lists.x.org Severity: normal

One additional observation that I just made is that on GK208, the blob apparently doesn't use the result of S2R Rx, SR_INVOCATION_ID wholesale in TCS. It either passes it through a I2I.S32.S32 Rx, |Rx| (i.e. absolute value), or even more paradoxically, shl 2; shr 2; which removes the top *2* bits, rather than just the top 1. However I see no such behaviour on GF108. I'm going to test out

https://bugs.freedesktop.org/show_bug.cgi?id=111167 Bug ID: 111167 Summary: Dividing zero by a uniform in loop header causes segfault in nv50_ir::NVC0LegalizeSSA::handleDIV Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor

On 27.05.2015 18:28, Marek Olšák wrote: > Another thing to consider is linking shaders that occur before the > rasterizer (e.g. any two shaders from VS->TCS->TES->GS). The maximum > number of written distances is still 8, but what happens if VS writes > 1x clip and 7x cull and GS reads 8x clip and no cull? i think this should be rejected anyway (in the glsl?!), constraining

On Mon, May 25, 2015 at 9:40 AM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > On 25.05.2015 07:17, Dave Airlie wrote: >> >> On 25 May 2015 at 08:11, Marek Olšák <maraeo at gmail.com> wrote: >>> >>> It's the same on Radeon. There are 2x ClipOrCullDistance output >>> vectors and a mask saying it should clip or cull

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp index 58092f4..93f7c2a 100644 ---

On Sat, Dec 19, 2015 at 1:53 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > These are supported on GK20A and GM107. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > > Was a bit torn on where to place the enums... we're about to gut all > the xml definitions so this seemed appropriate for now. > > Tested on GK20A only. > >

This commit adds support for dadd with an immediate src in gk110 code. The machine-code in question is generated by e.g. nouveau_compiler with the new "Make use of double immediates" patch series when building the piglit glsl-algebraic-double-add.shader_test. This commit changes the output from: 00000010: 001c0001 c38001ff $r0 $r0 $r0 $r0 0x3fe00 0x3fe00 0x3fe0000000000000

https://bugs.freedesktop.org/show_bug.cgi?id=66642 Priority: medium Bug ID: 66642 Assignee: nouveau at lists.freedesktop.org Summary: [nva5] Wrong provoking vertex is selected for flat attribute interpolation (clipping?) Severity: normal Classification: Unclassified OS: Linux (All) Reporter:

These are supported on GK20A and GM107. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Was a bit torn on where to place the enums... we're about to gut all the xml definitions so this seemed appropriate for now. Tested on GK20A only. src/gallium/drivers/nouveau/nv50/nv50_formats.c | 64 +++++++++++++++++++++++++ src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 ++++

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- .../drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp index f010767..4a9e48f 100644 ---

In certain circumstances, findFirstUses could end up doubling back on instructions it had already processed, resulting in an infinite recursion. Avoid this by keeping track of already-visited instructions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83079 Tested-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> Signed-off-by: Ilia Mirkin <imirkin at

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- This fixes the bin/fs-textureOffset-2D piglit test on nv50. Have yet to re-run the full piglit suite with this change in place, but it seems pretty obvious. src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp

So I figured out what was going on. The shader has a UMAD TEMP[0].x, TEMP[0].xxxx, -TEMP[5].xxxx, TEMP[0].xxxx instruction, in which the -TEMP[5].xxxx got emitted as cvt neg u32 $r1 u32 $r1 If instead I fudge mkOp() to force a s32 dtype on OP_NEG, everything starts to work. Similarly, if I fudge emitCVT to basically do the same thing, it also works. (Of note -- changing both stype and dtype to

From: Ben Skeggs <bskeggs at redhat.com> We've previously had identical naming between vertex and texture formats, so it mostly made sense to define these together. However, upcoming patches are going to transition the driver over to using updated texture header definitions using NVIDIA's naming, and this will no longer be the case. Signed-off-by: Ben Skeggs <bskeggs at

Hi, guys: I’m a developer of FydeOS. We porting ChromiumOS to amd64 and arm platforms. Now, I’m woking on porting android environment to Nvidia graphic cards. I have experience to port android to Vmware(SVGA). I found two display formats were not supported to display in nouveau driver: PIPE_FORMAT_R8G8B8A8_UNORM, PIPE_FORMAT_R8G8B8X8_UNORM. Which are defined at nv50/nv50_formats.c line: 130,131.