similar to: [PATCH] nouveau: add a nouveau_compiler binary to compile TGSI into shader ISA

I think it is better to put this behind an environmental variable, because that way it can also be used without having to dump the TGSI first and I don't see a good reason why not to. On Tue, Nov 14, 2017 at 4:01 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > This comes in handy when checking "NV50_PROG_DEBUG=1" outputs with diff! > >

This comes in handy when checking "NV50_PROG_DEBUG=1" outputs with diff! Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 6 +++--- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 2 +- src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h | 1 +

This comes in handy when checking "NV50_PROG_DEBUG=1" outputs with diff! V2: - Use environmental variable (Karol Herbst) V3: - Use the already populated nv50_ir_prog_info to forward 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 +

The “Program” class keeps a pointer to the “nv50_ir_prog_info” structure, so you could just use that in the “Program::print()” function, rather than passing the flag as an argument to “print”. Pierre On 2017-11-17 — 17:21, Tobias Klausmann wrote: > This comes in handy when checking "NV50_PROG_DEBUG=1" outputs with diff! > > V2: > - Use environmental variable (Karol

This comes in handy when checking "NV50_PROG_DEBUG=1" outputs with diff! V2: - Use environmental variable (Karol Herbst) Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 6 +++--- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 2 +-

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

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,

https://bugs.freedesktop.org/show_bug.cgi?id=101418 Bug ID: 101418 Summary: Build failure in GNOME Continuous Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=79462 Priority: medium Bug ID: 79462 Assignee: nouveau at lists.freedesktop.org Summary: [NVC0/Codegen] Shader compilation falis in spill logic Severity: normal Classification: Unclassified OS: All Reporter: imirkin at alum.mit.edu Hardware: Other

Hi, On 16-12-15 18:24, Ilia Mirkin wrote: > I believe that your problem is this: > > /*01a0*/ LD R8, [R8]; > /* 0x8000000000821c85 */ > > That needs to be LD.E (and your ST's need to be ST.E). You're using a > 32-bit gmem address, but you need to be using a 64-bit one. I believe > the 32-bit ones work on fermi, but afaik 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 all, As part of my compute work I'm trying to get some TGSI compute code to work. The code from mesa/src/gallium/tests/trivial.c works. So now I'm trying to get a "native" tgsi kernel to run via clover, I'm using Francisco's nbody.c example for this: https://fedorapeople.org/~jwrdegoede/nbody.c Which does not work, at first I thought there was an issue with the

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:

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

https://bugs.freedesktop.org/show_bug.cgi?id=101371 Bug ID: 101371 Summary: GlobalCSE Pass moves phi instructions Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau

Also, where's the exit op? Perhaps what's happening is that you don't have an exit and it just goes off executing into the ether? On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > A few things that stand out: > > 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) > > wtf is that 0x0000000000000 thing doing there? Was it a %rX which got

A few things that stand out: 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) wtf is that 0x0000000000000 thing doing there? Was it a %rX which got constant-folded into 0? That indirectness should have then been removed... that said, the final encoding looks fine. I believe that kepler has this launch descriptor thing too... is that being set correctly? Please generate a mmt trace, and we can

Hi, On 15-12-15 20:04, Ilia Mirkin wrote: > Also, where's the exit op? Perhaps what's happening is that you don't > have an exit and it just goes off executing into the ether? Sorry I only included a small bit of the program in my original mail because I found the use of "MOV" instructions to load constants suspicious, is that normal ? I've put a log with

I believe that your problem is this: /*01a0*/ LD R8, [R8]; /* 0x8000000000821c85 */ That needs to be LD.E (and your ST's need to be ST.E). You're using a 32-bit gmem address, but you need to be using a 64-bit one. I believe the 32-bit ones work on fermi, but afaik not on Kepler. Cheers, -ilia On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede

BTW, you may be interested in https://github.com/imirkin/mesa/commits/atomic3 which has working ARB_shader_atomic_counters and ARB_shader_storage_buffer_object support (while ripping out things like TGSI_FILE_RESOURCE). Still working on proper memory qualifier support, and obviously need to do some cleanup before upstreaming. Should be getting into a pushable state probably early January. Cheers,