search for: handlestor

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 now always zero-sized resources vector. Disable all the dead code. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -Split out assert() on getFile() != BUFFER/MEMORY into a separate patch -Split out r...

...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 now always zero-sized resources vector. > > Make non buffer / memory file accesses not being supported in these > functions more explicit and comment out a whole bunch of dead code. > > Also remove the magic file...

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 now always zero-sized resources vector. Make non buffer / memory file accesses not being supported in these functions more explicit and comment out a whole bunch of dead code. Also remove the magic file-indexe defines from the old...

...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 now always zero-sized resources vector. >> >> Make non buffer / memory file accesses not being supported in these >> functions more explicit and comment out a whole bunch of dead code. >> >> Al...

Hi, On 08-04-16 17:45, Ilia Mirkin wrote: > On Fri, Apr 8, 2016 at 11:28 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> When dealing with non vector variables the llvm register allocator >> will use TEMP[0].x then TEMP[0].y, etc. >> >> When loading something from a global buffer it will calculate the >> address to use, and store that in say TEMP[0].x,

...gt; effective. > > Right and note that the first src operand of STORE already takes swizzling > into account, so the proposed option 2 will actually make the 2 more inline. Erm, I mean the 2nd src operand of the store of-course, the actual src. On a related note, comparing handleLOAD and handleSTORE, this bit in handleLOAD seems wrong: Value *off = fetchSrc(1, c); I believe that should be: Value *off = fetchSrc(1, 0); Just like handleSTORE does: off = fetchSrc(0, 0); And always using a 'c' of 0 seems correct here since we are dealing with an address. Once I know...

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>

LOAD loads upto 4 components from the specified 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