On Thu, Jan 10, 2019 at 1:06 PM Karol Herbst <kher...@redhat.com> wrote: > > On Thu, Jan 10, 2019 at 2:33 AM Ian Romanick <i...@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 <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. > > > > 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@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
