On Dec 13, 2010, at 11:21 AM, Michel Dänzer wrote:
On Mon, 2010-12-13 at 11:35 +0200, Pauli Nieminen wrote:
On 12/12/10 19:49 -0500, ext Jerome Glisse wrote:
On Fri, Dec 10, 2010 at 9:40 AM, Mario Kleiner
<[email protected]> wrote:
On 12/08/2010 05:15 PM, Pauli Nieminen wrote:
On 08/12/10 16:55 +0100, ext Alex Deucher wrote:
One other thing that might be worth adding to DRI2 is a way
for the
driver to access the swap interval. If we could, then the driver
could dynamically disable things like vline waits for buffer
blits or
do non-vsynced pageflipping more easily if the swap interval
was 0.
Actually I tough DRI2 was already telling SwapInteval with
*swap_target = pPriv->last_swap_target + pPriv->swap_interval;
If swap_target doesn't advance then driver would know to flip
as fast as
possible.
But then I noticed a bug.
First one is that we always blit with swapinterval is zero when
it should
be
possible to flip (even tear free).
Let it tear :). I think swap_interval == 0 should cause
immediate swaps with
tearing. All OpenGL implementations i know (Windows, MacOS
classic, MacOS/X,
Linux with proprietary drivers, old SGI's) interpret a
swapinterval of zero
as "swap as soon as rendering is finished, immediately, don't
sync to
scanout cycle" and i think that makes the most sense. It's good for
benchmarking how fast your system can go if not throttled by the
monitor
(useful), for crazy gamers that trade visual quality for fps and
for special
applications that need to sometimes control swap timing
themselves (like my
toolkit).
Code from DRI2ScheduleSwap:
/* Old DDX or no swap interval, just blit */
if (!ds->ScheduleSwap || !pPriv->swap_interval) {
Not a "bug", just a half-done way of achieving the expected
swap_interval
zero ;-) [ok, maybe that is a bug].
It schedules an immediate copy-swap via blitting. Unfortunately
the ddx
doesn't know about the swap_interval, so it still synchronizes
the execution
of the blit to vsync via vline waits. That's tear-free, but it
depends on
the location and size of the drawable and the current position
of the
scanout if this will cause an immediate swap (if scanout is
outside the
drawables area) or a vsync'ed swap. It's a bit undefined
behaviour for
non-fullscreen drawables and it effectively enforces a minimum
swap interval
of 1 for fullscreen drawables, which is not what we want.
Both the intel ddx and (soon) the ati ddx have a xorg.conf
parameter
"SwapBuffersWait" to disable vsync completely, then you'd get
copy-swaps as
fast as possible for swap_interval zero, but for a non-zero
swap_interval
you'd have some chance of tearing, so this is alos just a band-aid.
If we wanted this for page-flipping we'd need a shortcut similar
to this one
which would bypass the vblank scheduling and call the ddx
pageflip routine
directly, plus an extension to the kernel's pageflip ioctl() to
allow
non-vsynced flips.
And we need a new interface to tell the ddx that a swap should be
non-vsync'ed.
Unless i miss read hw spec all pageflip are always vsync no matter
what you do. IIRC the crtc sancout address is updated during vblank
from the register, so what is scanned next is what ever address was
written last.
If I remember correctly RADEON_CRTC_OFFSET_FLIP_CNTL had some
effect on that.
Correct, if that bit is 1 the flip happens on the next horizontal
blank
(the non-KMS radeon DRM always sets this bit for flipping). There's
probably something similar for the AVIVO display engine.
On Radeons you can select if flip should happen at next vblank or
hblank. Alex's initial pageflip patches for Radeon used this even for
vblank sync'd flips, so we know it works, but we changed to a
different method for higher overall robustness. I assume other gpu's
aren't different, as on os/x and windows, all gpu's will swap
immediately (with tearing) when you set the swap_interval to zero.
Adding this to the implementation wouldn't be difficult (at least for
radeon's), it's just that the current pageflip ioctl() doesn't
support an option to pass this to the kms-driver. Same with the ddx.
Currently there isn't a specific interface for the x-server to
communicate vsync vs. non-vsync to the ddx.
I have to read the other e-mails in this thread first, esp. Pauli's,
i'm a bit slow at the moment.
-mario
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
