Hi, On Mon, Feb 23, 2009 at 3:26 AM, Tomas Frydrych <[email protected]> wrote: > > I do not particularly like this idea on principle, as you are moving > processing from GPU to CPU. Also, it feels like you are trying to > address driver brokenness in Clutter. >
I would say the main win of the patch (after coding it & profiling, see bug) is to keep the round-trips to get the matrix from destroying performance. The round trips have a cost of over 50% frame rate. It's not really a driver issue; it is an indirect rendering issue. I don't think there's a way the GL implementation could fix it other than doing the same thing as this patch (tracking matrix client-side). Question in my mind is whether the Clutter clipping implementation could avoid this round trip; that's probably the ideal fix if so. The round trip is flat-out catastrophic when GL is indirect. To work on indirect Clutter ends up needing a blanket ban on glGet during painting. Since there are only two cases I've found with a get right now (absolute transforms, and clipping), it does seem potentially within reach to simply fix those two cases somehow. But on the other hand, I don't know exactly how. Can also avoid the two cases, but unfortunately for clipping at least, there's often no good alternative, though one of my other patches (ClutterFlattener) does add a different way to clip. Another possible way to look at it is that there could be some nice Clutter enhancements that have been avoided due to fear of round-tripping the matrix, that would be possible with a patch like this. So it could open opportunities. But I don't know if it does. btw, do any GL drivers really do the matrix transforms on GPU? If they do, wouldn't they tend to have an expensive get-current-matrix operation, even when direct, since the matrix would have to be pulled off the GPU? Havoc -- To unsubscribe send a mail to [email protected]
