Current DRI3 specification

[James Jones]

On 06/05/2013 06:20 PM, Keith Packard wrote:
> * PGP Signed by an unknown key
>
> James Jones <jajones at nvidia.com> writes:
>
>> I read through this and the extension specification below.  The DRI3
>> stuff doesn't directly affect our driver at the moment of course, but I
>> like the direction it's going and the proposed/implied interactions
>> between DRI3 and Present.
>
> Thanks much for the review. I think the most relevant question for the
> binary nVidia driver is whether you think you can do something similar
> in terms of mapping your back buffers into X pixmaps for use by
> Present.

Yeah, I think the semantics are compatible.  We allocate these buffers 
on the server-side, but I don't think that affects the interaction with 
Present.

> Oh, I'm curious if you think we should be mapping the OML_sync_control
> UST/MSC/SBC triplet into Sync extension counters. It sure seems like a
> natural fit to me, and would reduce the size of the Present extension
> quite a bit.

I've never been fond of the OML triplet because the values don't 
correspond well to the counters/clocks our HW has.  However, it was 
always the intent that there would be a bunch of external-event 
triggered types of fences added via other extensions (trigger at a given 
timer value, when a certain scanline is reached, triggered while in the 
vblank region or a certain bracketed set of scanlines, etc.)

Perhaps rather than merge these into sync or present, there could be 
small, separate extensions that introduce various new ways to create a 
fence sync object with these properties.  One such extension could 
introduce the OML values either as a combined fence object, or as 3 
separate objects.  I had imagined the "present" operation would take an 
arbitrary length ordered list of fence sync objects to wait for, which 
would be passed down to drivers where they could be collapsed when 
possible.  For example, if the HW or kernel driver supports waiting for 
the first vblank after a given timer value was reached as a single 
operation, the fence sequence { TIMER, VBLANK } could be collapsed into 
a single HW/kernel wait operation by the corresponding X driver.

Thanks,
-James

>> I read through your futex-based fence sync implementation notes as well.
>>    Seems reasonable to me.  I didn't try too hard to poke holes in it
>>    though.
>
> I've had a couple of other positive reviews of that code; obviously it's
> going to take some actual failures before people figure out why it
> doesn't work right :-)
>