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 <kher...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
