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

[Marek Olšák]

On Tue, Oct 20, 2015 at 3:25 PM, Roland Scheidegger <sroland at 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 <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.

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.

Marek