search for: nouveau_compil

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 [-W...

...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: ‘code’ may be used uninitialized in >> this function [-Wmaybe-uninitialized] >> printf("%08x ", code[i / 4]); >> ^ >> nouveau_compiler.c:215:4: warning: ‘size’ m...

...rkin at alum.mit.edu> --- This currently only works for nv50+, but it'd probably be possible to split the code paths and introduce nv30/40 support. src/gallium/drivers/nouveau/.gitignore | 1 + src/gallium/drivers/nouveau/Makefile.am | 12 +++ src/gallium/drivers/nouveau/nouveau_compiler.c | 133 +++++++++++++++++++++++++ 3 files changed, 146 insertions(+) create mode 100644 src/gallium/drivers/nouveau/.gitignore create mode 100644 src/gallium/drivers/nouveau/nouveau_compiler.c diff --git a/src/gallium/drivers/nouveau/.gitignore b/src/gallium/drivers/nouveau/.gitignore new fil...

...d information to the print pass (Pierre Moreau) Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 + src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 12 +++++++++--- src/gallium/drivers/nouveau/nouveau_compiler.c | 2 ++ src/gallium/drivers/nouveau/nv50/nv50_program.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++ 5 files changed, 16 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codege...

...--- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 2 +- src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 + src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 14 ++++++++++---- src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +- src/gallium/drivers/nouveau/nouveau_compiler.c | 3 +++ src/gallium/drivers/nouveau/nv50/nv50_program.c | 2 ++ src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++ 8 files changed, 23 insertions(+), 9 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp b/src/gallium/drivers/nouveau/codegen...

...++--- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 2 +- src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 + src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 12 ++++++++---- src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +- src/gallium/drivers/nouveau/nouveau_compiler.c | 8 ++++++-- src/gallium/drivers/nouveau/nv50/nv50_program.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 1 + 8 files changed, 22 insertions(+), 11 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp b/src/gallium/drivers/nouveau/cod...

...link: ( cd ".libs" && rm -f "libnouveau.la" && ln -s "../libnouveau.la" "libnouveau.la" ) /bin/sh ../../../../libtool --tag=CXX --mode=link x86_64-gnomeostree-linux-g++ -g -m64 -mtune=generic -Wall -fno-math-errno -fno-trapping-math -o nouveau_compiler nouveau_compiler.o libnouveau.la ../../../../src/gallium/auxiliary/libgallium.la ../../../../src/util/libmesautil.la -lm -lpthread -ldl -ldrm libtool: link: x86_64-gnomeostree-linux-g++ -g -m64 -mtune=generic -Wall -fno-math-errno -fno-trapping-math -o nouveau_compiler nouveau_compiler.o ./....

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, 0x0000001e} IMM[6] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000} = IMM[6] FLT32 {0x0000001e, 0x00000005, 0x0000000a, 0x000...

...vers/nouveau/codegen/nv50_ir.h | 2 +- > src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 + > src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 14 ++++++++++---- > src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +- > src/gallium/drivers/nouveau/nouveau_compiler.c | 3 +++ > src/gallium/drivers/nouveau/nv50/nv50_program.c | 2 ++ > src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 2 ++ > 8 files changed, 23 insertions(+), 9 deletions(-) > > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp b/src/galliu...

...rivers/nouveau/codegen/nv50_ir.h | 2 +- > src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 + > src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 12 ++++++++---- > src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +- > src/gallium/drivers/nouveau/nouveau_compiler.c | 8 ++++++-- > src/gallium/drivers/nouveau/nv50/nv50_program.c | 1 + > src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 1 + > 8 files changed, 22 insertions(+), 11 deletions(-) > > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp b/src/gal...

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 reluctant about the fix as the (gcc) compiler gets it wrong. Personall...

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 is ack...

...l 00000004 [MULTIPLE_WARP_ERRORS] warp 20009 [INVALID_OPCODE] and repeats that for every "step" in the nobody simulation, this is on a gk107 card. So that seems to be the real problem, since the error says "INVALID_OPCODE", I've put the tgsi code from nbody.c through "nouveau_compiler -a e4" and then run "nvdisasm -b SM30" on it, but the output looks ok. There is a 8 byte sequence which does not get decoded every 64 bytes but AFAIK that is the scheduling info, so that should be fine. One thing which does stand out is that this: 0: ld u32 %r219 c0[0x00000000...

...every "step" in the nobody simulation, this is on a >>>> gk107 card. >>>> >>>> So that seems to be the real problem, since the >>>> error says "INVALID_OPCODE", I've put the tgsi code from nbody.c >>>> through "nouveau_compiler -a e4" and then run "nvdisasm -b SM30" >>>> on it, but the output looks ok. There is a 8 byte sequence which does >>>> not get decoded every 64 bytes but AFAIK that is the scheduling info, >>>> so that should be fine. >>>> >>&gt...

...416adf in nv50_ir_generate_code (info=0x7ffffffe87e0) at ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir.cpp:1256 #11 0x0000000000402e33 in nouveau_codegen (chipset=230, type=1, tokens=0x7fffffff9420, size=0x7ffffffe941c, code=0x7ffffffe9410) at ../../../../../src/gallium/drivers/nouveau/nouveau_compiler.c:126 #12 0x0000000000403210 in main (argc=4, argv=0x7fffffffd528) at ../../../../../src/gallium/drivers/nouveau/nouveau_compiler.c:206 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug. -------------- next part -------------- An HTML a...

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 0x3fe00000 0x0 0x3 ??? [unknown: 000000...

https://bugs.freedesktop.org/show_bug.cgi?id=83079 Priority: medium Bug ID: 83079 Assignee: nouveau at lists.freedesktop.org Summary: Dota 2 under Wine freezes with Nouveau Drivers Severity: normal Classification: Unclassified OS: All Reporter: lukebenes at hotmail.com Hardware: Other Status:

...>> >> and repeats that for every "step" in the nobody simulation, this is on a >> gk107 card. >> >> So that seems to be the real problem, since the >> error says "INVALID_OPCODE", I've put the tgsi code from nbody.c >> through "nouveau_compiler -a e4" and then run "nvdisasm -b SM30" >> on it, but the output looks ok. There is a 8 byte sequence which does >> not get decoded every 64 bytes but AFAIK that is the scheduling info, >> so that should be fine. >> >> One thing which does stand out is...

...ructions) - df = { } Which is also using 32 bits loads from global memory and that works fine on my GK107 [GeForce GT 740]. I think that for now I'll just focus on translating the tests from rc/gallium/tests/trivial/compute.c to opencl and getting the entire opencl -> llvm -> tgsi -> nouveau_compiler -> hardware chain to work that way. Still would be good to get nbody.c to work though. Regards, Hans > > Cheers, > > -ilia > > > > On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> On 15-12-15...

...u32 $r2 0x00000000 (8) 2: mov u32 $r3 0x3fe00000 (8) 3: add f64 $r0d $r0d $r2d (8) Into: 1: add f64 $r0d $r0d 0.500000 (8) This has been tested with the 2 double shader tests which I just send to the piglet list. On a gk208 (gk110 / SM35) card, and by checking the output of nouveau_compiler with both nvdisasm and envydis on gf100 / gk104 / gm107. Regards, Hans