similar to: [Bug 108032] New: nv50_ir_lowering_gm107.cpp:326: undefined reference to `nv50_ir::NVC0LoweringPass::loadMsAdjInfo32(nv50_ir::TexInstruction::Target, unsigned int, int, nv50_ir::Value*, bool)'

https://bugs.freedesktop.org/show_bug.cgi?id=100177 Bug ID: 100177 Summary: [GM206] Misrendering in XCOM Ennemy Within Product: Mesa Version: 17.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee:

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

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

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

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

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=111167 Bug ID: 111167 Summary: Dividing zero by a uniform in loop header causes segfault in nv50_ir::NVC0LegalizeSSA::handleDIV Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor

https://bugs.freedesktop.org/show_bug.cgi?id=111218 Bug ID: 111218 Summary: Segmentation fault in nv50_ir::NVC0LegalizeSSA::handleDIV when dividing result of textureSize Product: Mesa Version: 19.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major

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 FILE_MEMORY_BUFFER at the ir_from_tgsi and lowering steps, freeing use of FILE_MEMORY_GLOBAL for use with OpenCL global buffers. Note that after lowering buffer accesses use the

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

There is no dedicated instruction for this, so just combine it with the constant offset. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.3" <mesa-stable at lists.freedesktop.org> --- This fixes the spec/glsl-1.50/execution/geometry/dynamic_input_array_index piglit test. src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_gm107.cpp | 5 ++++- 1 file changed,

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: [hans at plank piglit]$ ./piglit run -o shader -t '.*arb_shader_storage_buffer_object.*' results/shader

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

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? >> >> I just checked: >> >> lspci: >> 01:00.0 VGA compatible

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?

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 >

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