On Fri, 5 Oct 2018 12:21:20 -0400 "Kazlauskas, Nicholas" <nicholas.kazlauskas@xxxxxxx> wrote: > On 10/05/2018 04:10 AM, Pekka Paalanen wrote: > > Hi, > > > > I have a somewhat of my own view on what would be involved with VRR, > > and I'd like to hear what you think of it. Comments inline. > > > > > > On Tue, 25 Sep 2018 09:51:37 -0400 > > "Kazlauskas, Nicholas" <nicholas.kazlauskas@xxxxxxx> wrote: > > > >> On 09/24/2018 04:26 PM, Ville Syrjälä wrote: > >>> On Mon, Sep 24, 2018 at 03:06:02PM -0400, Kazlauskas, Nicholas wrote: > >>>> On 09/24/2018 02:38 PM, Ville Syrjälä wrote: > >>>>> On Mon, Sep 24, 2018 at 02:15:36PM -0400, Nicholas Kazlauskas wrote: > >>>>>> Variable refresh rate algorithms have typically been enabled only > >>>>>> when the display is covered by a single source of content. > >>>>>> > >>>>>> This patch introduces a new default CRTC property that helps > >>>>>> hint to the driver when the CRTC composition is suitable for variable > >>>>>> refresh rate algorithms. Userspace can set this property dynamically > >>>>>> as the composition changes. > >>>>>> > >>>>>> Whether the variable refresh rate algorithms are active will still > >>>>>> depend on the CRTC being suitable and the connector being capable > >>>>>> and enabled by the user for variable refresh rate support. > >>>>>> > >>>>>> It is worth noting that while the property is atomic it isn't filtered > >>>>>> from legacy userspace queries. This allows for Xorg userspace drivers > >>>>>> to implement support in non-atomic setups. > >>>>>> > >>>>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@xxxxxxx> ... > >> Whenever I mentioned variable refresh "features", what I really meant > >> was operating in one of two modes: > >> > >> (1) Letting the driver and hardware adjust refresh automatically based > >> on the flip rate on a CRTC from a single application > >> > >> (2) Setting a fixed frame duration based on the flip rate on a CRTC from > >> a single application > > > > I wonder if that's too much magic in the kernel... what would be wrong > > with simply flipping ASAP when VRR is active? > > > > How will userspace be able to predict coming flip opportunities if the > > kernel does so much magic? > > The kernel driver doesn't need to do much more than let the hardware > know the variable refresh range. The "magic" is performed by hardware. > > Most games would like to render as fast as possible to deliver a more > responsive and smoother image to the user. Many of these are also > resource intensive and won't always be able to render at the fixed > refresh rate of the panel (especially for higher refresh rates like > 144Hz). The user will experience stuttering if the game takes too long > to render and misses the vblank window for the flip. > > Dynamic VRR adjustment can resolve this problem. The hardware can lower > the refresh rate and increase the vblank window in response to this so > the user doesn't experience stuttering (or latency). > > Userspace shouldn't predict anything. ... > >>>> The reasoning for the split is because not all content is suitable for > >>>> variable refresh. Desktop environments, web browsers, etc only typically > >>>> flip when needed - which will result in display flickering. > > > > Flickering? What do you mean? > > This is a property of how panels work. > > The luminance for a panel will vary based on how long the vrefresh is. > Since the vrefresh length is changing as part of VRR you're more likely > to notice the difference in luminance the bigger the difference is. > > The difference will be largest when switching from the min vrefresh to > the max vrefresh duration. > > Large differences can occur for applications that render on demand like > a web browser (and why you wouldn't want VRR enabled for those). The > hardware would continuously wait for a flip that isn't coming. Then if > the user moves their cursor or the page updates it's going to happen > "randomly" in that window and the hardware will adjust to that. Hi Nicholas, it seems I have very much mis-guessed what VRR aims to achieve, and the effect on luminance sounds horrible. People have worked for years to make display timings more explicit, giving better control and predictability over them. It sounds like VRR is not an improvement that allows new smarter software to take control of timings even better. Instead, VRR seems to be a step backwards, introducing more uncertainty into the timings. The expectation of a fixed unknown refresh rate must be built into software for the software to work reasonably while VRR is active. From your comments I understood that the VRR hardware still very much depends on a consistent refresh rate, except the hardware (not the software!) can additionally slew the refresh rate over time. Abrupt changes in frame timings must still be prevented, but I wasn't quite sure if you meant the hardware will do that or if the software must do that, since you are worried about on-demand updating applications causing flickering. Hence, VRR looks like a band-aid for old and simple applications that use brute force (more fps, maximize the work load) in an attempt to make things smoother and to reduce latency. There are lots of such applications, so VRR has its place. It is my mistake of assuming it could do more. Yes, I am disappointed to realize this. I believe that future display servers and applications that actually care about display timings will just opt out from VRR to gain better predictability. I also believe that you will need to blacklist applications like video players whose developers have spent a great deal of effort in making a smart scheduling algorithm for fixed rate display. I assume that a smart sheduling algorithm that is based on prediciting the next display time instant will interact poorly with VRR. A video player will need to know if it is getting fixed rate or VRR to choose the appropriate timing algorithm - wherther it needs to adapt to the display rate or will the display rate adapt to it. In summary, VRR is only good for exactly the use cases you listed, and for other uses it can be harmful, just like you said. Given the above, I think we are now very much on the same page about what the KMS UABI should look like. > Most compositors function well under this stack. It will vary > depending on compositor support for window unredirection to let the > window flip via the Present extension. Mutter handles this without > any configuration and kwin can be configured to work with these > patches. Compton can be configured to support unredirection as well. You are thinking about the applications. What about the compositor itself? Is the COW not hitting the Present direct scanout path, triggering VRR, when what is actually showing is the desktop with on-demand randomly updating windows? > These (among others) are covered as part of the blacklist for the > mesa patches. They do need to be explicitly excluded. Right, you blacklist all compositing managers to prevent them from regressing. That feels a bit ugly to me, needing exceptions to not regress things, but maybe that's business as usual in Mesa? Fortunately that problem with compositing managers won't exist with Wayland. In any case, there must also be a way for an application to explicitly say if it supports VRR or not and to know if it gets VRR or not. Are there no EGL or Vulkan extensions for that? Thanks, pq
Attachment:
pgpSK3wpnaW8B.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
