similar to: [PATCH mesa v2 1/3] nouveau: codegen: LOAD: Always use component 0 when getting the address

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> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 8 ++++++-- 1 file changed,

Hi, On 07-04-16 15:58, Ilia Mirkin wrote: > That's wrong. It used to work with the old RES[] code and if one cannot specify a source swizzle, then how can I do something like LOAD TEMP[0].y, MEMORY[0], address And get the data at absolute global memory address "address" into TEMP[0].y ? This is a must-have for llvm to be able to generate working TGSI code, I do not see any

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

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.

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>

[+radeon folk] Marek, Nicolai, Bas - please have a look at the doc change and let us know if 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

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 operand, which allows using: LOAD TEMP[0].y, MEMORY[0].xxxx, TEMP[0] And actually

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 66 +++++++++++++++++++++- 1 file changed, 63 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp index dfb093c..e38a3b8 100644 ---

That's wrong. The spec for the instruction needs to be clarified... The current nouveau impl is correct - only the .x of the address should be loaded, with up to 16 bytes read into the destination. On Thu, Apr 7, 2016 at 9:27 AM, Hans de Goede <hdegoede at redhat.com> wrote: > The llvm TGSI backend does things like: > > LOAD TEMP[0].y, MEMORY[0].xxxx, TEMP[0].x > >

I went through the gallium-nine tree and picked out nouveau patches that are general bug-fixes. The first bunch I'd like to also get into 10.2. I've reviewed all of them and they make sense to me, but sending them out for public review as well in case there are any objections. Unless I hear objections, I'd like to push this by Friday. Christoph Bumiller (11): nv50,nvc0: always pull

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

On 21/05/14 00:39, Ilia Mirkin wrote: > From: Christoph Bumiller <christoph.bumiller at speed.at> > > Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> > Cc: "10.2" <mesa-stable at lists.freedesktop.org> > --- > src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff

On 21/05/14 19:53, Ilia Mirkin wrote: > On Wed, May 21, 2014 at 2:51 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: >> On 21/05/14 00:39, Ilia Mirkin wrote: >>> From: Christoph Bumiller <christoph.bumiller at speed.at> >>> >>> Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> >>> Cc: "10.2" <mesa-stable at

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,

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 >

For values above integer accuracy in floats, val - floor(val) might actually produce a value greater than 1. For such large floats, it's reasonable to be imprecise, but it's unreasonable for FRC to return a value that is not between 0 and 1. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 3 ++- 1 file changed, 2

On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote: > Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: >> For values above integer accuracy in floats, val - floor(val) might >> actually produce a value greater than 1. For such large floats, it's >> reasonable to be imprecise, but it's unreasonable for FRC to return a >> value that

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

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- .../drivers/nouveau/codegen/nv50_ir_driver.h | 1 + .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 27 ++++++++++++++++++++-- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- This fixes the bin/fs-textureOffset-2D piglit test on nv50. Have yet to re-run the full piglit suite with this change in place, but it seems pretty obvious. src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp