On Fri, 26 Oct 2018 17:34:15 +0000 "Kazlauskas, Nicholas" <Nicholas.Kazlauskas@xxxxxxx> wrote: > On 10/26/18 10:53 AM, Ville Syrjälä wrote: > > On Fri, Oct 26, 2018 at 02:49:31PM +0000, Kazlauskas, Nicholas wrote: > >> On 10/26/18 7:37 AM, Pekka Paalanen wrote: > >>> Hi, > >>> > >>> where is the documentation that explains how drivers must implement > >>> "variable refresh rate adjustment"? > >>> > >>> What should and could userspace expect to get if it flicks this switch? > >>> > >>> I also think the kernel documentation should include a description of > >>> what VRR actually is and how it conceptually works as far as userspace > >>> is concerned. > >>> > >>> That is, the kernel documentation should describe what this thing does, > >>> so that we avoid every driver implementing a different thing. For > >>> example, one driver could prevent the luminance flickering itself by > >>> tuning the timings while another driver might not do that, which means > >>> that an application tested on the former driver will look just fine > >>> while it is unbearable to watch on the latter. > >>> > >>> > >>> Thanks, > >>> pq > >> > >> I felt it was best to leave this more on the vague side to not impose > >> restrictions yet on what a driver must do. > >> > >> If you think it's worth defining what the "baseline" expectation is for > >> userspace, I would probably describe it as "utilizing the monitor's > >> variable refresh rate to reduce stuttering or tearing that can occur > >> during flipping". This is currently what the amdgpu driver has enabled > >> for support. The implementation also isn't much more complex than just > >> passing the variable refresh range to the hardware. Hi, sorry, but that says nothing. Also, tearing has nothing to do here. VRR reduces stuttering if userspace is already tear-free. If userspace was driving the display in a tearing fashion, VRR will not reduce or remove tearing, it just makes it happen at different points and times. Tearing happens because framebuffer flips are executed regardless of the refresh cycle, so adjusting the refresh timings won't help. However... > >> > >> I wouldn't want every driver to be forced to implement some sort of > >> luminance flickering by default. It's not noticeable on many panels and > >> any tuning would inherently add latency to the output. It would probably > >> be better left as a new property or a driver specific feature. The point is to give userspace guaranteed expectations. If the expectation is that some displays might actually emit bad luminance flickering, then userspace must always assume the worst and implement the needed slewing algorithms to avoid it, even if it would be unnecessary. Userspace is farther away from the hardware than the drivers are, and if userspace is required to implement luminance flickering avoidance, that implementation must be done in all display servers and KMS apps that might enable VRR. That would also call for a userspace hardware database, so that people can set up quirks to enable/disable/adjust the algorithms for specific hardware with the hopes that other users could then have a good out-of-the-box experience. Instead, if possible, I would like to see some guarantees from the kernel drivers that userspace does not need to worry about luminance flickering. Unless you would deem all hardware that can exhibit luminance flickering as faulty and unsupported? We need a baseline default expectation. You can modify that expectation later with new properties, but I believe something needs to be defined as the default. Even if the definition is really just "hardware takes care of not flickering". > >> > >> In general I would imagine that most future VRR features would end up as > >> new properties. Anything that's purely software could be implemented as > >> a drm helper that every driver can use. I think the target presentation > >> timestamp feature is a good example for that. > > > > Speaking of timestamps. What is the expected behaviour of vblank > > timestamps when vrr is enabled? > > > > When vrr is enabled the duration of the vertical front porch will be > extended until flip or timeout occurs. The vblank timestamp will vary > based on duration of the vertical front porch. The min/max duration for > the front porch can be specified by the driver via the min/max range. ...This is actually useful information, it explains things. Do all VRR hardware implementations fundamentally work like this? With that definition, there is only more parameter to be exposed to userspace in the future: what is the length of the timeout? No need to expose maximum-refresh-freq because that information is already present in the programmed video mode. Btw. even this definition does not give any hint about problems like the luminance flickering. If possible flickering is an issue that cannot be simply ignored, then something should be documented about it. Do you know of any other "hidden" issues that could require userspace or drivers to be careful in how it will drive VRR? Thanks, pq > No changes to vblank timestamping handling should be necessary to > accommodate variable refresh rate. > > I think it's probably best to update the documentation for vrr_enable > with some of the specifics I described above. That should help clarify > userspace expectations as well. > > Nicholas Kazlauskas
Attachment:
pgpAbmidPbUZw.pgp
Description: OpenPGP digital signature
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
