On Tue, Dec 7, 2010 at 7:54 PM, James Jones <jajo...@nvidia.com> wrote: > On Sunday 05 December 2010 20:31:24 Owen Taylor wrote: ... >> But I can't say that I'm at all happy the idea that we'll have two sets of >> drivers, one where flushing rendering enables an implicit fence for >> subsequent rendering from that buffer, and one where it doesn't. If the >> implicit fence approach is actually less efficient... work being >> pointlessly done, then I say we should just kill it everywhere and move to >> a consistently looser model. > > Agreed. I can't force other drivers to change, but I don't think buffer > accesses should be implicitly fenced by drivers. Two coordinated threads, for > instance, should be able to simultaneously render to two regions of the same > drawable/buffer. OpenGL, and I believe X, allow for this.
But do you think the implicit fencing in inherently less efficient than explicit fencing? I think the flip side to Owens suggestion is that if explicit fencing doesn't allow a performance improvement, then we can't justify pushing this bookkeeping to the clients and making correct damage/GL interaction require it. I have a personal preference on explicit vs implicit fencing as well, and I'm certainly willing to put that aside if there's even a theoretic benefit to explicit fencing. And just to be clear, I don't see implicit fencing affecting write/write contention as in your example above, only the case where you're reading from a buffer that's currently being written to in a different hw context. Is there a way explicit fencing makes this use case faster or does it just add extra latency? Kristian _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel