similar to: [PATCH mesa 0/3] tgsi and nouveau global / local / opencl-input mem support

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_build.c | 6 ++++++ 1 file changed, 6

On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Extend the MEMORY file support to differentiate between global, local > and shared memory, as well as "input" memory. > > "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a > special memory type is added for this, since the actual storage of these > (e.g.

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

Extend the MEMORY file support to differentiate between global, local and shared memory, as well as "input" memory. "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a special memory type is added for this, since the actual storage of these (e.g. UBO-s) may differ per implementation. The uploading of kernel parameters is handled by launch_grid,

Extend the MEMORY file support to differentiate between global, private and shared memory, as well as "input" memory. "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a special memory type is added for this, since the actual storage of these (e.g. UBO-s) may differ per implementation. The uploading of kernel parameters is handled by launch_grid,

Hi, On 10-03-16 16:35, Aaron Watry wrote: > On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > >> Extend the MEMORY file support to differentiate between global, local >> and shared memory, as well as "input" memory. >> >> "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a >> special

Also some missing _src()s and cosmetic changes. --- src/gallium/programs/galliumut/Makefile | 5 + .../programs/galliumut/gen_uureg_opcodes.sh | 29 +++ src/gallium/programs/galliumut/uureg.h | 196 ++++---------------- 3 files changed, 71 insertions(+), 159 deletions(-) create mode 100644 src/gallium/programs/galliumut/gen_uureg_opcodes.sh diff --git

Only implemented for glsl->tgsi. Other converters just set precise to 0. Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 3 +++ src/gallium/auxiliary/tgsi/tgsi_ureg.c | 14 +++++++--- src/gallium/auxiliary/tgsi/tgsi_ureg.h | 20 +++++++++++--- src/gallium/auxiliary/util/u_simple_shaders.c | 2 +-

This looks like the right idea to me too. It may sound a bit weird to do that per instruction, but d3d11 does that as well. (Some d3d versions just have a global flag basically forbidding or allowing 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>

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>

https://bugs.freedesktop.org/show_bug.cgi?id=80266 Priority: medium Bug ID: 80266 Assignee: nouveau at lists.freedesktop.org Summary: Undefined operation in tgsi_ureg.c left shift of 1 by 31 places cannot be represented in type 'int' Severity: minor Classification: Unclassified OS: Linux (All)

Hi, On 14-03-16 16:05, Ilia Mirkin wrote: > There's a less hacky and more hacky way forward. The more hacky solution is > to set file index to -1 or something and then not do the lowering when you > see that. > > The less hacky solution is the one you proposed as #1 - introduce a new > file for "buffer" memory and lower it to the global file by adding a base >

This little "hack" fixes the use of OpenCL global memory buffers with nouveau, but clearly the #if 0 is not a solution as it breaks buffers with GLSL. The reason I'm posting this as an RFC patch is to discuss how to solve this properly, 2 solutions come to mind: 1) Use separate nv50_ir::FILE_MEMORY_xxx values for buffers versus TGSI_FILE_MEMORY with TGSI_MEMORY_TYPE_GLOBAL,

On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Add support for clover / OpenCL kernel input parameters. > > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- > .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 18 +++++++++++++++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > > diff --git

On Thu, Mar 10, 2016 at 10:27 AM, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote: > > > On 03/10/2016 04:23 PM, Ilia Mirkin wrote: >> >> On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede <hdegoede at redhat.com> >> wrote: >>> >>> Add support for clover / OpenCL kernel input parameters. >>> >>> Signed-off-by: Hans de

Hi, On 14-03-16 16:41, Samuel Pitoiset wrote: > > > On 03/14/2016 04:28 PM, Hans de Goede wrote: >> Hi, >> >> On 14-03-16 16:05, Ilia Mirkin wrote: >>> There's a less hacky and more hacky way forward. The more hacky >>> solution is >>> to set file index to -1 or something and then not do the lowering when >>> you >>> see

On 04:27 PM - Mar 10 2016, Samuel Pitoiset wrote: > > > On 03/10/2016 04:23 PM, Ilia Mirkin wrote: > >On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > >>Add support for clover / OpenCL kernel input parameters. > >> > >>Signed-off-by: Hans de Goede <hdegoede at redhat.com> > >>--- > >>

On 03/16/2016 10:23 AM, Hans de Goede wrote: > Commit c3083c7082 ("nv50/ir: add support for BUFFER accesses") disabled / > commented out some of the old resource handling code, but not all of it. > > Effectively all of it is dead already, if we ever enter the old code > paths in handeLOAD / handleSTORE / handleATOM we will get an exception > due to trying to access the

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/tgsi_build.c index cfe9b92..c420ae1 100644 ---

Hi All, While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089 I made a apitrace recording of the a single slide transition animation, and since I suspected memory corruption replayed it using ElectrFence + glretrace, this finds a 0 sized array allocation at src/mesa/state_tracker/st_glsl_to_tgsi.cpp: 5565: if (proginfo->Parameters) { t->constants = (struct