On 06/07/2013 10:10 AM, Keith Packard wrote:
* PGP Signed by an unknown key
James Jones <[email protected]> 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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
