Current DRI3 specification

[James Jones]

On 06/08/2013 11:18 AM, Daniel Stone wrote:
> Hi,
>
> On 7 June 2013 13:30, James Jones <jajones at nvidia.com> wrote:
>> 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.
>
> This is only true to the extent that the entire pipeline is totally
> predictable in terms of latency;

That doesn't sound right to me.  I would think you want what I described 
above in high-latency or fluctuating latency situations, where you want 
to accurately do something a few hundred milliseconds in the future, 
rather than inaccurately do something ASAP.  The synchronization is 
supposed to happen at the end of the pipeline, where more accuracy is 
possible.

> given that isn't even remotely true
> with these kinds of system, timing feedback, to allow clients to
> adjust accordingly, is more important.  GStreamer, for example, has
> really detailed code to feed back in frame timestamps and use the
> actual, rather than predicted, presentation time to adjust its clock.

Yes, if your system doesn't allow accurate semi-high latency 
presentation, that's what you'd want.  This idea is for a system that 
does allow accurate presentation after a series of 
maybe-not-so-predictable-latency operations though.  I think ideally, 
you have both:  A framework that allows reliable latency when the 
HW/driver supports it, AND accurate feedback to handle the situations 
where the driver or hardware can't provide sufficiently reliable 
presentation.  I'm certainly not opposed to feedback mechanisms.

This isn't theoretical either.  We have robust implementations of the 
high latency/accurate mechanism in VDPAU and GL_NV_present_video:

ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/group___vdp_presentation_queue.html

http://www.opengl.org/registry/specs/NV/present_video.txt

The general "list of fences" mechanism is theoretical at the moment, but 
is the logical next step in generalizing both the high latency/reliable 
and low-latency/best effort mechanisms IMHO.  Over the past few years, 
it's proven interesting to have mechanisms to synchronize graphics 
processing at the front and end of the graphics pipeline (GL fences, EGL 
fences, X fence syncs to a lesser extent).  Having a similarly powerful 
way to express synchronization at the beginning of the display pipeline 
seems like it could be a useful tool as well.

Thanks,
-James

> Cheers,
> Daniel
>