Fence Sync patches

[Francisco Jerez]

James Jones <jajones at nvidia.com> writes:

> On Sunday 05 December 2010 20:31:24 Owen Taylor wrote:
>[...]
>> Something like this was the first thing that came to mind (well, not the
>> sequence number, since those are per-client, but say associating an XSync
>> counter with the damage object.) I don't think it's very hard to work
>> around the 64-bit issue, at least for >=, but I can understand the
>> reluctance to spec out something new going beyond current GL
>> synchronization primitives and assume that it will be implementable on all
>> hardware.
>>
>> [ This is the basic advantage that the implicit fence approach has - since
>>   the fences are being inserted at the driver level, they can be done
>> however works out right for that hardware without needing a common
>> abstraction ]
>
> On the contrary, I think this is a disadvantage.  With explicit, boolean 
> fences, there's no need to worry about wrapping semantics and no need to use 
>>= type logic.  The value waited for is True, the initial state is False.  The 
> client specifies which fence to wait for and what conditions cause it to become 
> Triggered, or True.
>
> With the server issuing implicit fences, it has no way to know whether the 
> client will ever bother to wait for the fence or a particular fence value.  
> Therefore, it needs to be able to continuously, asynchronously update the 
> value with the understanding that the client will wait for a particular fence 
> value using range comparisons rather than equality comparisons, or generate an 
> unbounded number of fences for the client to wait for.
>  
No, implicit fencing doesn't require ">=" style comparisons, actually it
could be implemented internally in terms of your Fence Sync API,
basically you could do exactly the same you've been suggesting Owen to
do, inside your 3D driver.

IOW, the driver could keep a ring of fences, and at the beginning of
each frame it would ask the server to trigger one of them if it turns
out to be texturing from a shared pixmap. I really don't see why making
your proprietary driver comply with the established behavior is such a
big deal.

>> > -Have the server generate a sync object ID, trigger it, and send that
>> > with the damage event if clients opt-in some how.  This seemed very
>> > anti-X design (clients should create, or at least name, transient
>> > resources), and has the potential of generating tons and tons of objects
>> > if the client forgets to delete them or can't keep up with the damage
>> > events.  Also, importing X sync objects to GL is expensive, so it's
>> > desirable to make that a startup-time operation.
>[...]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101208/6c63f754/attachment.pgp>