All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Koenig, Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
To: Pekka Paalanen <ppaalanen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Haehnle, Nicolai" <Nicolai.Haehnle-5C7GfCeVMHo@public.gmane.org>,
	"michel-otUistvHUpPR7s880joybQ@public.gmane.org"
	<michel-otUistvHUpPR7s880joybQ@public.gmane.org>,
	"Olsak, Marek" <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org"
	<manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"Daniel Vetter" <daniel-/w4YWyX8dFk@public.gmane.org>,
	"Deucher,
	Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
	"Kazlauskas,
	Nicholas" <Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org>,
	"Ville Syrjälä"
	<ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Subject: Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC
Date: Fri, 12 Oct 2018 11:20:39 +0000	[thread overview]
Message-ID: <00b8b89f-2675-dda5-7307-8a75b20390d7@amd.com> (raw)
In-Reply-To: <20181012122144.595de059@eldfell>

Am 12.10.2018 um 11:21 schrieb Pekka Paalanen:
> On Fri, 12 Oct 2018 07:35:57 +0000
> "Koenig, Christian" <Christian.Koenig@amd.com> wrote:
>
>> Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
>>> On Wed, 10 Oct 2018 09:35:50 -0400
>>> "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> wrote:
>>>   
>>>> The patches I've put out target this use case mostly because of the
>>>> benefit for a relatively simple interface. VRR can and has been used in
>>>> more ways that this, however.
>>>>
>>>> An example usecase that differs from this would actually be video
>>>> playback. The monitor's refresh rate likely doesn't align with the video
>>>> content rate. An API that exposes direct control over VRR (like the
>>>> range, refresh duration, presentation timestamp) could allow the
>>>> application to specify the content rate directly to deliver a smoother
>>>> playback experience. For example, if you had a 24fps video and the VRR
>>>> range was 40-60Hz you could target 48Hz via some API here.
>>> The way that has been discussed to be implemented is that DRM page flips
>>> would carry a target timestamp, which the driver will then meet as good
>>> as it can. It is better to define an absolute target timestamp than a
>>> frequency, because a timestamp can be used to synchronize with audio
>>> and more. Mario Kleiner can tell you all about scientific use cases
>>> that require accurate display timing, not just frequency.
>> To summarize what information should be provided by the driver stack to
>> make applications happy:
>>
>> 1. The minimum time a frame can be displayed, in other words the maximum
>> frame rate.
>> 2. The maximum time a frame can be displayed, in other words the minimum
>> frame rate.
>> 3. How much change of frame timing is allowed between frames to avoid
>> luminescence flickering.
>>
>> Number 1 and 2 can also be used to signal the availability of VRR to
>> applications, e.g. if they are identical we don't support VRR at all.
> Hi Christian,
>
> "the maximum time a frame can be displayed" is perhaps not an
> unambiguous definition. A frame can be shown indefinitely in any case.

Good point. Please also note that I'm not an expert on the display stuff 
in general.

My background comes more from implementing the VDPAU mediaplayer 
interface in mesa.

So just throwing some ideas in here from the point of view of an 
userspace developer which wants to write a media player :)

> The CRTC will simply start scanning out the same frame again if there
> is no new one. I understand what you want to say, but perhaps some
> different words will be in order.
>
> I do wonder if applications really want to know the maximum acceptable
> slew rate in timings... maybe that should be left for the drivers to
> apply. What I'm thinking is that we have the page flip timestamp with
> the page flip events to tell when the new FB became active. That
> information could be extended with a time range on when the very next
> flip could take place. Applications are already computing that
> prediction from the flip timestamp and fixed refresh rate, but it might
> be nice to give them the driver's opinion explicitly. Maybe the
> tolerable slew rate is not a constant.

Well it depends. I agree that the kernel should probably enforce the 
slew rate to avoid flickering for the user.

But it might be beneficial for the application to know things like this.

What the application definitely needs to know is when a frame was 
actually displayed. E.g. application says I want to display this at 
point X and at some point later the kernel returns saying the frame was 
displayed at point N where in the ideal case N=X.

Additional to that let's please use 64bit values and nanoseconds for 
every value we use here, and NOT fps, line numbers or similar :)

Regards,
Christian.

