On Fri, Jan 11, 2019 at 8:50 PM Kenneth Graunke <kenn...@whitecape.org> wrote: > > On Friday, January 11, 2019 9:32:20 AM PST Eric Anholt wrote: > > Jason Ekstrand <ja...@jlekstrand.net> writes: > > > > > On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke <kenn...@whitecape.org> > > > wrote: > > > > > >> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote: > > >> > On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote: > > >> > > Those names (nir_var_func_local, nir_var_thread_local, and > > >> > > nir_var_thread_global) make more sense to me than private/function. > > >> > > > > >> > > Another option is `nir_var_local_temp` and `nir_var_shader_temp`, > > >> > > indicating that they're just temporary variables, and not anything > > >> > > with special semantics like memory. shader_temp would pair well with > > >> > > the existing shader_in/shader_out, since they have the same scope. > > >> > > > > >> > > I might also consider adding 'mem' to variables representing memory. > > >> > > > > >> > > So that would look like... > > >> > > > > >> > > nir_var_shader_in > > >> > > nir_var_shader_out > > >> > > nir_var_shader_temp (formerly local/function) > > >> > > nir_var_local_temp (formerly global/private) > > >> > > > > >> > > > >> > Are those flipped? > > >> > > >> Gah! Sorry. Yes. > > >> > > >> nir_var_shader_in > > >> nir_var_shader_out > > >> nir_var_shader_temp (formerly global/private) > > >> nir_var_local_temp (formerly local/function) > > >> nir_var_uniform > > >> nir_var_system_value > > >> nir_var_mem_ubo (added mem) > > >> nir_var_mem_ssbo (added mem) > > >> nir_var_mem_shared (added mem) > > >> nir_var_mem_global (the new global memory type being introduced) > > >> > > > > > > I can work with that. I do think I'd mildly prefer function_temp over > > > local_temp but I think the adding of _temp is an improvement. > > > > I like the _temp suggestion a lot! And I think I'm also mildly in favor > > of function_temp. > > > > (Also, thanks to taking naming seriously, to everyone involved here. > > It's hard.) > > Yep, it's not easy. Karol, sorry for being grumpy the other day, it > wasn't a very constructive email on my part. I agree that the names > should change, for all the reasons you suggested. >
no worries. I should have probably pinged a few more people, especially with a patch like that. > > --Ken _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev