[PATCH 3/3] glx/dri3: Request non-vsynced Present for swapinterval zero.
Keith Packard
keithp at keithp.com
Tue Dec 16 00:23:14 PST 2014
Mario Kleiner <mario.kleiner.de at gmail.com> writes:
> The 0 case is good for benchmarking.
Sure, but the current code does benchmarking just fine. In fact, because
it doesn't copy queued frames that aren't the most recent before the
vblank, benchmarks tend to run *faster* as a result, and people
generally like that aspect of it...
> In my specific case i always want vsync'ed swap for actual visual
> stimulation in neuroscience/medical settings, with no frame skipped
> ever. The bonus use for me, except for benchmarking how fast the system
> can go, is if one has a multi-display setup, e.g., dual-display for
> stereoscopic stimulation - one display per eye, or some CAVE like setup
> for VR with more than 2 displays. You want display updates and scanout
> on all of them synchronized, so the scene stays coherent. One simple way
> for visually testing multi-display sync is to intentionally swap all of
> them without vsync, e.g., timed to swap in the middle of the scanout. If
> the tear-lines on all displays are roughly at the same vertical position
> and stay there then that's a good visual test if stuff works. There are
> other ways to do it, but this is the one method that seems to work
> cross-platform, without lots of mental context switching depending on
> what os/gpu/server/driver combo with what settings one uses, and much
> more easy to grasp for scientists with no graphics background. You can
> see at a glance if stuff is roughly correct or not.
It seems like you want something that the GL API doesn't express
precisely; my reading of the GL spec definitely lets Present work the
way it does today, and as you avoid tearing *and* improve performance in
the vblank_mode=0 case, I'm very reluctant to change it.
Present could trivially offer a new bit to force tearing; I'm not sure
how you'd get at that from GL though.
--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20141216/0c6aa585/attachment.sig>
More information about the xorg-devel
mailing list