On Wed, Aug 6, 2014 at 10:52 AM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 06.08.2014 13:00, schrieb Marek Olšák: >> On Wed, Aug 6, 2014 at 4:02 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> On Tue, Aug 5, 2014 at 5:25 PM, Roland Scheidegger <srol...@vmware.com> >>> wrote: >>>> From a gallium perspective, indirect temp regs are already working - so >>>> something like >>>> MOV TEMP[0], TEMP[TEMP[1].x] should work. >>>> Indirect registers are supported for inputs, outputs, temps, constants, >>>> and immediates even, but the indirect reg itself must come from a temp >>>> or address reg (I am not 100% certain where that restriction comes >>>> from). I have no idea which drivers support it, all I can tell is that >>>> it works with llvmpipe. >>>> I sort of doubt it is supported for samplers right now in gallium though >>>> technically it might be possible to express this already. >>> >>> Well, with my limited patch + ChrisF's small patches to mesa core, the >>> dynamic sampler stuff works for nvc0, except for the issues I >>> outlined. Not sure what you mean by "supported in gallium". Perhaps I >>> have an incorrect view of things, but I see gallium as an amorphous >>> thing that we can change to our heart's content. >>> >>>> A cap bit for the ability to support dynamic indexing of shaders (plus >>>> whatever is needed for making it work like declaration of sampler >>>> arrays) would certainly be needed in any case. For drivers supporting >>> >>> Right... so it's not like shaders will start magically containing >>> these things, it'll only happen if ARB_gs5 is enabled (probably via >>> PIPE_CAP_GLSL >= 400). Which presumably means that the backend >>> supports whatever we're throwing at it. >>> >>>> this I would certainly expect them to allow temp regs as the indirect >>>> reg. I guess it would be nice if we'd just use temp regs instead of >>>> address reg in glsl to tgsi conversion if a driver supports it. I think >>>> for modern drivers this makes a lot more sense than trying to shove >>>> everything into address regs. >>> >>> Agreed. With the exception that I guess we also need to support >>> indexing with float values? (i.e. ARL) This would have to be treated >>> with some care. Not sure when that comes up though... perhaps only if >>> !native_integers, which won't be an issue with any of the hw that >>> we're talking about. >> >> If you really want to lower ARL into a temp, I recommend using F2I, >> which is equivalent in behavior. For UARL, MOV will do. >> >> Also, I don't think GLSL sampler arrays have to be declared as arrays >> in TGSI. Array declarations are really only needed for TEMPs, because >> they allow better register allocation. Every other shader resource has >> a fixed location and would not benefit from it. > I think not requiring them to be declared as an array is a bad idea. It > may well be true that hw drivers can't really benefit from it but in any > case it would be trivial to handle in the drivers. It gives you the > ability to easily see what values are legal in the end as a sampler > index, might help with debugging at some day. Besides, it's just bad
You would see that based on the declarations anyways, no? > style imho to index into things which aren't arrays, that is applicable > to all languages, so I can't see why it should be different for tgsi. > But I guess it's not all _that_ important. Well, it might be important to put this in some context -- sampler arrays are perfectly legal in GLSL today. What's not legal in pre-gs5 glsl (although based on some commends glsl 110 might have allowed it) are the dynamic indices. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
