[Mesa-dev] [PATCH 08/17] tgsi/ureg: add shared variables support for compute shaders

[Marek Olšák]

On Tue, Jan 26, 2016 at 9:48 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Tue, Jan 26, 2016 at 3:23 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> On Tue, Jan 26, 2016 at 3:12 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> On Tue, Jan 26, 2016 at 8:57 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> On Tue, Jan 26, 2016 at 2:25 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>> I'd be fine with a new TGSI_FILE_MEMORY which provided options for
>>>>> shared, global, and local(/private?) memory. I believe the old
>>>>> TGSI_FILE_RESOURCE had support for these in a hacky way, this would be
>>>>> the clean way of doing it.
>>>>
>>>> I think they mean:
>>>> global = global shared memory
>>>> local = shared within a thread group (GL "shared memory")
>>>> private = ???
>>>
>>> memory that is local to a thread.
>>>
>>>>
>>>> ureg_DECL_local_temporary seems like a good match. I'd prefer to have
>>>> a separate file though.
>>>>
>>>> Shared memory is the same as TEMPs, except that they are TEMPs shared
>>>> within a thread group.
>>>
>>> It's much more of a memory area than a TEMP area though. TEMP's imply
>>> 16-byte wide stride for indirect indexing, etc -- not easy to work
>>> with.
>>
>> Yeah, TGSI implies that. If you want just loads, stores, and atomics
>> without declarations, you can add TGSI_FILE_SHARED. If drivers get
>> instructions with TGSI_FILE_SHARED in the resource operand, they can
>> just assume it's a load/store/atomic on the shared memory. For
>> example:
>>
>> LOAD TEMP[0], SHARED, address
>>
>> Note that I deliberately didn't type "SHARED[0]" to show that the
>> index should be ignored.
>>
>> In order to prevent confusion, please try to avoid using the word
>> "memory" without the word "shared", because shared memory is not a
>> typical memory resource. It's actually closer to registers in my
>> opinion.
>
> Hm... well on NVIDIA hardware it's accessed the same as any other
> memory area, like global memory, local memory, or constbufs. Same
> types of opcodes too... loads + stores. And GLSL/OpenCL want to be
> able to perform atomic operations on it too. Feels a lot more like
> memory to me than registers. But of course what are registers but
> super-mega-fast memory :)
>
> Sicne we eventually want to allow OpenCL TGSI to work, and from the
> looks of it, OpenCL *really* wants to just be able to pass in any
> number of pointers it feels like, and not be limited to N resources,
> we'll also need global and local (or private, as OpenCL calls it), in
> addition to shared.
>
> So I think a TGSI_FILE_MEMORY file would make sense, where you could
> specify in the declaration whether that specific one refers to
> global/shared/local somehow.

Can you give me a TGSI example how it should look like?

Thanks,
Marek