On Tue, 19 Aug 2008 12:57:55 +0200 Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Mon, 2008-08-18 at 15:30 -0400, Kristian Høgsberg wrote: > > The way this works now, is that when ctx->Driver.Viewport is called > > (and thus at least when binding a drawable to a context), the DRI > > driver calls back to the loader, which then calls into the DRI2 module > > to get the buffers associated with the drawable. The DRI2 module in > > turns calls into the DDX driver to allocate these and sends them back > > to the DRI driver, which updates the renderbuffers to use the given > > buffers. > > So after binding a drawable to a context, the buffer information will > only be updated when the app calls glViewport()? Any idea if this scheme > will be suitable for other APIs like GLES or OpenVG? > > Also, I'm wondering if xDRI2Buffer should have a buffer size field, or > if any buffer size padding requirements beyond height * pitch can always > be handled in the driver components.
I think too that we might need more informations there (things for tiling format, compression, ...). > > When glXSwapBuffers is called, the loader calls into the DRI > > driver to finish the frame (this part is missing currently) and then > > calls into the DRI2 module to actually do the back buffer to front > > buffer copy. The DRI2 module again implements this using a hook into > > the DDX driver. The code right now just does a generic CopyArea, and > > then flushes the batch buffer. Swap buffer needs to be a round trip > > so the swap buffer commands are emitted before the DRI driver proceeds > > to render the next frame. > > Making SwapBuffers a round trip isn't ideal for sync to vblank > (especially considering potentially using triple buffering, but see > below). Also, it looks like currently every glXCopySubBufferMESA() call > is a roundtrip as well, which might incur a noticeable hit with compiz. > > About triple buffering, AFAICT this scheme makes that impossible, as > well as implementing buffer swaps by just flipping the front and back > buffers, because the clients won't know the mapping from API buffers to > memory buffers changed. > > Have you considered any other schemes, e.g. some kind of event triggered > when a buffer swap actually takes effect, and which includes information > about the new mapping from API buffers to memory buffers? Or is the idea > to just leave any advanced SwapBuffers schemes to the drivers? > I agree with Michel, i think we need a mecanism for the DDX and the DRI to talk to each other. On SwapBuffer the DRI driver would query for update and in single buffer case it would be up to the DRI client to update it's view from times to times and inform back the DDX that it's now in sync (does it sounds like the DRI2 event things ? :)) So, i like a lot having the DDX being in charge for swap following reasons : - no nasty cliprects things to keep in sync DDX knows about that first hand - safe page flip for full screen case DDX should be the only one allowed (well who ever own the front buffer) to ask for a page flip Problems i foresee : - in one scan out buffer per screen case (i think it's on the roadmap somewhere btw getting free beer and peace in the whole word) with gl apps overlapping several screens solution i can think of: force to go to redirected rendering like if there was a compositor - for tripple buffered or resize or even when the back buffer change (like when changing resolution) need so way for the DDX and DRI to talk so each others know about what it's happening and where. Also usefull if DDX wants DRI to render to a pixmap or whatever others usecase. events things ? So all in all i think DRI should be told where to render by the DDX and DDX should be in charge of getting this things to the screen in what ever way it sees fit (vblank blit, page flip, ...). I think in such case tripple, or even more, buffered rendering should work ie on swap the DRI wait for the DDX to tell it where to render next frame : - in tripple case DDX can directly give a new buffer, while scheduling the swap - in double case DDX schedule the swap, wait for the last swap to finish (ie having old front buffer idle) then front become back and DDX tell the DRI about it Thanks a lot for working on this DRI2 things Kristian :) Cheers, Jerome Glisse <[EMAIL PROTECTED]> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
