Am 20.10.2015 um 15:40 schrieb Marek Olšák: > On Tue, Oct 20, 2015 at 3:25 PM, Roland Scheidegger <srol...@vmware.com> > wrote: >> Am 19.10.2015 um 23:44 schrieb Marek Olšák: >>> On Mon, Oct 19, 2015 at 11:31 PM, Roland Scheidegger <srol...@vmware.com> >>> wrote: >>>> Yes, but I still don't see much change from getting this information >>>> from the property rather than how tgsi_scan does it now, which is by >>>> just using the usage mask from the output declaration. So the writes >>>> shouldn't have to be analyzed. >>>> (There's also a slight change in patch 4/4, namely these outputs >>>> absolutely must be in order (xyzw) now as usage mask is determined >>>> solely by the number of values. That might already have been the case at >>>> least for some drivers and is probably ok for other state trackers too, >>>> it wasn't in the docs however.) >>> >>> DCL OUT[1..2], ARRAY(1), CLIPDIST >>> >>> CLIPDIST became an array declaration recently, so the usage mask isn't >>> useful unless it's extended to 8 bits. >>> >>> Also, st/mesa doesn't set the usage mask for anything, so I wonder >>> whether we need it. >>> >>> Marek >>> >> >> Actually thinking about this some more, the problem here really is that >> we have vec4 only, but clip/culldist are scalar outputs. Thus, an array >> size of 2 doesn't give you the information how many elements the array >> actually has and needs to be put somewhere else. Can you actually >> dynamically index into such an array? You'd have to translate the scalar >> index to vec4 array index + component. > > Yes, I believe that's what the GLSL compiler does - it divides the > index by 4 and does some kind of vec4-extract-element operation. > >> I guess another possibility instead of properties would be to encode >> this scalar array information directly into the declaration instead, >> tgsi_declaration for instance would have spare bits, and >> tgsi_declaration_array even more so. >> Albeit properties should be fine for now, it doesn't feel very clean (as >> I can't really see a reason why this is "side-channel" information >> rather than directly part of the register declaration). > > Well, do we really need the usage mask? There are no real users (maybe > nine), vec4 backends typically don't care about usage masks and > optimizing scalar backends can walk the shader and check writemasks on > the outputs. >
Honestly I don't see much point in removing that information. If the state tracker doesn't emit it, that's really the fault of the state tracker - some drivers do something with that information. Also, this is really a somewhat orthogonal issue to missing the scalar array information for clip/cull dist (except that of course for non-vec4 arrays UsageMask doesn't make sense). Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
