similar to: [PATCH] nvc0: do quadops on the right texture coordinates for TXD

On Tue, Dec 19, 2017 at 11:41 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > This is parallel to the pre-SM50 change which does this. Adjusts the > shuffles / quadops to make the values correct relative to lane 0, and > then splat the results to all lanes for the final move into the target > register. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> >

This is parallel to the pre-SM50 change which does this. Adjusts the shuffles / quadops to make the values correct relative to lane 0, and then splat the results to all lanes for the final move into the target register. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Entirely untested beyond compilation. Should check bin/tex-miplevel-selection textureGrad Cube

Something about how we're implementing offsets for TXD is wrong, just flip to the generic quadop-based implementation in that case. This is the minimal fix appropriate for backporting. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 3 ++- 1 file changed, 2

The nvc0 texfetch instruction expects the sample id to be in the second source (usually used for the offset) rather than as part of the texture coordinate. This fixes all the sampler2DMS/Array tests on nvc0. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.1" <mesa-stable at lists.freedesktop.org> --- Tested on nvc1 with a full piglit run, no regressions,

Unfortuantely we don't know if a particular load is a real 2d image (as would be a cube face or 2d array element), or a layer of a 3d image. Since we pass in the TIC reference, the instruction's type has to match what's in the TIC (experimentally). In order to properly support bindless images, this also can't be done by looking at the current bindings and generating appropriate

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.3" <mesa-stable at lists.freedesktop.org> --- With this, all the tex-miplevel-selection tests pass on maxwell. There is a minor bit of this change which affects textureGrad on kepler that I have yet to test, but I'm moderately sure it's correct and was only working by luck before. (Changing the insbf to use

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

assert's get compiled out in release builds, so they can't be relied upon to perform logic. Reported-by: Pierre Moreau <pierre.morrow at free.fr> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2 10.3 10.4" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp | 3 ++-

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- .../drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp index f010767..4a9e48f 100644 ---

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

FILE_MEMORY_GLOBAL is currently only used for buffer handling, as we do not yet have (opencl) global memory support. Global memory support actually requires some different handling during lowering, so rename FILE_MEMORY_GLOBAL to FILE_MEMORY_BUFFER to reflect that the current code is for buffer handling, this will allow the later (re-)addition of FILE_MEMORY_GLOBAL for regular global memory.

Hi, On 16-03-16 15:55, Ilia Mirkin wrote: > This approach leads to the emitters needing to know about both global and > buffer, even though at that point, they are identical. I was thinking that > in the lowering logic, buffer would just get rewritten as global (with the > offset added), thus not needing any change to the emitters. What do you > think about such an approach? I was

https://bugs.freedesktop.org/show_bug.cgi?id=108032 Bug ID: 108032 Summary: nv50_ir_lowering_gm107.cpp:326: undefined reference to `nv50_ir::NVC0LoweringPass::loadMsAdjInfo32(nv50_ir::T exInstruction::Target, unsigned int, int, nv50_ir::Value*, bool)' Product: Mesa Version: git

This approach leads to the emitters needing to know about both global and buffer, even though at that point, they are identical. I was thinking that in the lowering logic, buffer would just get rewritten as global (with the offset added), thus not needing any change to the emitters. What do you think about such an approach? On Mar 16, 2016 2:24 AM, "Hans de Goede" <hdegoede at

Are you sure this won't break compute shaders on fermi? Could you please double-check that? One minor comment below. On 03/17/2016 05:07 PM, Hans de Goede wrote: > Some of the lowering steps we currently do for FILE_MEMORY_GLOBAL only > apply to buffers, making it impossible to use FILE_MEMORY_GLOBAL for > OpenCL global buffers. > > This commits changes the buffer code to use

On 04/08/2016 12:17 PM, Hans de Goede wrote: > Hi, > > On 23-03-16 23:10, Samuel Pitoiset wrote: >> Are you sure this won't break compute shaders on fermi? >> Could you please double-check that? > > I just checked: > > lspci: > 01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT > 610] (rev a1) > > Before this patch-set: >

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 offset. Right now the meaning of global is overloaded - before lowering it

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 that. >> >> The less hacky solution is the one you proposed as #1 - introduce a

On 04/12/2016 12:04 PM, Hans de Goede wrote: > Hi, > > On 08-04-16 18:14, Samuel Pitoiset wrote: >> >> >> On 04/08/2016 12:17 PM, Hans de Goede wrote: >>> Hi, >>> >>> On 23-03-16 23:10, Samuel Pitoiset wrote: >>>> Are you sure this won't break compute shaders on fermi? >>>> Could you please double-check that?

On 03/14/2016 08:50 PM, Hans de Goede wrote: > 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