[Mesa-dev] [PATCH 05/12] nir: rename global/local to private/function memory

[Ian Romanick]

On 1/8/19 9:57 PM, Kenneth Graunke wrote:
> On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
>> the naming is a bit confusing no matter how you look at it. Within SPIR-V
>> "global" memory is memory accessible from all threads. glsl "global" memory
>> normally refers to shader thread private memory declared at global scope. As
>> we already use "shared" for memory shared across all thrads of a work group
>> the solution where everybody could be happy with is to rename "global" to
>> "private" and use "global" later for memory usually stored within system
>> accessible memory (be it VRAM or system RAM if keeping SVM in mind).
>> glsl "local" memory is memory only accessible within a function, while SPIR-V
>> "local" memory is memory accessible within the same workgroup.
>>
>> v2: rename local to function as well
>>
>> Signed-off-by: Karol Herbst <kherbst at redhat.com>
> 
> I strongly dislike this patch, and I think we ought to revert it.
> 
> This probably makes sense from an OpenCL memory-model view of the world,
> but it's really confusing from a compiler or general programming point
> of view.
> 
> /Everybody/ knows what a local variable is.  It's one of the most used
> concepts in programming.  Calling it nir_var_function is very confusing.
> The variable is a...function?  Maybe it's a function pointer?  Neither
> of those things even exist in GLSL, so...what the heck is it?
> 
> Renaming global scope variables to "private" is also confusing IMO.
> They're certainly not private to a function.  They're globally
> accessible by anything in the whole shader.  I'll admit "global" isn't
> a great name either.

It seems like the concepts we're after a function local and thread
local, so why not nir_var_thread_local (for old nir_var_global) and
nir_var_function_local (for old nir_var_local).  When "global" is
reintroduced to mean thread global, we could add it as
nir_var_thread_global.  That seems to match at least one reasonable view
of a storage hierarchy.

> I think we need to discuss this more.  There are people with large
> series of outstanding work that now have to rebase on this flag day
> rename, and I don't think two people is enough consensus for renaming
> a core IR concept.  Can we find names we're all happy with?
> 
> --Ken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190109/cc5aec5e/attachment.sig>