>
> Other than that, yes, it sounds fine to me.
>
>
> Thanks,
> pq

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2018-10-12 11:20 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-24 18:15 [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support Nicholas Kazlauskas
2018-09-24 18:15 ` [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC Nicholas Kazlauskas
2018-09-24 18:38   ` Ville Syrjälä
2018-09-24 19:06     ` Kazlauskas, Nicholas
     [not found]       ` <4aa1583c-2be0-8cec-2857-6c3e489965b4-5C7GfCeVMHo@public.gmane.org>
2018-09-24 20:26         ` Ville Syrjälä
     [not found]           ` <20180924202655.GA9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-09-25 13:28             ` Michel Dänzer
     [not found]               ` <2158aa72-9156-5592-822a-c815f373fd53-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-09-25 14:04                 ` Ville Syrjälä
     [not found]                   ` <20180925140433.GH9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-09-25 14:35                     ` Michel Dänzer
2018-09-25 15:28                       ` Ville Syrjälä
     [not found]                         ` <20180925152817.GK9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-10-01  7:10                           ` Daniel Vetter
2018-09-25 13:51             ` Kazlauskas, Nicholas
2018-10-05  8:10               ` Pekka Paalanen
2018-10-05 16:21                 ` Kazlauskas, Nicholas
     [not found]                   ` <fdc195dd-9650-8194-3a16-393f61bb2eee-5C7GfCeVMHo@public.gmane.org>
2018-10-05 16:56                     ` Michel Dänzer
2018-10-05 17:48                       ` Kazlauskas, Nicholas
2018-10-08 10:57                         ` Michel Dänzer
2018-10-10  7:14                     ` Pekka Paalanen
2018-10-10 13:35                       ` Kazlauskas, Nicholas
     [not found]                         ` <3bb5e05d-f7e6-8e44-cfae-202191d64245-5C7GfCeVMHo@public.gmane.org>
2018-10-12  7:23                           ` Pekka Paalanen
2018-10-12  7:35                             ` Koenig, Christian
     [not found]                               ` <894d12d3-aa0b-c0f6-6347-7d13e58e651a-5C7GfCeVMHo@public.gmane.org>
2018-10-12  9:21                                 ` Pekka Paalanen
2018-10-12 11:20                                   ` Koenig, Christian [this message]
2018-10-12 12:58                                     ` Kazlauskas, Nicholas
2018-10-15 13:57                                       ` Pekka Paalanen
2018-10-15 16:02                                         ` Kazlauskas, Nicholas
     [not found]                                           ` <52103366-510d-15a6-61d2-26196a4f0e57-5C7GfCeVMHo@public.gmane.org>
2018-10-16  7:36                                             ` Pekka Paalanen
     [not found] ` <20180924181537.12092-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-09-24 18:15   ` [PATCH v2 1/3] drm: Add variable refresh rate properties to connector Nicholas Kazlauskas
2018-09-24 18:32     ` Ville Syrjälä
2018-10-01  7:05       ` Daniel Vetter
2018-09-24 18:15   ` [PATCH v2 3/3] drm/amd/display: Set FreeSync state using DRM VRR properties Nicholas Kazlauskas
2018-10-01  7:15 ` [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support Daniel Vetter
2018-10-02 14:49   ` Harry Wentland
2018-10-03  8:41     ` Daniel Vetter
     [not found]       ` <20181003084120.GP11082-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-10-03 18:35         ` Manasi Navare
2018-10-11 19:37           ` Harry Wentland
2018-10-11 19:41         ` Harry Wentland
2018-10-03  8:25   ` Mike Lothian
     [not found]     ` <CAHbf0-HhjG2xc1sAjHBR=Ep11LzumO6tdyzBcKSZ8h82H28Zbg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-10-11 19:44       ` Harry Wentland
2018-10-12  8:26         ` Michel Dänzer
     [not found]           ` <ac5b5865-6bb0-08e8-d83c-26893e75b11e-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-10-12  8:31             ` Koenig, Christian
     [not found]               ` <84c4a243-ca2c-49a7-9e2c-22666292aea9-5C7GfCeVMHo@public.gmane.org>
2018-10-25 17:57                 ` Wentland, Harry
     [not found]                   ` <1c3d19a7-3afa-6de5-59e0-37a19d73848b-5C7GfCeVMHo@public.gmane.org>
2018-10-26  9:33                     ` Michel Dänzer

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=00b8b89f-2675-dda5-7307-8a75b20390d7@amd.com \
    --to=christian.koenig-5c7gfcevmho@public.gmane.org \
    --cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
    --cc=Marek.Olsak-5C7GfCeVMHo@public.gmane.org \
    --cc=Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org \
    --cc=Nicolai.Haehnle-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=daniel-/w4YWyX8dFk@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=michel-otUistvHUpPR7s880joybQ@public.gmane.org \
    --cc=ppaalanen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.