Swap limit

[Michel Dänzer]

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
> > <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.

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.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer