<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jan 8, 2019 at 11:57 PM Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:<br>
> the naming is a bit confusing no matter how you look at it. Within SPIR-V<br>
> "global" memory is memory accessible from all threads. glsl "global" memory<br>
> normally refers to shader thread private memory declared at global scope. As<br>
> we already use "shared" for memory shared across all thrads of a work group<br>
> the solution where everybody could be happy with is to rename "global" to<br>
> "private" and use "global" later for memory usually stored within system<br>
> accessible memory (be it VRAM or system RAM if keeping SVM in mind).<br>
> glsl "local" memory is memory only accessible within a function, while SPIR-V<br>
> "local" memory is memory accessible within the same workgroup.<br>
> <br>
> v2: rename local to function as well<br>
> <br>
> Signed-off-by: Karol Herbst <<a href="mailto:kherbst@redhat.com" target="_blank">kherbst@redhat.com</a>><br>
<br>
I strongly dislike this patch, and I think we ought to revert it.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This probably makes sense from an OpenCL memory-model view of the world,<br>
but it's really confusing from a compiler or general programming point<br>
of view.<br>
<br>
/Everybody/ knows what a local variable is.  It's one of the most used<br>
concepts in programming.  Calling it nir_var_function is very confusing.<br>
The variable is a...function?  Maybe it's a function pointer?  Neither<br>
of those things even exist in GLSL, so...what the heck is it?<br></blockquote><div><br></div><div>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. :-)</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>--Jason<br></div></div></div>