Chris Wilson <ch...@chris-wilson.co.uk> writes: > If a DRI2 client also grabs the buffer, then we have to fallback to blits. > That should be fairly easy to detect and handle.
So, the question is whether the NameWindowPixmap IDs are stable across pixmap replacement. I'm frankly tempted to add a new event to Composite that is sent whenever the window pixmap changes -- that way applications wouldn't have to guess that the pixmap changed whenever the window was resized. This would also provide an opportunity to improve resize performance as the X server could over-allocate window pixmaps during the resize operation, and then shrink them back down once the final size had been selected. > We are concerned with the GEM objects backing the Pixmaps, which may > be changed at whim by the driver. Huh? > We cannot perform simple name exchanges currently in DRI2 because the > Damage is badly ordered wrt the Invalidate event and there is no > coordination between client <-> server <-> compositor on when the > buffers are reusable by the client. Right, so we clearly need to pass the backing buffer from application to X server and thence to the compositor. What I'm not sure about is how to name these buffers, and how to scope their lifetime. Here's a quick proposal -- have the X server assign server XIDs to the buffers, and send those XIDs to the compositor in events. Now the compositor is responsible for telling the server (some new 'IdlePixmap' call?) when it finishes with the objects, at which point they can be released back to the application. We'd need some magic to make sure the pixmaps got freed if the compositor crashed, but I think that's easier than trying to figure out how to allocate XIDs in the compositor ID space from within the X server. This would replace NameWindowPixmap, and would eliminate the current race conditions between the ConfigureNotify and the NameWindowPixmap call while also providing traceable ownership of the buffer contents: busy application X server compositor A Draw to buffer A Allocate pixmap ID for buffer A, 'Pixmap Aa' SwapRegion Pixmap Aa Allocate server ID for Pixmap Aa, 'Pixmap Ax' Send 'window pixmap changed' event 'Pixmap Ax' Receive event Convert 'Pixmap Ax' into buffer A using TextureFromPixmap paint screen using buffer A ... AB Draw to buffer B Allocate pixmap ID for buffer B, 'Pixmap Ba' SwapRegion Pixmap Ba Allocate server id for Pixmap Ba, 'Pixmap Bx' Send 'window pixmap changed' event 'Pixmap Ax' Receive event IdlePixmap Pixmap Ax Convert 'Pixmap Bx' into buffer B using TextureFromPixmap paint screen using buffer B B Mark Pixmap Aa as idle BC Draw to buffer C Allocate pixmap ID for buffer C, 'Pixmap Ca' SwapRegion Pixmap Ca Reply with Pixmap Aa idle Allocate server id for Pixmap Ca, 'Pixmap Cx' Send 'window pixmap changed' event 'Pixmap Cx' Receive event IdlePixmap Pixmap Bx Convert 'Pixmap Cx' into buffer C using TextureFromPixmap paint screen using buffer C C Mark Pixmap Ba as idle CA Draw to buffer A SwapRegion Pixmap Aa Reply with Pixmap Ba idle Send 'window pixmap changed' event 'Pixmap Ax' Receive event IdlePixmap Pixmap Cx paint screen using buffer A A Mark Pixmap Ca as idle At this point, we're in a steady state, using three buffers for the window -- a 'back buffer', a 'front buffer' and an 'idle buffer'. One easy thing for memory usage is to consider idle buffers as suitable for discard in the kernel; that would get us to one pinned buffer in the idle case, although we'd be using three buffers while active. It would be nice to flip between two buffers instead, but there may be compositor rendering traffic in flight using buffer A as the application draws to B and then C. Hrm. What we need is for the client to learn that the compositor has marked a buffer idle before it starts drawing; the current design places that information in the reply to SwapRegion, which is one drawing cycle too late for us. Consider an application which wants to be completely synchronized with screen updates. Such an application would use the new SwapComplete event to detect when its contents were presented to the screen, starting a new frame each time that event was received (assuming it had new data to present). First off, we want the SwapComplete event to be delayed until the compositor is done updating the screen. A new request from the compositor to signal rendering complete could be sent to the server to flag which window contents were present on the screen. When the SwapComplete for the whole screen was delivered, the X server would then forward suitable SwapComplete events to the windows as appropriate. Next, we need the application to learn about idle buffers sooner. One option would be to remove the idle buffer data from the SwapRegion request and create a SwapGetIdle request that fetched the idle buffers separately from doing the swap operation. The application would call this before selecting the target rendering buffer for each frame. The other option would be to create SwapIdle event which the X server would deliver immediately after the compositor marked a buffer as idle. We would need to rewire the X protocol library to deliver this event directly to the DRI3 library. As long as this event were delivered before the SwapComplete, when the client started rendering the next frame, it would get the previous back buffer as intended. I don't think this event would have the same problems as the current Invalidate event; it wouldn't be pulling any active objects out from under the application. > I think we definitely want to support window swapping with DRI3 > compositors. DRI2 compositors will just have to continue to force > blits. Yup. > As I see it the challenge is to prevent sending the buffer release > (SwapIdle) back to the client before all interested third parties have > had a chance to snoop its contents and react. Sketching that out we > need to increment the busy count everytime we send an Invalidate and > expect the client (compositor) to send a release after they have > finished processing the buffer. See above plan. -- keith.pack...@intel.com
pgpKmQoUGIMQQ.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel