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

[Jason Ekstrand]

On Tue, Jan 8, 2019 at 11:57 PM 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.
>

I'm fine with reverting it so that Matt can land stuff without the rebase
pain.  I thought it was just going to be one place and I tried to warn him
about it but we probably should have held off a bit longer.


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

Do they? Is it? I'm going to try to convince you that the suggested rename
is at least not terrible and better than what we have today.  We'll see if
you buy it. :-)

The old names made perfect sense in a OpenGL 3.0 world when you look at a
single invocation of a shader.  You have global variables and local
variables just like you do in C.  Then you have inputs, outputs, and
uniforms which are magic globals which get pre-populated with data and/or
data is read from them at the end of the execution; a bit weird, but okay.
Since I/O is really just special globals, you really only have two scopes,
local and global, and local < global in terms of who can access it.

Ok, now step forward into 2019 with OpenGL 4.6, Vulkan, and compute.  We
now have "shared" variables and SSBOs which I'm going to, for the sake of
momentary sanity, call "universal" because they are accessible from all
threads in all stages in all workgroups.  Now we have four scopes and they
go universal > shared > global > local.  Wait, shared > global?  How does
that make sense?  It doesn't, really.  If you take a step back and stop
looking at your shader as if a single invocation is an entire program and
instead look at is as a single invocation of a massively multi-threaded
program, things start to make more sense.  Things that we used to call
"global" are no longer global in the C sense; they're now more of a
thread-local storage.  Compute shared variables aren't global either,
they're a sort of storage that's somewhere between thread-local and
universal which you could call workgroup-local.  Hopefully, you can start
to see where the new names come from.  So what about function-local
variables?  Now that we've got three *-local things, local is getting a bit
overloaded so we drop the "local" and call it "function".  What about what
we used to call "global" but which isn't really global anymore in the C
sense?  We could call it thread but that's a bit overloaded with SIMD since
a thread may contain many invocations.  We could call it "invocation" but
that's a bit long and clumsy so we went with "private" because it's private
in the sense that it's never touched by any other invocations.  I'll grant
that the name "private" is a bit weak but it's what SPIR-V used so we
decided to not be too creative.

If it helps, I hated the rename at first too but I've come to be ok with
it.  I'm not a huge fan of "function" and "private" but I don't really have
anything better and I am firmly convinced that "global" doesn't make sense
anymore.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190109/e0c432bb/attachment.html>