search for: nv50_prog_debug

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/nouve...

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 +- src/...

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

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

...>> 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 NV50_PROG_DEBUG=1 output here: > > https://fedorapeople.org/~jwrdegoede/nbody.log > > nvdisasm -b SM30 for the generated binary code is here: > > https://fedorapeople.org/~jwrdegoede/nbody.disasm > > There are already .tgsi, .hex and .bin files there if > you find those easier to use the...

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

...39;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 NV50_PROG_DEBUG=1 output here: https://fedorapeople.org/~jwrdegoede/nbody.log nvdisasm -b SM30 for the generated binary code is here: https://fedorapeople.org/~jwrdegoede/nbody.disasm There are already .tgsi, .hex and .bin files there if you find those easier to use then the NV50_PROG_DEBUG=1 output. > &g...

...Y_CONST: c = 'c'; break; >> case FILE_SHADER_INPUT: c = 'a'; break; >> case FILE_SHADER_OUTPUT: c = 'o'; break; >> + case FILE_MEMORY_BUFFER: c = 'b'; break; // Only used before lowering > > Could you please show me the output of NV50_PROG_DEBUG=255 with a test which uses this file type? I'm not sure if using b[] is better than g[] actually. NV50_PROG_DEBUG=255 bin/arb_shader_storage_buffer_object-rendering ... MAIN:-1 () BB:0 (52 instructions) - df = { } -> BB:1 (tree) 0: mov u32 %r1 0x00000000 (0) 1: ld u32 %r0 b[0x0]...

...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 NV50_PROG_DEBUG=1 output here: >> >> https://fedorapeople.org/~jwrdegoede/nbody.log >> >> nvdisasm -b SM30 for the generated binary code is here: >> >> https://fedorapeople.org/~jwrdegoede/nbody.disasm >> >> There are already .tgsi, .hex and .bin files there if >&...

...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 NV50_PROG_DEBUG=1 output here: >> >> https://fedorapeople.org/~jwrdegoede/nbody.log >> >> nvdisasm -b SM30 for the generated binary code is here: >> >> https://fedorapeople.org/~jwrdegoede/nbody.disasm >> >> There are already .tgsi, .hex and .bin files there if >&...

...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! > > 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/nouve...

...ase FILE_SHADER_INPUT: c = 'a'; break; >>>> case FILE_SHADER_OUTPUT: c = 'o'; break; >>>> + case FILE_MEMORY_BUFFER: c = 'b'; break; // Only used before >>>> lowering >>> >>> Could you please show me the output of NV50_PROG_DEBUG=255 with a test >>> which uses this file type? I'm not sure if using b[] is better than >>> g[] actually. >> >> NV50_PROG_DEBUG=255 bin/arb_shader_storage_buffer_object-rendering >> >> ... >> >> MAIN:-1 () >> BB:0 (52 instructions) - d...

...>>> case FILE_SHADER_INPUT: c = 'a'; break; >>> case FILE_SHADER_OUTPUT: c = 'o'; break; >>> + case FILE_MEMORY_BUFFER: c = 'b'; break; // Only used before >>> lowering >> >> Could you please show me the output of NV50_PROG_DEBUG=255 with a test >> which uses this file type? I'm not sure if using b[] is better than >> g[] actually. > > NV50_PROG_DEBUG=255 bin/arb_shader_storage_buffer_object-rendering > > ... > > MAIN:-1 () > BB:0 (52 instructions) - df = { } > -> BB:1 (tree) &gt...

...T: c = 'a'; break; >>>>> case FILE_SHADER_OUTPUT: c = 'o'; break; >>>>> + case FILE_MEMORY_BUFFER: c = 'b'; break; // Only used before >>>>> lowering >>>> >>>> Could you please show me the output of NV50_PROG_DEBUG=255 with a test >>>> which uses this file type? I'm not sure if using b[] is better than >>>> g[] actually. >>> >>> NV50_PROG_DEBUG=255 bin/arb_shader_storage_buffer_object-rendering >>> >>> ... >>> >>> MAIN:-1 () &gt...

https://bugs.freedesktop.org/show_bug.cgi?id=56788 Emil Velikov <emil.l.velikov at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org |rg

https://bugs.freedesktop.org/show_bug.cgi?id=72939 Priority: medium Bug ID: 72939 Assignee: nouveau at lists.freedesktop.org Summary: [nv96] Freespace 2 open crashes Severity: normal Classification: Unclassified OS: All Reporter: madman2003 at gmail.com Hardware: Other Status: NEW

...info.io.suInfoBase = NV50_CB_AUX_TEX_MS_OFFSET; + info.io.msInfoCBSlot = 15; + info.io.msInfoBase = NV50_CB_AUX_MS_OFFSET; + + info.assignSlots = dummy_assign_slots; + + info.optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3); + info.dbgFlags = debug_get_num_option("NV50_PROG_DEBUG", 0); + + i = nv50_ir_generate_code(&info); + if (i) { + _debug_printf("Error compiling program: %d\n", i); + return i; + } + + _debug_printf("program binary (%d bytes)\n", info.bin.codeSize); + for (i = 0; i < info.bin.codeSize; i += 4) { +...

Some of the lowering steps we currently do for FILE_MEMORY_GLOBAL only apply to buffers, making it impossible to use FILE_MEMORY_GLOBAL for OpenCL global buffers. This commits changes the buffer code to use FILE_MEMORY_BUFFER at the ir_from_tgsi and lowering steps, freeing use of FILE_MEMORY_GLOBAL for use with OpenCL global buffers. Note that after lowering buffer accesses use the

https://bugs.freedesktop.org/show_bug.cgi?id=96355 Bug ID: 96355 Summary: Performance: extra&costly SSBO validation even when SSBO aren't used Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component:

...case FILE_MEMORY_CONST: c = 'c'; break; > case FILE_SHADER_INPUT: c = 'a'; break; > case FILE_SHADER_OUTPUT: c = 'o'; break; > + case FILE_MEMORY_BUFFER: c = 'b'; break; // Only used before lowering Could you please show me the output of NV50_PROG_DEBUG=255 with a test which uses this file type? I'm not sure if using b[] is better than g[] actually. > case FILE_MEMORY_GLOBAL: c = 'g'; break; > case FILE_MEMORY_SHARED: c = 's'; break; > case FILE_MEMORY_LOCAL: c = 'l'; break; > diff --git a...