Am 13.05.2016 um 23:12 schrieb Dave Airlie: > On 14 May 2016 at 01:12, Roland Scheidegger <srol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev