search for: tgsi

Hi, Here are patches which implement the support for OpenCL kernel input parameters we discussed. They also add the tgsi parsing bits for adding support for global / local mem, but no implementation yet. Regards, Hans

When support for decl.Atomic and .Shared was added, tgsi_build_declaration was not updated to propagate these properly. Signed-off-by: Hans de Goede <hdegoede at redhat.com> Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Changes in v2: -Add Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/auxiliary/tgsi/tgsi_...

...resource starting at the passed in x value of the 2nd source operand, the y, z and w components of the address should not be used. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -New patch in v2 of this patch-set --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp index 557608e..d3c2d61 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp +++ b/src/galli...

...of kernel > parameters is handled by launch_grid, "MEMORY[x], INPUT" allows drivers > to use an access mechanism for parameter reads which matches with the > upload method. > > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- > src/gallium/auxiliary/tgsi/tgsi_build.c | 8 +++---- > src/gallium/auxiliary/tgsi/tgsi_dump.c | 9 ++++++-- > src/gallium/auxiliary/tgsi/tgsi_text.c | 14 ++++++++++-- > src/gallium/auxiliary/tgsi/tgsi_ureg.c | 25 > ++++++++++++---------- > src/gallium/auxiliar...

...per implementation. The uploading of kernel parameters is handled by launch_grid, "MEMORY[x], INPUT" allows drivers to use an access mechanism for parameter reads which matches with the upload method. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 8 +++---- src/gallium/auxiliary/tgsi/tgsi_dump.c | 9 ++++++-- src/gallium/auxiliary/tgsi/tgsi_text.c | 14 ++++++++++-- src/gallium/auxiliary/tgsi/tgsi_ureg.c | 25 ++++++++++++---------- src/gallium/auxiliary/tgsi/tgsi_ureg.h...

The llvm TGSI backend does things like: LOAD TEMP[0].y, MEMORY[0].xxxx, TEMP[0].x Expecting the data at address TEMP[0].x to get loaded to TEMP[0].y. Before this commit the data at TEMP[0].x + 4 would be loaded instead. This commit fixes this. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- s...

...llows drivers to use an access mechanism for parameter reads which matches with the upload method. Signed-off-by: Hans de Goede <hdegoede at redhat.com> Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Changes in v2: -Drop mention of GLSL global / GLSL local from comments -Change TGSI_MEMORY_TYPE_LOCAL to TGSI_MEMORY_TYPE_PRIVATE -Add Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 8 +++---- src/gallium/auxiliary/tgsi/tgsi_dump.c | 9 ++++++-- src/gallium/auxiliary/tgsi/tgsi_text.c | 14...

...s is handled by launch_grid, "MEMORY[x], INPUT" allows drivers >> to use an access mechanism for parameter reads which matches with the >> upload method. >> >> Signed-off-by: Hans de Goede <hdegoede at redhat.com> >> --- >> src/gallium/auxiliary/tgsi/tgsi_build.c | 8 +++---- >> src/gallium/auxiliary/tgsi/tgsi_dump.c | 9 ++++++-- >> src/gallium/auxiliary/tgsi/tgsi_text.c | 14 ++++++++++-- >> src/gallium/auxiliary/tgsi/tgsi_ureg.c | 25 >> ++++++++++++---------- >&gt...

...Also remove the magic file-indexe defines from the old resource code > from include/pipe/p_shader_tokens.h as those are no longer used now > (which is a good thing). > > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- > .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 42 +++++++++++++++------- > src/gallium/include/pipe/p_shader_tokens.h | 9 ----- > 2 files changed, 30 insertions(+), 21 deletions(-) > > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cp...

...12.06.2017 um 12:42 schrieb Nicolai Hähnle: > On 11.06.2017 20:42, Karol Herbst wrote: >> Running Tomb Raider on Nouveau I found some flicker caused by ignoring >> precise >> modifiers on variables inside Nouveau. >> >> This series add precise/invariant handling to TGSI, which can be then >> used by >> drivers to disable certain unsafe optimisations which may otherwise alter >> calculations, which depend on having the same result across shaders. > > It's kind of amazing that we got this far without doing this. On the > radeonsi side...

