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