Am 04.06.2014 21:54, schrieb Keith Packard:
Pekka Paalanen <[email protected]> writes:
that is starting to sound a lot like queueing display updates in the
kernel. Let me jump a few (couple?) years to the future and speculate
wildly, likely going off-topic. ;-)
We're already queueing updates in the kernel, it's just that the time
for that update to be shown is implicitly 'the next frame', whatever
that means. Applications need to be able to control when their contents
are displayed
I think the whole concept of MSC will be breaking down, as we are
getting dynamic/variable refresh displays (G-SYNC, FreeSync). MSC will
no longer correspond to the true real time at all (bye bye A/V sync),
not even for the very next vblank which might happen any time from 5 to
500 ms from the previous vblank.
I think of MSC as simply a different notation for 'time', one which
recognizes the current discrete nature of frames, and which changes
units every time you switch monitors.
The problem of MSC is that with approaches like free-sync, active sync
or G-sync (or however you call it) the number of vertical refreshes per
second isn't constant any more. So you don't have an unit associated
with your MSC, and so we really need some kind of external reference for
this to work reliable.
Apart from that at least on Radeon hardware you have double buffered
registers, so the hardware does the flip in the next vertical or
horizantal vblank period if you tell it to do so. So waiting in
userspace for a certain VBLANK counter to be reached and then sending
down the request to the kernel would be rather awkward and error prone,
cause the hardware can do this on their own.
Christian.
(That is one reason why I designed the Wayland Presentation extension
(still RFC [1]) around timestamps instead of frame counters.) We'd
need a way to tell DRM when we would like the next vblank to happen.
Present current implements the Khronos standards, which aren't exactly
forward-looking and have a lot of kruft in them, but at least are
published.
The how is totally open, and the benefits are not clear at least to me
yet.
Agreed; I'm just dealing with the current situation where we *do* have
queuing in the kernel and need to make it more sane. Right now, given a
flip request, the kernel has no idea whether it should replace the
current flip with that or have the new one wait for yet another frame.
Using some kind of time unit in the request (whether MSC, UST or other),
means that the kernel knows what to do.
I suspect you'd also need a way to cancel some or all queued updates -
I suppose you'd want that already - and to get feedback per submission
on was it actually presented and when.
This is absolutely required; right now the X server has significant
mechanism in place to deal with a canceled flip as it can only correct
things after the flip has occurred.
We've had similar discussions in the Wayland land, and generally people
were horrified of needing 4 buffers for a busy-loop EGL app (games).
I'm not sure if we came to any real conclusion. I think if someone
really wants to waste CPU/GPU cycles for drawing more than you can
show, they have also the memory to juggle more buffers around. *shrug*
With the current kernel implementation, three buffers with flipping runs
at frame rate because you always have one buffer blocked waiting for
vblank. Providing a way to replace that buffer would mean that you'd be
able to start drawing another frame as soon as the previous frame
finished rendering and the GPU went idle. At least that provides for
faster-than-frame-rate rendering, although it still doesn't saturate the
hardware.
If the aim is to reduce latency, I think it should be tackled in a
more... sophisticated manner than just throwing raw power at it. But
that'd mean the games would need to get smarter, which won't help
existing games.
What you want is for the application to start drawing precisely when it will
finish in time for vblank. Modeling the performance characteristics of
the system accurately enough to do this reliably is non-trivial. Right
now, some applications adjust rendering complexity to hit their desired
frame rate, but even then developers generally want a
non-vblank-synchronized update in case they miss the deadline.
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
