On Mon, 2008-08-18 at 15:30 -0400, Kristian Høgsberg wrote: > > I have pushed the DRI2 update to the dri2proto, mesa, xserver, and > xf86-video-intel trees in ~krh. It's on the master branch in those repos.
I don't see anything younger than 5 months in your xf86-video-intel repo. > 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. > 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? > Since we just end up calling CopyArea, damage is posted automatically > and now DRI magically works with SW cursors. Nice for MPX. :) -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------- 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
