Current DRI3 specification

[James Jones]

On 06/07/2013 10:10 AM, Keith Packard wrote:
> * PGP Signed by an unknown key
>
> James Jones <jajones at nvidia.com> writes:
>
>> 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.
>
> DRI2 allocates them server-side as well for GLX compliance, but with the
> way Intel hardware does MSAA, it's just not feasible to allow for
> multi-process rendering to the same buffers so I've given up any
> pretense.
>
>> I've never been fond of the OML triplet because the values don't
>> correspond well to the counters/clocks our HW has.
>
> Yeah, I haven't found anyone who likes the OML stuff, but it's the spec
> we have...
>
>> 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.)
>
> I'm not sure how general I want to try and make this. As far as I can
> understand it, applications want to display no faster than frame rate,
> and tear if they go over time on a frame. Just getting to that will
> probably be complicated enough without adding the ability to sync to
> other mechanisms.
>
>> 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.
>
> I think Fence objects are completely unrelated to the display system --
> Fence objects provide a way to serialize GPU access to the underlying
> render buffers. Trying to stir those up into more general counters that
> provide precise times when buffers get displayed seems confusing to me.

Fences are just abstract boolean barriers that can be used to 
synchronize graphics with other stuff.  I don't see them as inherently a 
part or excluded from any particular sub-system.

> Having them as simple Sync counters might make sense, the chief trouble
> there is that OML links the three values together, and Sync doesn't
> support that notion.
>
>> 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.
>
> Do you actually need this, or would it just be 'cool'? I don't have
> anyone asking for anything like this, just the simple 'make it pretty'
> requirement described above.

We don't need it to be this general.  I'd just like to solve present 
synchronization once and for all, and this seems like a logical way to 
do so.  The interface and the naive implementation don't seem that much 
more complex than what you have already IMHO.

We do need more than the 'make it pretty' requirement above though. 
What you describe is what interactive rendering apps want, when you're 
translating some sort of input into graphics with as little latency as 
possible.  Video/streaming apps would rather queue up several frames as 
close to the HW presentation mechanism as possible to avoid hiccups, but 
have precise control over when the frames present so they can still do 
A/V sync right with the longer queues.  That's where the OML-type stuff 
with counters and timers becomes interesting.  Those are the two 
important scenarios I know of right now.  I can't say for certain others 
don't exist.

Thanks,
-James