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

[Roland Scheidegger]

Am 20.10.2015 um 15:40 schrieb 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.
> 

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