On 11.06.2017 20:42, Karol Herbst wrote: > Running Tomb Raider on Nouveau I found some flicker caused by ignoring precise > modifiers on variables inside Nouveau. > > This series add precise/invariant handling to TGSI, which can be then used by > drivers to disable certain unsafe optimisations which may otherwise alter > calculations, which depend on having the same result across shaders. It's kind of amazing that we got this far without doing this. On the radeonsi side, it's probably related to...

...lowing any such fast > math optimizations in the assembly, but I'm not actually sure everybody > honors that without tesselation...) > > For 1/9: > Reviewed-by: Roland Scheidegger <sroland at vmware.com> I forgot to mention, could you add some bits in gallium docs (source/tgsi.rst) for this? Not sure where maybe under Modifiers or some such. Roland > > 2/9 has a typo in the commit short log ("Instrutions"). > > FWIW surely on nv50 you could keep a single mad instruction for umad > (sad maybe too?). (I'm actually wondering if the hw really...

...f you think this will cause a problem for radeon. Hans is solving the issue that he wants to swizzle the data loaded from the image/buffer/whatever before sticking it into the dst register. -ilia On Thu, Apr 21, 2016 at 8:39 AM, Hans de Goede <hdegoede at redhat.com> wrote: > The llvm TGSI backend uses pointers in registers and does things > like: > > LOAD TEMP[0].y, MEMORY[0], TEMP[0] > > Expecting the data at address TEMP[0].x to get loaded to > TEMP[0].y. But this will cause the data at TEMP[0].x + 4 to be > loaded instead. > > This commit adds support f...

Hi All, So as discussed I've started working on a TGSI backend for llvm to use as a way to get compute going on nouveau (and other gpu-s). I'm still learning all the ins and outs of llvm so I do not have much to show yet. I've rebased Francisco's (curro's) latest version on top of llvm trunk, and added a commit on top to actual get it...

Hi, After a few distractions I'm back to work on the llvm tgsi backend. I've added clang integration and I can now compile a simple opencl program to something which sort of looks like tgsi. You can find my latest work on this here: http://cgit.freedesktop.org/~jwrdegoede/llvm http://cgit.freedesktop.org/~jwrdegoede/clang (the latter may still need to syn...

When support for decl.Atomic and .Shared was added, tgsi_build_declaration was not updated to propagate these properly. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/gallium/auxiliary/tgsi/tgsi_build.c b/src/gallium/auxiliary/tgsi/tgs...

Running Tomb Raider on Nouveau I found some flicker caused by ignoring precise modifiers on variables inside Nouveau. This series add precise/invariant handling to TGSI, which can be then used by drivers to disable certain unsafe optimisations which may otherwise alter calculations, which depend on having the same result across shaders. This series fixes this bug in Tomb Raider and one CTS test for 4.4 and 4.5 Note on Patch 3: I really dislike how I tell glsl_to...

The llvm TGSI backend uses pointers in registers and does things like: LOAD TEMP[0].y, MEMORY[0], TEMP[0] Expecting the data at address TEMP[0].x to get loaded to TEMP[0].y. But this will cause the data at TEMP[0].x + 4 to be loaded instead. This commit adds support for a swizzle suffix for the 1st source ope...

...pute >> kernels for testing. I guess you manually wrote them ? > > Yeah, I wrote those compute kernels directly in assembly by hand. > > I already said few days ago, you have some examples in src/gallium/tests/trivial/compute.c which show how to use that compute support stuff with TGSI kernels and without clover. Ah, right. Ok I'll take a look at those. > Because clover is not currently able to do OpenCL -> TGSI using Clang/LLVM, you can't really use your backend directly. I know I'm fine with manually copying TGSI output by llc for my first tests. I've t...

...gt; But this does not seem to be hooked up yet for nouveau. > > Samuel has patches. See > https://cgit.freedesktop.org/~hakzsam/mesa/log/?h=arb_compute_shader_v3 Cool, I will take a look at those. >> So some questions: >> -The commit by Samual says: >> This introduces TGSI_FILE_MEMORY for shared, global and local memory. Only >> shared memory is currently supported. >> >> The commit introduces MEMORY[x] and MEMORY[x],SHARED so in reality it also >> introduces >> a second option next to shared, so what are we going to use plain MEMORY...