Am 04.06.2014 09:03, schrieb Pekka Paalanen:
On Tue, 03 Jun 2014 20:08:21 -0700
Keith Packard <[email protected]> wrote:
Michel Dänzer <[email protected]> writes:
At least the waiting for the pixmap to become idle part should be
perfectly possible in the X server?
One of three possible ways:
1) Blocking kernel call waiting for buffer idle.
This doesn't seem like what we want.
2) Receive a DRM event when a buffer is idle
Does this event even exist today?
3) Polling for idle when receiving a vblank event.
This will work fine for vblank-synchronized flips; we
simply check whether the next queued buffer is idle and delay the
flip by a frame if it isn't.
For flip elision with non-async flips, something like
DRM_MODE_PAGE_FLIP_REPLACE (and possibly a corresponding DRM event
signaling the previous flip was canceled, if DRM_EVENT_FLIP_COMPLETE is
inappropriate for that) might work, which would replace any pending flip
with the new one.
Do we just want to send the MSC count to the kernel so it "knows" which
frame we want the contents presented at?
Hi,
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. ;-)
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. (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.
Agree totally, even today we have a number of problems with MSCs.
For example try to move a video from one monitor to another. Since the
state tracker doesn't know of the window move we send out MSCs for the
wrong display device. In the best case this results in just displaying a
frame way to early, in the worst we stall for a quite long time until
the other device reaches the MSC counter of the first one.
DRM universal planes + atomic modesetting / nuclear pageflip is already
aiming to gather at least a per-head update into a single atomic set of
state changes. Once we have that, we might extend that to allow
queueing in the kernel for more than just the very next update. The how
is totally open, and the benefits are not clear at least to me yet. 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 just some food for thought, nothing more.
I'm not sure if we want to queue things up in the kernel.
I think just providing a timestamp when the frame should be first
visible like VDPAU does is the right way to go.
Adding a flag that a waiting flip request should be replaced by another
one instead of running into an error should be enough to handle the
triple (or quad) buffered case as well.
Christian.
The client may still need to use a fourth buffer if it wants to start
rendering the next frame before the flip is complete and before the last
submitted pixmap becomes idle. I can't think of any way around that
offhand.
We can try it both ways and see what it looks like for real applications.
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*
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.
So it might make sense to try the approach using async flips for now,
and see how well that works in practice.
Right, having "real" async flips is a prerequisite for doing this, along
with sufficient mechanism to not request a flip until the buffer is
idle, without forcing the X server to stall in the flip kernel call
waiting.
I think dmabuf will be solving that problem. If I understood right, you
would be able to use the dmabuf fd to check if (DRM) fences have been
signalled. I'm not sure of the details, though, or when that feature
would be available. Maarten Lankhorst would know.
Thanks,
pq
[1] http://lists.freedesktop.org/archives/wayland-devel/2014-March/013580.html
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
