similar to: [PATCH] nv50/ir: (trivial) initialize pointer to silence warning

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 27 ++++++++++++++++++++-- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h

previously, if we had something like: gl_ViewportIndex = idx; for(int i = 0; i < gl_in.length(); i++) { gl_Position = gl_in[i].gl_Position; EmitVertex(); } EndPrimitive(); we failed to set the right ViewportIndex. To resolve this, save the ViewportIndex and store it to the right register on each emit. This fixes the remaining piglit tests in ARB_viewport_array for nvc0. Note: Not

previously, if we had something like: gl_ViewportIndex = idx; for(int i = 0; i < gl_in.length(); i++) { gl_Position = gl_in[i].gl_Position; EmitVertex(); } EndPrimitive(); we failed to set the right ViewportIndex. To resolve this, save the ViewportIndex and store it to the right register on each emit. This fixes the remaining piglit tests in ARB_viewport_array for nvc0. Note: Not

Printing without this could lead to the following output, while the values are not exactly zero: IMM[5] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} IMM[6] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} IMM[7] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} when printing the values as hex, we can now see the differences: IMM[5] FLT32 {0x00000019, 0x0000000f, 0x00000005,

Hi, yeah in the long run showing both in an ordered manner would be a nice thing to have! That would include patching the output and the tgsi parser (who wants to delete half the output to parse it again e.g. with nouveau_compiler). I can image an output similar to the one below: IMM[5] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} ^ IMM[5] FLT32 {0x00000019, 0x0000000f, 0x00000005,

On 24.05.2015 20:25, Ilia Mirkin wrote: > I'm having a bit of trouble tracing through this. What happens if I > have a shader that just does: > > gl_ClipDistance[0] = 1; > gl_CullDistance[0] = 1; > > what does the resulting TGSI look like? (Assuming that clip plane 0 is > enabled.) What about the generated nvc0 code (for the vertex shader)? (hack up a patch for this,

On 24.05.2015 21:36, Ilia Mirkin wrote: > On Sun, May 24, 2015 at 3:30 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 24.05.2015 20:25, Ilia Mirkin wrote: >>> I'm having a bit of trouble tracing through this. What happens if I >>> have a shader that just does: >>> >>> gl_ClipDistance[0] = 1;

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp index 9d70ec3c9c..e4f38c8e46 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp +++

And another try for constant folding of Instructions for nvc0. Please Review this! Thanks, Tobias Klausmann Tobias Klausmann (4): nvc0/ir: clear subop when folding constant expressions nvc0/ir: Handle reverse subop for OP_EXTBF when folding constant expressions nvc0/ir: Handle OP_BFIND when folding constant expressions nvc0/ir: Handle OP_POPCNT when folding constant expressions

This patch series adds the needed support for this extension to the various parts of mesa to finally enable it for nvc0. Dave Airlie (1): glsl: lower cull_distance into cull_distance_mesa Tobias Klausmann (10): glapi: add GL_ARB_cull_distance mesa/main: add support for GL_ARB_cull_distance mesa/prog: Add varyings for arb_cull_distance mesa/st: add support for GL_ARB_cull_distance

Yet another try for constant folding of Instructions for nvc0. Please Review this again! (Hopefully the last time ;-) ) Tobias Klausmann (4): nvc0/ir: clear subop when folding constant expressions nvc0/ir: Handle reverse subop for OP_EXTBF when folding constant expressions nvc0/ir: Handle OP_BFIND when folding constant expressions nvc0/ir: Handle OP_POPCNT when folding constant

v2: use initialization list (Pierre) Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> Reviewed-by: Pierre Moreau <pierre.morrow at free.fr> --- src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp

Hi, please review the following 4 patches: 1b1cfc6 nvc0/ir: Handle OP_BFIND when folding constant expressions d2d2727 nvc0/ir: Handle OP_POPCNT when folding constant expressions 86a1ee6 nvc0/ir: Handle reverse subop for OP_EXTBF when folding constant expressions 84563bf nvc0/ir: clear subop when folding constant expressions src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 39

nouveau_compiler.c: In function ‘main’: nouveau_compiler.c:216:27: warning: ‘code’ may be used uninitialized in this function [-Wmaybe-uninitialized] printf("%08x ", code[i / 4]); ^ nouveau_compiler.c:215:4: warning: ‘size’ may be used uninitialized in this function [-Wmaybe-uninitialized] for (i = 0; i < size; i += 4) { Signed-off-by: Tobias

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

the problem is, that you also need to be able to save the TGSI into a file and run it rhough nouveau_compiler. Not really sure if it is worth the effort. Printing hex instead of numbers make more sense in this regard anyhow, because we are more precise and being able to debug some issues much better in the end. As long as the new version is still correctly parsed with nouveau_compiler, this change

This is enough to enable tessellation support on nvc0. It seems to work a lot better on my GF108 than GK208. I suspect that there's some sort of scheduling shenanigans that need to be adjusted for kepler+. Or perhaps some shader header things. Even with the GF108, I still get occasional blue triangles in Heaven, but I get a *ton* of them on the GK208 -- seemingly the same issue, but it's

On 8 July 2015 at 20:34, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > Mh i'm not aware of me ever changed the "nouveau_compiler". But i'm happy to > see this made you laugh, so it has something positive at least... :/ > Story time: This particular compiler warning has been brought up (incl here) four or five times. Each time, Ilia feels

For values above integer accuracy in floats, val - floor(val) might actually produce a value greater than 1. For such large floats, it's reasonable to be imprecise, but it's unreasonable for FRC to return a value that is not between 0 and 1. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 3 ++- 1 file changed, 2

Curious how many times this needs to come along, for you to change your mind. :-) On 8 July 2015 at 19:38, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Compiler is wrong. > > On Wed, Jul 8, 2015 at 2:27 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> nouveau_compiler.c: In function ‘main’: >> nouveau_compiler.c:216:27: warning: