similar to: [PATCH] nouveau/codegen: add missing values for OP_TXLQ into the target arrays

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Note: this applies on top of airlied's r600g-texture-gather branch. Appears to pass all 4 piglit tests. The conversion from what the instruction outputs is the same as what the blob does. src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 + .../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 4 ++++

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

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

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

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

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Tested on NVE6. Very strange that it seems to use 8 bits for offsets, vs 4 bits used by texelFetch. But this passes the piglit tests. Will test on a NVCX before checking in, in case it's different there. (Although that'd be surprising, given the similarities between the 2 ISAs.)

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedesktop.org> --- Not 100% sure of the significance of this code, but this seems like the correct thing to do... will definitely run it through a full piglit run before pushing out. src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git

And you're allowing saturate/neg emission on the short form. Is this already in envytools? Also, what's the shortForm thing? This change is probably fine, but the changelog needs work. On Sat, Jan 10, 2015 at 7:22 PM, Roy Spliet <rspliet at eclipso.eu> wrote: > MAD IMM has a very specific SDST == SSRC2 requirement, so don't emit > > Signed-off-by: Roy Spliet <rspliet

Add emission rules for negative and saturate flags for MAD 4-byte opcodes, and get rid of some of the constraints. Obviously tested with a wide variety of shaders. V2: Document MAD as supported short form V3: Split up IMM from short-form modifiers Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 10 ++++------

Op 11-01-15 om 01:34 schreef Ilia Mirkin: > And you're allowing saturate/neg emission on the short form. Yes > Is this already in envytools? Tesla floating point instructions are poorly documented in the RST documents; fmad is no exception. I'll make sure to check envydis. > Also, what's the shortForm thing? Documented in envytools; see

Add emission rules for negative and saturate flags for MAD 4-byte opcodes, and get rid of constraints. Short MAD has a very specific SDST == SSRC2 requirement, and since MAD IMM is short notation + 4-byte immediate, don't have the compiler create MAD IMM instructions yet. V2: Document MAD as supported short form Signed-off-by: Roy Spliet <rspliet at eclipso.eu> ---

MAD IMM has a very specific SDST == SSRC2 requirement, so don't emit Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- .../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 18 ++++++++++++------ .../drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 2 +- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp