similar to: [RFC PATCH] nouveau/compiler: Allow to omit line numbers when printing instructions

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

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 +

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

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

Most of codegen is already FP64-ready. There are a few edge-cases that I ran into, many of which can apply even to non-fp64-enabled programs (although the double-wide registers are not very common without fp64). I've yet to give this a full piglit run, but wanted to send these out in case someone wanted to comment. They do not depend on the preliminary core fp64 work. Ilia Mirkin (5):

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

OK, so there's a bunch of stuff in here. The geometry stuff is based on the work started by Bryan Cain and Christoph Bumiller. Patches 01-12: Add support for geometry shaders and fix related issues Patches 13-14: Make it possible for fb clears to operate on texture attachments with an explicit layer set (as is allowed in gl 3.2). Patches 15-17: Make ARB_texture_multisample work

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

Hi, On 23-03-16 23:10, Samuel Pitoiset wrote: > Are you sure this won't break compute shaders on fermi? > Could you please double-check that? I just checked: lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1) Before this patch-set: [hans at plank piglit]$ ./piglit run -o shader -t '.*arb_shader_storage_buffer_object.*' results/shader

This makes it easy to compare output between different cards, especially for ones that you don't have (and/or not in the current machine). Signed-off-by: Ilia Mirkin <imirkin 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 +

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,

tgsi_default_instruction_memory / tgsi_build_instruction_memory were returning uninitialized memory for tgsi_instruction_memory.Texture and tgsi_instruction_memory.Format. Note 0 means not set, and thus is a correct default initializer for these. Fixes: 3243b6fc97 ("tgsi: add Texture and Format to tgsi_instruction_memory") Cc: Nicolai Hähnle <nicolai.haehnle at amd.com>

Hi, On 08-04-16 18:14, Samuel Pitoiset wrote: > > > On 04/08/2016 12:17 PM, Hans de Goede wrote: >> Hi, >> >> On 23-03-16 23:10, Samuel Pitoiset wrote: >>> Are you sure this won't break compute shaders on fermi? >>> Could you please double-check that? >> >> I just checked: >> >> lspci: >> 01:00.0 VGA compatible

Could you please get rid of the cosmetic changes (eg. the switch ones)? Because this doesn't really improve readability and in my opinion these changes should be eventually done in a separate patch. Other than that, this patch is : Reviewed-by: Samuel Pitoiset <samuel.pitoiset at gmail.com> Yes, this probably won't work as is for atomic operations but the lowering pass is

This approach leads to the emitters needing to know about both global and buffer, even though at that point, they are identical. I was thinking that in the lowering logic, buffer would just get rewritten as global (with the offset added), thus not needing any change to the emitters. What do you think about such an approach? On Mar 16, 2016 2:24 AM, "Hans de Goede" <hdegoede at

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=111217 Bug ID: 111217 Summary: compilation of vdpau shaders crashes in handleCVT_CVT Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee:

Hi, On 20-11-15 17:07, Samuel Pitoiset wrote: > > > On 11/20/2015 11:36 AM, Hans de Goede wrote: >> Hi Samual, et al, > > Hi Hans, > >> >> In >> http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd >> >> you write: "This compute support has been tested by >> Pierre

https://bugs.freedesktop.org/show_bug.cgi?id=69155 Priority: medium Bug ID: 69155 Assignee: nouveau at lists.freedesktop.org Summary: codegen/nv50_ir_emit_nv50.cpp:169:srcAddr8: Assertion `(offset <= 0x1fc || offset == 0x3fc) && !(offset & 0x3)' failed. Severity: critical

The hardware only generates vertexid when vertices come from a VBO. This fixes: vertexid-drawelements vertexid-drawarrays Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "11.0" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_program.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_program.h | 1 +