Swap limit

[Jerome Glisse]

On Fri, Dec 10, 2010 at 9:40 AM, Mario Kleiner
<mario.kleiner at tuebingen.mpg.de> 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.

Cheers,
Jerome