- Forwarded message from Peter John Garrone pgarr...@optusnet.com.au -
From: Peter John Garrone pgarr...@optusnet.com.au
To: Jesse Barnes jbar...@virtuousgeek.org
Subject: Re: [RFC] page flipping/buffer swap for DRI2
On Fri, Feb 13, 2009 at 04:44:08PM -0800, Jesse Barnes wrote:
On Friday, February 13, 2009 4:18 pm Peter John Garrone wrote:
In reply to Jesse Barnes post.
I'm not on top of the finer details, being a consumer rather than a
developer. I have the following queries:
1) Is the buffer flip to be synchronous in the hardware, or to be
implemented as a software interrupt?
I'm not sure what you mean... The flip is queued in the hardware ring, and
delayed by hardware until the vertical blank interval starts. So in that
sense the hardware takes care of it for us (we don't rely on an interrupt to
get the bits on the screen). We do require an interrupt, however, to know
when the flip has occurred. This lets us know that it's ok to start drawing
on the new back buffer, since it's no longer being displayed to the user.
I incorrectly wrote software interrupt when I meant hardware interrupt,
which is confusing, sorry. I would rephrase my own particular
requirement as
Is the buffer flip to be implemented in the hardware, or implemented
in software triggered by hardware interrupt?
The intel hardware has the ability to do a buffer swap in the hardware.
However I believe that the current dri infrustructure works (see
mesa/src/mesa/drivers/dri/intel/intel_swapbuffers.c:intelSwapBuffers) by
flushing pending rendering commands, waiting for the appropriate
vertical blank interrupt, then copying the opengl back buffer to the
front buffer. This is a problem when the interrupt response is slow, or
when the hardware graphics queue is not empty because other opengl
applications are currently rendering, so the buffer swap is
delayed, creating a tear generally near the top of the screen. I don't
think this quite agrees with your outline, unless your patch set
addresses this problem, which would be wonderful.
I currently cope with this by poking the hardware to cause the two
screens to interrupt at a particular phase, and synchronizing the two
rendering threads to wait until both have accomplished their screen
swaps. At high loads, however, the synchronization breaks down and
tearing results, and it is never possible to completly eliminate
tearing.
2) By fullscreen, do you mean covering one or all screens in a multi-headed
display?
It's hard coded to deal with one screen in this patchset, but potentially
needs to flip both heads in a shared (cloned or extended desktop)
configuration.
That's fine. I would hope that in a dual-headed setup, each screen (or
plane) can be individually full-screen. Sometimes fullscreen is
interpreted as a single window covering both screens, which is not good
for me.
3) If fullscreen means covering an individual screen in a multi-headed
display, will it be possible to have multiple simultaneous fullscreen
tear-free applications?
Yes, it should be possible.
4) Will non-fullscreen applications be tear-free?
Maybe. If you're running a compositing manager that always swaps the whole
screen (like the hacked version of compiz I've been using for testing does),
then any non-DRI apps running under it will be tear-free. DRI apps will need
special treatment, which I haven't implemented yet.
To be honest, the speed of the window manager is not a big issue for me.
Tearing is. In production mode, efficient fullscreen output mode is
desirable. In development mode, having the output into manageable
re-sizeable windows is nicer.
The only way I can see non-tearing non-fullscreen
applications working is with triple-buffer. i.e. a kernel screen flyback
interrupt copies a screen-full from the multi-headed working buffer to a
plane buffer, schedules that plane buffer to be swapped upon the next
flyback, and triggers approptiate returns from the application swap-buffer
function calls. I assume this is triple-buffer because there is the large
possibly virtual working buffer and also two plane buffers for each screen.
That would be one way of handling non-fullscreen apps. Another way would be
to queue front buffer blits from such apps to occur during the vertical blank
period. That's not as reliable (nor easy to implement) as full page flipping
though, but has the advantage of just blitting over a small area of the
screen, which will preserve most of the compressed framebuffer (if present),
saving power.
This appears to me to be what the code in intel_swapbuffers.c currently
achieves. I'm grateful if you are creating an alternative for fullscreen
applications, anyway.
However a fullscreen application should be able to override this on an
individual screen basis, rendering directly into the non-output display
plane, and scheduling it to be swapped upon the N'th flyback.
Right, that's
