[Mesa-dev] ARB_cull_distance support v4?

[Roland Scheidegger]

Am 13.05.2016 um 23:12 schrieb Dave Airlie:
> On 14 May 2016 at 01:12, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 13.05.2016 um 06:41 schrieb Dave Airlie:
>>> This is just the core patches, as I think the lowering was pretty
>>> broken in the last couple of reposts.
>>>
>>> The lowering now lowers to one array of 8 or whatever. I need
>>> to recheck the gallium and llvmpipe bits on top of this, as I think
>>> llvmpipe will be broken.
>> Maybe. draw expects separate clip and cull dists, each packed as vec4s
>> (it could probably handle up to 2 vec4 for each).
>>
>>>
>>> I think I'm going to rip out the CULLDIST semantic from gallium,
>>> it really isn't what the hw wants.
>>>
>>
>> I can't really see how the output is going to look like from your
>> change, but there's reasons things are the way they are. This is, of
>> course, all inspired by d3d10 (this even predates the gl cull dist
>> extension) - d3d10 has these weirdo packed vec4. The problem is, in
>> d3d10, you can have a vec4 output declared, with x component being a
>> ordinary output, yz being a clipdist, and w being a cull dist. But in
>> gallium, we can't really have different semantics per output - hence
>> clip and cull must be in different outputs (and nothing else can be
>> packed into the same vars).
>> A single array for clip and cull dist each probably would have been
>> cleaner, but we didn't have input/output arrays for system values
>> neither at that time, so gallium's design is something which looks like
>> neither what gl, d3d10 nor probably hw wants, but was simple enough to
>> translate and worked.
> 
> Ouch d3d10 is ugly here. You'll probably need to patch up your state tracker
> to work with the new code, since I don't have access to it, and I'd prefer
> not to keep the in-tree code too messy just to support something crazy like
> the above.
> 
> Hopefully it should be easy enough to translate to the new scheme, since at
> least most of the hardware seems to work off either vec4[2], or
> float[8] and some
> bitmask.

Yes, shouldn't be much of a problem, since we already had to do lots of
translation. (Initially, there were not actually any properties
associated with clip/cull dists, the number of components was figured
out from the mask of the register. That stopped working though when
Marek changed those inputs to be potentially arrays. I hope that still
works...)

Roland