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

[Ilia Mirkin]

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.

  -ilia