[Mesa-dev] [PATCH 2/4] gallium: add new properties for clip and cull distance usage

Roland Scheidegger sroland at vmware.com
Tue Oct 20 06:25:20 PDT 2015


Am 19.10.2015 um 23:44 schrieb Marek Olšák:
> On Mon, Oct 19, 2015 at 11:31 PM, Roland Scheidegger <sroland at 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.
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).

Roland



More information about the mesa-dev mailing list