search for: file_memory_glob

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

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

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

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

...gen/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/nouv...

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>

...: 9 / After this patch-set: [hans at plank piglit]$ ./piglit run -o shader -t '.*arb_shader_storage_buffer_object.*' results/shader [9/9] pass: 9 / > 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 FILE_MEMORY_BUFFER at the >> ir_from_tgsi and lowering steps, freeing use of FILE_MEMORY_GLOBAL >> for use w...

...atch. 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: + code[0] = 0x00000002; + code[1] = 0x7a800000; + break; The first bit actually changes things to have 2 cases for the BUFFER code, an other way of writing this would be: + case...

...v50_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/nv50_ir_emit_gk110.cp...

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

...0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GT 740] (rev a1) Same result. Regards, Hans > >> >>> 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 FILE_MEMORY_BUFFER at the >>>> ir_from_tgsi and lowering steps, freeing use...

...s: 9 / And what about compute shaders? (ie. -t arb_compute_shader) Sorry to ask you again but I just want to be sure it's fine. :-) > >> 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 FILE_MEMORY_BUFFER at the >>> ir_from_tgsi and lowering steps, freeing use of FILE_MEMORY_GLOBA...

...t <samuel.pitoiset at gmail.com> > > Regards, > > Hans > > > >> >>> >>>> 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 FILE_MEMORY_BUFFER at the >>>>> ir_from_tgsi and lowering...

...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, 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 OpenC...

...ns come to mind: >> >> 1) Use separate nv50_ir::FILE_MEMORY_xxx values for buffers versus >> 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. >> >>...

...e separate nv50_ir::FILE_MEMORY_xxx values for buffers versus >>>> 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 lik...

...e > 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, 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 wi...

...; >>> 1) Use separate nv50_ir::FILE_MEMORY_xxx values for buffers versus >>> 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 >>>...

...s for buffers versus >>>>> 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...

..._gk110.cpp index 0d7d95e..70f3c3f 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp @@ -1655,10 +1655,8 @@ CodeEmitterGK110::emitSTORE(const Instruction *i) break; } - if (i->src(0).getFile() != FILE_MEMORY_GLOBAL) - offset &= 0xffffff; - if (code[0] & 0x2) { + offset &= 0xffffff; emitLoadStoreType(i->dType, 0x33); if (i->src(0).getFile() == FILE_MEMORY_LOCAL) emitCachingMode(i->cache, 0x2f); -- 2.7.2