search for: file_memory_buffer

.../gallium/drivers/nouveau/codegen/nv50_ir.h > index fdc2195..5141fc6 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h > @@ -333,6 +333,7 @@ enum DataFile > FILE_SHADER_INPUT, > FILE_SHADER_OUTPUT, > FILE_MEMORY_BUFFER, > + FILE_MEMORY_GLOBAL, > FILE_MEMORY_SHARED, > FILE_MEMORY_LOCAL, > FILE_SYSTEM_VALUE, > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp > index 02a1101..62f1598 100644 > ---...

...ase 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] = 0xe0000000; code[0] = 0x00000000; break; - case FILE_MEMORY_LOCAL: code[1] = 0x7a800000; code[0] = 0x00000002; break; + case FILE_MEMORY_BUFFER: + case FILE_MEMORY_GLOBAL: + code[0] = 0x00000000; + code[1] = 0xe0000000; + break; + case FILE_MEMORY_LOCAL: + co...

...rivers/nouveau/codegen/nv50_ir.h b/src/gallium/drivers/nouveau/codegen/nv50_ir.h index fdc2195..5141fc6 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.h +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.h @@ -333,6 +333,7 @@ enum DataFile FILE_SHADER_INPUT, FILE_SHADER_OUTPUT, FILE_MEMORY_BUFFER, + FILE_MEMORY_GLOBAL, FILE_MEMORY_SHARED, FILE_MEMORY_LOCAL, FILE_SYSTEM_VALUE, diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp index 02a1101..62f1598 100644 --- a/src/gallium/drivers/nouveau/codegen...

...oede" <hdegoede at redhat.com> wrote: > 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. > > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- > src/gallium/drivers/nouveau/codegen/nv50_ir.h...

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>

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. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir.h | 2 +- src/gallium/drive...

...g by others I believe. Questions: 1) Any tests I can run to test the buffer paths ? 2) So the resulting patch, which would replace this one, and make most of the "nouveau: codegen: Add support for OpenCL global memory buffers" unnecessary would look something like this: 2a) Add FILE_MEMORY_BUFFER as nv50_ir::FILE_* type 2b) Use it in nv50_ir_from_tgsi.cpp instead of GLOBAL 2c) Use it in nv50_ir_lowering_ to check for buffer accesses, and when adding the offset change the file_type to GLOBAL Right ? Regards, Hans > On Mar 16, 2016 2:24 AM, "Hans de Goede" <hdegoede...

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 FILE_MEMORY_GLOBAL register file. Tested with piglet on a gk107, before this patch: ./piglit run -o shader -t '.*arb_shader_storage_bu...

...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 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 FILE_MEMORY_GLOBAL > register file. > > Tested with piglet on a gk107, before this patch: > ./piglit run -o...

...t; 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 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 FILE_MEMORY_GLOBAL >> register file. >> >> Tested with piglet on a gk107, before this...

...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 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 FILE_MEMORY_GLOBAL >>> register file. >>> >>> Tested with pig...

...>> 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 FILE_MEMORY_GLOBAL >>>>> register file. &...

...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 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 FILE_MEMORY_GLOBAL >>>> register file. >>>> >...

...sus TGSI_FILE_MEMORY with TGSI_MEMORY_TYPE_GLOBAL, looking at translateFile() we currently have: case TGSI_FILE_BUFFER: return nv50_ir::FILE_MEMORY_GLOBAL; case TGSI_FILE_MEMORY: return nv50_ir::FILE_MEMORY_GLOBAL; So doing a s/nv50_ir::FILE_MEMORY_GLOBAL/nv50_ir::FILE_MEMORY_BUFFER/ everywhere and then adding a new FILE_MEMORY_GLOBAL seems like an obvious fix. But I'm afraid that we will have similar issues with OpenCL using flat addresses where as GLSL will have some implied base-address / offset in other places too, which brings me to solution 2: 2) Add...

...>> translateFile() >> we currently have: >> >> case TGSI_FILE_BUFFER: return nv50_ir::FILE_MEMORY_GLOBAL; >> case TGSI_FILE_MEMORY: return nv50_ir::FILE_MEMORY_GLOBAL; >> >> So doing a s/nv50_ir::FILE_MEMORY_GLOBAL/nv50_ir::FILE_MEMORY_BUFFER/ >> everywhere and then adding a new FILE_MEMORY_GLOBAL seems like an >> obvious fix. >> >> But I'm afraid that we will have similar issues with OpenCL using >> flat addresses where as GLSL will have some implied base-address / >> offset i...

...>>>> >>>> case TGSI_FILE_BUFFER: return nv50_ir::FILE_MEMORY_GLOBAL; >>>> case TGSI_FILE_MEMORY: return nv50_ir::FILE_MEMORY_GLOBAL; >>>> >>>> So doing a >>>> s/nv50_ir::FILE_MEMORY_GLOBAL/nv50_ir::FILE_MEMORY_BUFFER/ >>>> everywhere and then adding a new FILE_MEMORY_GLOBAL seems like an >>>> obvious fix. >>>> >>>> But I'm afraid that we will have similar issues with OpenCL using >>>> flat addresses where as GLSL will have some impl...

..._MEMORY_TYPE_GLOBAL, looking at > translateFile() > we currently have: > > case TGSI_FILE_BUFFER: return nv50_ir::FILE_MEMORY_GLOBAL; > case TGSI_FILE_MEMORY: return nv50_ir::FILE_MEMORY_GLOBAL; > > So doing a s/nv50_ir::FILE_MEMORY_GLOBAL/nv50_ir::FILE_MEMORY_BUFFER/ > everywhere and then adding a new FILE_MEMORY_GLOBAL seems like an > obvious fix. > > But I'm afraid that we will have similar issues with OpenCL using > flat addresses where as GLSL will have some implied base-address / > offset in other places too, which bri...

...we currently have: >>> >>> case TGSI_FILE_BUFFER: return nv50_ir::FILE_MEMORY_GLOBAL; >>> case TGSI_FILE_MEMORY: return nv50_ir::FILE_MEMORY_GLOBAL; >>> >>> So doing a >>> s/nv50_ir::FILE_MEMORY_GLOBAL/nv50_ir::FILE_MEMORY_BUFFER/ >>> everywhere and then adding a new FILE_MEMORY_GLOBAL seems like an >>> obvious fix. >>> >>> But I'm afraid that we will have similar issues with OpenCL using >>> flat addresses where as GLSL will have some implied base-address / &...

...R: return >>>>> nv50_ir::FILE_MEMORY_GLOBAL; >>>>> case TGSI_FILE_MEMORY: return >>>>> nv50_ir::FILE_MEMORY_GLOBAL; >>>>> >>>>> So doing a >>>>> s/nv50_ir::FILE_MEMORY_GLOBAL/nv50_ir::FILE_MEMORY_BUFFER/ >>>>> everywhere and then adding a new FILE_MEMORY_GLOBAL seems like an >>>>> obvious fix. >>>>> >>>>> But I'm afraid that we will have similar issues with OpenCL using >>>>> flat addresses where as GLSL...