[Mesa-dev] ARB_cull_distance support v4?

[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.

Dave.