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

[Karol Herbst]

On Wed, Jan 9, 2019 at 6:57 AM Kenneth Graunke <kenneth at whitecape.org> 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.
>
> 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

okay. I wouldn't mind that it gets reverted, the main idea behind it
was, that I have another patch pending reintroducing "global" for
global memory, which we need for kernels anyway and we wanted to run
into those rebase issues exactly because of that. The main conflict
here is that the current naming scheme is based on what the code sees,
but that doesn't help us if we want to express what a thread sees.
What is "global" in the former concept?