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. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
