similar to: [PATCH mesa v2 1/2] nouveau: codegen: Use FILE_MEMORY_BUFFER for buffers

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

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

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

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>

Could you please get rid of the cosmetic changes (eg. the switch ones)? Because this doesn't really improve readability and in my opinion these changes should be eventually done in a separate patch. Other than that, this patch is : Reviewed-by: Samuel Pitoiset <samuel.pitoiset at gmail.com> Yes, this probably won't work as is for atomic operations but the lowering pass is

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

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

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 >

Add support for OpenCL global memory buffers, note this has only been tested with regular load and stores and likely needs more work for e.g. atomic ops. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 + .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 31 +++++++++++++++++-----

Hi, On 16-03-16 11:37, Samuel Pitoiset wrote: > Could you please get rid of the cosmetic changes (eg. the switch ones)? > Because this doesn't really improve readability and in my opinion these changes should be eventually done in a separate patch. I need at least halve of those cosmetic changes, because half of them is not cosmetic, e.g. : - case FILE_MEMORY_BUFFER: code[1] =

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

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

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

This is enough to enable tessellation support on nvc0. It seems to work a lot better on my GF108 than GK208. I suspect that there's some sort of scheduling shenanigans that need to be adjusted for kepler+. Or perhaps some shader header things. Even with the GF108, I still get occasional blue triangles in Heaven, but I get a *ton* of them on the GK208 -- seemingly the same issue, but it's

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