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. At least I remeber there was bit to toggle for tearing. I have to check it in evening. > Cheers, > Jerome _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
