Current DRI3 specification

[Daniel Stone]

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; 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.

Cheers,
Daniel