Am 06.08.2014 17:20, schrieb Ilia Mirkin: > On Wed, Aug 6, 2014 at 11:15 AM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 06.08.2014 17:03, schrieb Ilia Mirkin: >>> 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? >> How so? If you've got 15 samplers declared it is still not legal to >> index into the 15th one if your sampler array is starting at 0 with 5 >> entries (or maybe it is legal but results undefined). That is at least >> my understanding of the spec. (Of course if I'm wrong here then indeed >> sampler arrays are worthless.) > > That is indeed not legal. So right -- you wouldn't see where the > arrays are. But is that really worth worrying about at the TGSI level? > Anyways, I'll send my patch once perl gets unbroken on my system, and > you can rip it apart then :) Doing the array thing would be a giant > complication for what I perceive to be fairly little gain. The thing > is that the information of what's an array where is long lost by the > time the declarations are created -- there's just a bitmask of used > samplers. Oh I wasn't aware of that I thought you got that information pretty easily. Yeah in that case I guess it's not worth bothering. In any case we could tighten that up later if necessary.
Roland >> >>> >>>> 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. >> Yes, but without dynamically indexing into it the sampler array can >> easily be flattened since you always got the corresponding immediate >> "index". That is, it was never addressed as an array in tgsi. >> FWIW this is the same story with d3d10 - resource dcls could be arrays >> but the index had to be an immediate. >> >> Roland >> >> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
