Re: dri2-without-sarea branches for review

[Michel D. <mi...@tu...>]

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