On 8/4/2020 11:19 AM, Kulkarni, Vandita wrote:
-----Original Message-----
From: Michel Dänzer <michel@xxxxxxxxxxx>
Sent: Wednesday, July 29, 2020 1:04 PM
To: Kulkarni, Vandita <vandita.kulkarni@xxxxxxxxx>; Zanoni, Paulo R
<paulo.r.zanoni@xxxxxxxxx>; Vetter, Daniel <daniel.vetter@xxxxxxxxx>; B S,
Karthik <karthik.b.s@xxxxxxxxx>; intel-gfx@xxxxxxxxxxxxxxxxxxxxx
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx; Shankar, Uma
<uma.shankar@xxxxxxxxx>; nicholas.kazlauskas@xxxxxxx
Subject: Re: [PATCH v5 0/5] Asynchronous flip implementation for i915
On 2020-07-29 9:23 a.m., Kulkarni, Vandita wrote:
On async flips, there needs to be some clarity/guideline on the
behaviour and event expectation from the driver by user space.
Here are few assumptions that we have, 1. Our understanding is that
the user space doesn’t expect the timestamp for async flips (but still
expects vblank timestamp) , or doesn’t do anything with that, same is the
assumption wrt the flip sequence, please correct us if we are wrong.
2. In the sequence the user space still expects the counter that marks
vblanks.
3. The user space can use different event types like DRM_EVENT_VBLANK
or DRM_EVENT_FLIP_COMPLETE for getting the corresponding event. And
their designs are still aligned to this even in case of async.
If there are any more expectations from the user space wrt to the
event that is being sent from the driver in case of async flip, please let us
know.
If the user space doesn’t care much about the flip sequence then, we
can just not do anything like returning the flip counter like this version is
doing and just stick to returning of the frame counter value(which marks
vblanks).
There's no such thing as a "flip sequence" in the KMS API. There's only the
per-CRTC vblank counter. Each flip completion event needs to contain the
value of that counter when the hardware completed the flip, regardless of
whether it was an async flip or not.
As for the timestamp in the event, I'm not sure what the expectations are for
async flips, but I suspect it may not really matter. E.g. the timestamp
calculated to correspond to the end of the previous vertical blank period
might be fine.
Thanks Michel, Paulo, Daniel, Nicholas, Ville for your inputs.
After all the discussions, looks like the async flip time stamp is not of much
use to the userspace and the async flip sequence; hence we will stick to the approach of sending vblank time stamp
itself and have a test case in the igt to cover the async flips cases in a slightly different way.
And update the documentation.
Thanks a lot for all the inputs.
I will make changes in IGT to calculate the time stamps from userspace
itself, as we have now concluded that the kernel will be returning vbl
timestamps even in the case of async flips.
Also, as suggested by Daniel, I will be adding one more subtest to
verify that the async flip time stamp lies in between the timestamps of
the previous and the next vblank.
Thanks,
Karthik.B.S
Thanks,
Vandita
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
