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

[Karol Herbst]

On Thu, Jan 10, 2019 at 1:06 PM Karol Herbst <kherbst at redhat.com> wrote:
>
> 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.
> >
>
> The old nir_var_global is
> really something like thread_private memory accessible from everywhere
> within the thread.
>

actually I was jumping between lines and the name
"nir_var_thread_local" would actually fit.

> > > 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