dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: "Kulkarni, Vandita" <vandita.kulkarni@intel.com>,
	"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>,
	"Vetter, Daniel" <daniel.vetter@intel.com>,
	"B S, Karthik" <karthik.b.s@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "Shankar, Uma" <uma.shankar@intel.com>,
	"nicholas.kazlauskas@amd.com" <nicholas.kazlauskas@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v5 0/5] Asynchronous flip implementation for i915
Date: Wed, 29 Jul 2020 09:33:50 +0200	[thread overview]
Message-ID: <f439795a-6a95-2e96-b511-42b4f5725e04@daenzer.net> (raw)
In-Reply-To: <57510F3E2013164E925CD03ED7512A3B86351230@BGSMSX102.gar.corp.intel.com>

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.


-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-07-29  7:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20 11:31 [PATCH v5 0/5] Asynchronous flip implementation for i915 Karthik B S
2020-07-20 11:31 ` [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler Karthik B S
2020-07-24 23:26   ` Paulo Zanoni
2020-07-27 12:27     ` Michel Dänzer
2020-07-27 21:34       ` Daniel Vetter
2020-08-05 13:53         ` Karthik B S
2020-08-05 13:46       ` Karthik B S
2020-08-05 13:43     ` Karthik B S
2020-07-20 11:31 ` [PATCH v5 2/5] drm/i915: Add support for async flips in I915 Karthik B S
2020-07-24 23:26   ` Paulo Zanoni
2020-07-28  7:37     ` Karthik B S
2020-07-20 11:31 ` [PATCH v5 3/5] drm/i915: Add checks specific to async flips Karthik B S
2020-07-20 11:31 ` [PATCH v5 4/5] drm/i915: Do not call drm_crtc_arm_vblank_event in " Karthik B S
2020-07-20 11:31 ` [PATCH v5 5/5] drm/i915: Enable async flips in i915 Karthik B S
2020-07-24 23:26 ` [PATCH v5 0/5] Asynchronous flip implementation for i915 Paulo Zanoni
2020-07-29  7:23   ` Kulkarni, Vandita
2020-07-29  7:33     ` Michel Dänzer [this message]
2020-08-04  5:49       ` Kulkarni, Vandita
2020-08-04  6:06         ` Karthik B S

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f439795a-6a95-2e96-b511-42b4f5725e04@daenzer.net \
    --to=michel@daenzer.net \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=karthik.b.s@intel.com \
    --cc=nicholas.kazlauskas@amd.com \
    --cc=paulo.r.zanoni@intel.com \
    --cc=uma.shankar@intel.com \
    --cc=vandita.kulkarni@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).