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

[Karol Herbst]

On Thu, Jan 10, 2019 at 2:33 AM Ian Romanick <idr at freedesktop.org> wrote:
>
> 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.
>

"function local" doesn't make that much sense, because only SPIR-V has
a concept of function memory, which are usually just variables
(usually stored as SSA values instead except you take an address of
the variable and then it becomes function memory) and parameters where
we end up using the old nir_var_local. The old nir_var_global is
really something like thread_private memory accessible from everywhere
within the thread.

I don't really like the name "nir_var_thread_global" because what's
that supposed to mean? Is it global from within the thread? Or are all
threads able to access it? But then nir_var_global might still be
better, because it's really memory accessible from basically
everything. In worst case, it can also be accessed from various GPU
engines or even a CPU even while the shader is still running (keeping
SVM in mind). "nir_var_memory" might be also a possible name, but
memory can be everything. In the end it is really something globally
accessible by nearly everything.

> > 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
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev