Fence Sync patches

[Kristian Høgsberg]

On Tue, Dec 7, 2010 at 7:54 PM, James Jones <jajones at 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