Swap limit

[Pauli Nieminen]

On 12/12/10 19:49 -0500, ext Jerome Glisse wrote:
> 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.
> 

If I remember correctly RADEON_CRTC_OFFSET_FLIP_CNTL had some effect on that.
At least I remeber there was bit to toggle for tearing.

I have to check it in evening.

> Cheers,
> Jerome