Hi,
(CC dri-devel, Pekka and Martin who might be interested in this as well.)
On Thursday, December 10th, 2020 at 7:48 PM, Aurabindo Pillai aurabindo.pillai@amd.com wrote:
This patchset enables freesync video mode usecase where the userspace can request a freesync compatible video mode such that switching to this mode does not trigger blanking.
This feature is guarded by a module parameter which is disabled by default. Enabling this paramters adds additional modes to the driver modelist, and also enables the optimization to skip modeset when using one of these modes.
Thanks for working on this, it's an interesting feature! However I'd like to take some time to think about the user-space API for this.
As I understand it, some new synthetic modes are added, and user-space can perform a test-only atomic *without* ALLOW_MODESET to figure out whether it can switch to a mode without blanking the screen.
However the exact modes amdgpu adds are just some guesses. I think it would be great if user-space could control the min/max refresh rate values directly. Not only this would remove the need for the kernel to hard-code "well-known video refresh rates", but this would also enable more use-cases. For instance some users might want to mitigate flickering on their screen by reducing the VRR range. Some users might want to lower their screen refresh rate for power savings.
What do you think? Would you be fine with adding min/max VRR range properties?
If you're scared about the user-space code requirement, I can provide that.
Thanks,
Simon Ser
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team with the design, so I have taken the liberty of adding some comments on behalf of the team, Inline.
On 11/12/20 3:31 am, Simon Ser wrote:
Hi,
(CC dri-devel, Pekka and Martin who might be interested in this as well.)
On Thursday, December 10th, 2020 at 7:48 PM, Aurabindo Pillai aurabindo.pillai@amd.com wrote:
This patchset enables freesync video mode usecase where the userspace can request a freesync compatible video mode such that switching to this mode does not trigger blanking.
This feature is guarded by a module parameter which is disabled by default. Enabling this paramters adds additional modes to the driver modelist, and also enables the optimization to skip modeset when using one of these modes.
Thanks for working on this, it's an interesting feature! However I'd like to take some time to think about the user-space API for this.
As I understand it, some new synthetic modes are added, and user-space can perform a test-only atomic *without* ALLOW_MODESET to figure out whether it can switch to a mode without blanking the screen.
The implementation is in those lines, but a bit different. The idea is to:
- check if the monitor supports VRR,
- If it does, add some new modes which are in the VRR tolerance range, as new video modes in the list (with driver flag).
- when you get modeset on any of these modes, skip the full modeset, and just adjust the front_porch timing
so they are not test-only as such, for any user-space these modes will be as real as any other probed modes of the list.
However the exact modes amdgpu adds are just some guesses. I think it would be great if user-space could control the min/max refresh rate values directly. Not only this would remove the need for the kernel to hard-code "well-known video refresh rates", but this would also enable more use-cases. For instance some users might want to mitigate flickering on their screen by reducing the VRR range. Some users might want to lower their screen refresh rate for power savings.
What do you think? Would you be fine with adding min/max VRR range properties?
If you're scared about the user-space code requirement, I can provide that.
This sounds like a reasonable approach, and there is no reason why we can't do this if we have the proper userspace support as you mentioned.
But what we thought would be a sensitive approach towards this feature would be:
- *Phase 1: *Add this feature experimentally as kernel-only change, to:
test out its functionality on all all supported platforms first, without going for the UAPI complexity.
gain attention from UAPI stakeholders and get them involved for the UAPI design (so far so good :)).
- *Phase 2:* Have a design discussions with user-space stakeholders, examine the use-cases possible, and then create a reasonable UAPI, and make the other solution a fallback method.
So I guess we can fork out a parallel discussion for the UAPI thread too. How does this sound to you ?
- Shashank
Thanks,
Simon Ser
On Fri, 11 Dec 2020 09:56:07 +0530 Shashank Sharma shashank.sharma@amd.com wrote:
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team with the design, so I have taken the liberty of adding some comments on behalf of the team, Inline.
On 11/12/20 3:31 am, Simon Ser wrote:
Hi,
(CC dri-devel, Pekka and Martin who might be interested in this as well.)
Thanks for the Cc! This is very interesting to me, and because it was not Cc'd to dri-devel@ originally, I would have missed this otherwise.
On Thursday, December 10th, 2020 at 7:48 PM, Aurabindo Pillai aurabindo.pillai@amd.com wrote:
This patchset enables freesync video mode usecase where the userspace can request a freesync compatible video mode such that switching to this mode does not trigger blanking.
This feature is guarded by a module parameter which is disabled by default. Enabling this paramters adds additional modes to the driver modelist, and also enables the optimization to skip modeset when using one of these modes.
Thanks for working on this, it's an interesting feature! However I'd like to take some time to think about the user-space API for this.
As I understand it, some new synthetic modes are added, and user-space can perform a test-only atomic *without* ALLOW_MODESET to figure out whether it can switch to a mode without blanking the screen.
The implementation is in those lines, but a bit different. The idea is to:
check if the monitor supports VRR,
If it does, add some new modes which are in the VRR tolerance
range, as new video modes in the list (with driver flag).
- when you get modeset on any of these modes, skip the full modeset,
and just adjust the front_porch timing
so they are not test-only as such, for any user-space these modes will be as real as any other probed modes of the list.
But is it worth to allow a modeset to be glitch-free if the userspace does not know they are glitch-free? I think if this is going in, it would be really useful to give the guarantees to userspace explicitly, and not leave this feature at an "accidentally no glitch sometimes" level.
I have been expecting and hoping for the ability to change video mode timings without a modeset ever since I learnt that VRR is about front-porch adjustment, quite a while ago.
This is how I envision userspace making use of it:
Let us have a Wayland compositor, which uses fixed-frequency video modes, because it wants predictable vblank cycles. IOW, it will not enable VRR as such.
When the Wayland compositor starts, it will choose *some* video mode for an output. It may or may not be what a KMS driver calls "preferred mode", because it depends on things like user preferences. The compositor makes the initial modeset to this mode.
Use case 1:
A Wayland client comes up and determines that its window would really like a refresh rate of, say, 47.5 Hz. Yes, it's not a traditional video player rate, but let's assume the application has its reasons. The client tells the compositor this (Wayland protocol still to be designed to be able to do that). (Hey, this could be how future games should implement refresh rate controls in cooperation with the window system.)
The compositor sees the wish, and according to its complex policy rules, determines that yes, it shall try to honor that wish by changing the whole output temporarily to 47.5 Hz if possible.
The compositor takes the original video mode it modeset on the output, and adjusts the front-porch to create a new custom 47.5 Hz mode. Using this mode, the compositor does a TEST_ONLY atomic commit *without* ALLOW_MODESET.
If the test commit succeeds, the compositor knows that changing timings will not cause any kind of glitch, flicker, blanking, or freeze, and proceeds to commit this video mode without ALLOW_MODESET. The whole output becomes 47.5 Hz until the compositor policy again determines that it is time to change, e.g. to go back to the original mode. Going back to the original mode also needs to work without ALLOW_MODESET - but a compositor cannot test for this with atomic TEST_ONLY commits.
If the test commit fails, the compositor knows that it cannot change the timings like this without risking a visible glitch. Therefore the compositor does not change the video mode timings, and the client's wish is not granted.
The client adapts to whatever the refresh rate is in any case.
Use case 2:
A client comes up, and starts presenting frames with a target timestamp (Wayland protocol for this still to be designed). The compositor analyzes the target timestamp, and according to the complex compositor policy, determines that it should try to adjust video mode timings to better meet the target timestamps.
Like in use case 1, the compositor creates a new custom video mode and tests if it can be applied without any glitch. If yes, it is used. If not, it is not used.
This use case is more complicated, because the video mode timing changes may happen refresh by refresh, which means they need to apply for the very next front-porch in the scanout cycle in hardware. Hence, I'm not sure this use case is realistic. It can also be argued that this is better implemented by just enabling VRR and handling the flip timing in userspace, in the compositor: issue an atomic flip at the exact time it needs to be executed instead of issuing it well in advance and letting the driver wait for vblank.
Worth to note: neither case needs the kernel to expose new manufactured video modes. Whether the feature is available or not is detected by an atomic TEST_ONLY commit without ALLOW_MODESET.
However the exact modes amdgpu adds are just some guesses. I think it would be great if user-space could control the min/max refresh rate values directly.
Setting min==max could be used to achieve the fixed refresh rate proposed here, but it would also allow setting custom min < max limits. This would be more flexible, but I'm not sure what the use case for it could look like... oh, there are the use cases mentioned below: user preferences. :-)
Maybe the min/max setting is better than fiddling with custom video modes. If we have min/max to control, then there is no problem with going back to the "original" video mode like in my example use case 1.
Not only this would remove the need for the kernel to hard-code "well-known video refresh rates", but this would also enable more use-cases. For instance some users might want to mitigate flickering on their screen by reducing the VRR range. Some users might want to lower their screen refresh rate for power savings.
What do you think? Would you be fine with adding min/max VRR range properties?
If you're scared about the user-space code requirement, I can provide that.
This sounds like a reasonable approach, and there is no reason why we can't do this if we have the proper userspace support as you mentioned.
Maybe the min/max controls are the way to go, considering that the seamless refresh rate change feature in general cannot be implemented without VRR. Or can it?
But if it can be implemented while not supporting VRR on some hardware, then the video mode fiddling without ALLOW_MODESET is still a usable approach. Or maybe such a driver could special-case VRR=enabled && min==max.
Yeah, min/max controls seems like the best idea to me so far.
Thanks, pq
Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 09:56:07 +0530 Shashank Sharma shashank.sharma@amd.com wrote:
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team with the design, so I have taken the liberty of adding some comments on behalf of the team, Inline.
On 11/12/20 3:31 am, Simon Ser wrote:
Hi,
(CC dri-devel, Pekka and Martin who might be interested in this as well.)
Thanks for the Cc! This is very interesting to me, and because it was not Cc'd to dri-devel@ originally, I would have missed this otherwise.
On Thursday, December 10th, 2020 at 7:48 PM, Aurabindo Pillai aurabindo.pillai@amd.com wrote:
This patchset enables freesync video mode usecase where the userspace can request a freesync compatible video mode such that switching to this mode does not trigger blanking.
This feature is guarded by a module parameter which is disabled by default. Enabling this paramters adds additional modes to the driver modelist, and also enables the optimization to skip modeset when using one of these modes.
Thanks for working on this, it's an interesting feature! However I'd like to take some time to think about the user-space API for this.
As I understand it, some new synthetic modes are added, and user-space can perform a test-only atomic *without* ALLOW_MODESET to figure out whether it can switch to a mode without blanking the screen.
The implementation is in those lines, but a bit different. The idea is to:
check if the monitor supports VRR,
If it does, add some new modes which are in the VRR tolerance
range, as new video modes in the list (with driver flag).
- when you get modeset on any of these modes, skip the full modeset,
and just adjust the front_porch timing
so they are not test-only as such, for any user-space these modes will be as real as any other probed modes of the list.
But is it worth to allow a modeset to be glitch-free if the userspace does not know they are glitch-free? I think if this is going in, it would be really useful to give the guarantees to userspace explicitly, and not leave this feature at an "accidentally no glitch sometimes" level.
I have been expecting and hoping for the ability to change video mode timings without a modeset ever since I learnt that VRR is about front-porch adjustment, quite a while ago.
This is how I envision userspace making use of it:
Let us have a Wayland compositor, which uses fixed-frequency video modes, because it wants predictable vblank cycles. IOW, it will not enable VRR as such.
Well in general please keep in mind that this is just a short term solution for X11 applications.
For things like Wayland we probably want to approach this from a completely different vector.
When the Wayland compositor starts, it will choose *some* video mode for an output. It may or may not be what a KMS driver calls "preferred mode", because it depends on things like user preferences. The compositor makes the initial modeset to this mode.
I think the general idea we settled on is that we specify an earliest display time for each frame and give feedback to the application when a frame was actually displayed.
This approach should also be able to handle multiple applications with different refresh rates. E.g. just think of a video playback with 25 and another one with 30 Hz in two windows when the max refresh rate is something like 120Hz.
Regards, Christian.
Use case 1:
A Wayland client comes up and determines that its window would really like a refresh rate of, say, 47.5 Hz. Yes, it's not a traditional video player rate, but let's assume the application has its reasons. The client tells the compositor this (Wayland protocol still to be designed to be able to do that). (Hey, this could be how future games should implement refresh rate controls in cooperation with the window system.)
The compositor sees the wish, and according to its complex policy rules, determines that yes, it shall try to honor that wish by changing the whole output temporarily to 47.5 Hz if possible.
The compositor takes the original video mode it modeset on the output, and adjusts the front-porch to create a new custom 47.5 Hz mode. Using this mode, the compositor does a TEST_ONLY atomic commit *without* ALLOW_MODESET.
If the test commit succeeds, the compositor knows that changing timings will not cause any kind of glitch, flicker, blanking, or freeze, and proceeds to commit this video mode without ALLOW_MODESET. The whole output becomes 47.5 Hz until the compositor policy again determines that it is time to change, e.g. to go back to the original mode. Going back to the original mode also needs to work without ALLOW_MODESET - but a compositor cannot test for this with atomic TEST_ONLY commits.
If the test commit fails, the compositor knows that it cannot change the timings like this without risking a visible glitch. Therefore the compositor does not change the video mode timings, and the client's wish is not granted.
The client adapts to whatever the refresh rate is in any case.
Use case 2:
A client comes up, and starts presenting frames with a target timestamp (Wayland protocol for this still to be designed). The compositor analyzes the target timestamp, and according to the complex compositor policy, determines that it should try to adjust video mode timings to better meet the target timestamps.
Like in use case 1, the compositor creates a new custom video mode and tests if it can be applied without any glitch. If yes, it is used. If not, it is not used.
This use case is more complicated, because the video mode timing changes may happen refresh by refresh, which means they need to apply for the very next front-porch in the scanout cycle in hardware. Hence, I'm not sure this use case is realistic. It can also be argued that this is better implemented by just enabling VRR and handling the flip timing in userspace, in the compositor: issue an atomic flip at the exact time it needs to be executed instead of issuing it well in advance and letting the driver wait for vblank.
Worth to note: neither case needs the kernel to expose new manufactured video modes. Whether the feature is available or not is detected by an atomic TEST_ONLY commit without ALLOW_MODESET.
However the exact modes amdgpu adds are just some guesses. I think it would be great if user-space could control the min/max refresh rate values directly.
Setting min==max could be used to achieve the fixed refresh rate proposed here, but it would also allow setting custom min < max limits. This would be more flexible, but I'm not sure what the use case for it could look like... oh, there are the use cases mentioned below: user preferences. :-)
Maybe the min/max setting is better than fiddling with custom video modes. If we have min/max to control, then there is no problem with going back to the "original" video mode like in my example use case 1.
Not only this would remove the need for the kernel to hard-code "well-known video refresh rates", but this would also enable more use-cases. For instance some users might want to mitigate flickering on their screen by reducing the VRR range. Some users might want to lower their screen refresh rate for power savings.
What do you think? Would you be fine with adding min/max VRR range properties?
If you're scared about the user-space code requirement, I can provide that.
This sounds like a reasonable approach, and there is no reason why we can't do this if we have the proper userspace support as you mentioned.
Maybe the min/max controls are the way to go, considering that the seamless refresh rate change feature in general cannot be implemented without VRR. Or can it?
But if it can be implemented while not supporting VRR on some hardware, then the video mode fiddling without ALLOW_MODESET is still a usable approach. Or maybe such a driver could special-case VRR=enabled && min==max.
Yeah, min/max controls seems like the best idea to me so far.
Thanks, pq
amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On Fri, 11 Dec 2020 11:28:36 +0100 Christian König ckoenig.leichtzumerken@gmail.com wrote:
Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 09:56:07 +0530 Shashank Sharma shashank.sharma@amd.com wrote:
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team with the design, so I have taken the liberty of adding some comments on behalf of the team, Inline.
On 11/12/20 3:31 am, Simon Ser wrote:
Hi,
(CC dri-devel, Pekka and Martin who might be interested in this as well.)
Thanks for the Cc! This is very interesting to me, and because it was not Cc'd to dri-devel@ originally, I would have missed this otherwise.
On Thursday, December 10th, 2020 at 7:48 PM, Aurabindo Pillai aurabindo.pillai@amd.com wrote:
This patchset enables freesync video mode usecase where the userspace can request a freesync compatible video mode such that switching to this mode does not trigger blanking.
This feature is guarded by a module parameter which is disabled by default. Enabling this paramters adds additional modes to the driver modelist, and also enables the optimization to skip modeset when using one of these modes.
Thanks for working on this, it's an interesting feature! However I'd like to take some time to think about the user-space API for this.
As I understand it, some new synthetic modes are added, and user-space can perform a test-only atomic *without* ALLOW_MODESET to figure out whether it can switch to a mode without blanking the screen.
The implementation is in those lines, but a bit different. The idea is to:
check if the monitor supports VRR,
If it does, add some new modes which are in the VRR tolerance
range, as new video modes in the list (with driver flag).
- when you get modeset on any of these modes, skip the full modeset,
and just adjust the front_porch timing
so they are not test-only as such, for any user-space these modes will be as real as any other probed modes of the list.
But is it worth to allow a modeset to be glitch-free if the userspace does not know they are glitch-free? I think if this is going in, it would be really useful to give the guarantees to userspace explicitly, and not leave this feature at an "accidentally no glitch sometimes" level.
I have been expecting and hoping for the ability to change video mode timings without a modeset ever since I learnt that VRR is about front-porch adjustment, quite a while ago.
This is how I envision userspace making use of it:
Let us have a Wayland compositor, which uses fixed-frequency video modes, because it wants predictable vblank cycles. IOW, it will not enable VRR as such.
Well in general please keep in mind that this is just a short term solution for X11 applications.
I guess someone should have mentioned that. :-)
Do we really want to add more Xorg-only features in the kernel?
It feels like "it's a short term solution for X11" could be almost used as an excuse to avoid proper uAPI design process. However, with uAPI there is no "short term". Once it's in, it's there for decades. So why does it matter if you design it for Xorg foremost? Are others forbidden to make use of it? Or do you deliberately want to design it so that it's not generally useful and it will indeed end up being a short term feature? Planned obsolescence from the start?
For things like Wayland we probably want to approach this from a completely different vector.
When the Wayland compositor starts, it will choose *some* video mode for an output. It may or may not be what a KMS driver calls "preferred mode", because it depends on things like user preferences. The compositor makes the initial modeset to this mode.
I think the general idea we settled on is that we specify an earliest display time for each frame and give feedback to the application when a frame was actually displayed.
That is indeed something completely different, and feels like it would be several years in the future, while the proposed scheme or the min/max properties could be done fairly quickly. But I'm not in a hurry.
Setting the earliest display time for a flip does not fully cover what video mode timing adjustment or min/max frame time or refresh rate property would offer: prediction of when the next flip can happen. Choosing display times requires knowing the possible display times, so something more is needed. The min/max properties would fit in.
This approach should also be able to handle multiple applications with different refresh rates. E.g. just think of a video playback with 25 and another one with 30 Hz in two windows when the max refresh rate is something like 120Hz.
But that's just an extension to what I already described and completely possible with the proposed and the min/max approaches.
Thanks, pq
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100 Christian König ckoenig.leichtzumerken@gmail.com wrote:
Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 09:56:07 +0530 Shashank Sharma shashank.sharma@amd.com wrote:
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team with the design, so I have taken the liberty of adding some comments on behalf of the team, Inline.
On 11/12/20 3:31 am, Simon Ser wrote:
Hi,
(CC dri-devel, Pekka and Martin who might be interested in this as well.)
Thanks for the Cc! This is very interesting to me, and because it was not Cc'd to dri-devel@ originally, I would have missed this otherwise.
On Thursday, December 10th, 2020 at 7:48 PM, Aurabindo Pillai aurabindo.pillai@amd.com wrote:
This patchset enables freesync video mode usecase where the userspace can request a freesync compatible video mode such that switching to this mode does not trigger blanking.
This feature is guarded by a module parameter which is disabled by default. Enabling this paramters adds additional modes to the driver modelist, and also enables the optimization to skip modeset when using one of these modes.
Thanks for working on this, it's an interesting feature! However I'd like to take some time to think about the user-space API for this.
As I understand it, some new synthetic modes are added, and user-space can perform a test-only atomic *without* ALLOW_MODESET to figure out whether it can switch to a mode without blanking the screen.
The implementation is in those lines, but a bit different. The idea is to:
check if the monitor supports VRR,
If it does, add some new modes which are in the VRR tolerance
range, as new video modes in the list (with driver flag).
- when you get modeset on any of these modes, skip the full modeset,
and just adjust the front_porch timing
so they are not test-only as such, for any user-space these modes will be as real as any other probed modes of the list.
But is it worth to allow a modeset to be glitch-free if the userspace does not know they are glitch-free? I think if this is going in, it would be really useful to give the guarantees to userspace explicitly, and not leave this feature at an "accidentally no glitch sometimes" level.
I have been expecting and hoping for the ability to change video mode timings without a modeset ever since I learnt that VRR is about front-porch adjustment, quite a while ago.
This is how I envision userspace making use of it:
Let us have a Wayland compositor, which uses fixed-frequency video modes, because it wants predictable vblank cycles. IOW, it will not enable VRR as such.
Well in general please keep in mind that this is just a short term solution for X11 applications.
I guess someone should have mentioned that. :-)
Do we really want to add more Xorg-only features in the kernel?
Well, my preferred solution was to add the mode in userspace instead :)
It feels like "it's a short term solution for X11" could be almost used as an excuse to avoid proper uAPI design process. However, with uAPI there is no "short term". Once it's in, it's there for decades. So why does it matter if you design it for Xorg foremost? Are others forbidden to make use of it? Or do you deliberately want to design it so that it's not generally useful and it will indeed end up being a short term feature? Planned obsolescence from the start?
Yes exactly. We need something which works for now and can be removed again later on when we have a better solution. Adding some extra modes is not considered UAPI since both displays and drivers are doing this for a couple of different purposes already.
Another main reason is that this approach works with existing media players like mpv and kodi without changing them because we do pretty much the same thing in the kernel which TVs do in their EDID.
E.g. when starting to play a video kodi will automatically try to switch to a mode which has the same fps as the video.
For things like Wayland we probably want to approach this from a completely different vector.
When the Wayland compositor starts, it will choose *some* video mode for an output. It may or may not be what a KMS driver calls "preferred mode", because it depends on things like user preferences. The compositor makes the initial modeset to this mode.
I think the general idea we settled on is that we specify an earliest display time for each frame and give feedback to the application when a frame was actually displayed.
That is indeed something completely different, and feels like it would be several years in the future, while the proposed scheme or the min/max properties could be done fairly quickly. But I'm not in a hurry.
X11 already supports that with the DRI3 extension. Also see VDPAU present and the Vulkan extension for reference application API implementations, so that stuff is already present.
It's just not wired up correctly with KMS and we don't have anything similar in Wayland as far as I know.
Setting the earliest display time for a flip does not fully cover what video mode timing adjustment or min/max frame time or refresh rate property would offer: prediction of when the next flip can happen. Choosing display times requires knowing the possible display times, so something more is needed. The min/max properties would fit in.
Well you need to communicate to the application what the minimum and maximum refresh rates are by some extension of the mode description.
Regards, Christian.
This approach should also be able to handle multiple applications with different refresh rates. E.g. just think of a video playback with 25 and another one with 30 Hz in two windows when the max refresh rate is something like 120Hz.
But that's just an extension to what I already described and completely possible with the proposed and the min/max approaches.
Thanks, pq
On Mon, 14 Dec 2020 21:57:25 +0100 Christian König christian.koenig@amd.com wrote:
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100 Christian König ckoenig.leichtzumerken@gmail.com wrote:
Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 09:56:07 +0530 Shashank Sharma shashank.sharma@amd.com wrote:
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team with the design, so I have taken the liberty of adding some comments on behalf of the team, Inline.
On 11/12/20 3:31 am, Simon Ser wrote:
Hi,
(CC dri-devel, Pekka and Martin who might be interested in this as well.)
Thanks for the Cc! This is very interesting to me, and because it was not Cc'd to dri-devel@ originally, I would have missed this otherwise.
On Thursday, December 10th, 2020 at 7:48 PM, Aurabindo Pillai aurabindo.pillai@amd.com wrote:
> This patchset enables freesync video mode usecase where the userspace > can request a freesync compatible video mode such that switching to this > mode does not trigger blanking. > > This feature is guarded by a module parameter which is disabled by > default. Enabling this paramters adds additional modes to the driver > modelist, and also enables the optimization to skip modeset when using > one of these modes. Thanks for working on this, it's an interesting feature! However I'd like to take some time to think about the user-space API for this.
As I understand it, some new synthetic modes are added, and user-space can perform a test-only atomic *without* ALLOW_MODESET to figure out whether it can switch to a mode without blanking the screen.
The implementation is in those lines, but a bit different. The idea is to:
check if the monitor supports VRR,
If it does, add some new modes which are in the VRR tolerance
range, as new video modes in the list (with driver flag).
- when you get modeset on any of these modes, skip the full modeset,
and just adjust the front_porch timing
so they are not test-only as such, for any user-space these modes will be as real as any other probed modes of the list.
But is it worth to allow a modeset to be glitch-free if the userspace does not know they are glitch-free? I think if this is going in, it would be really useful to give the guarantees to userspace explicitly, and not leave this feature at an "accidentally no glitch sometimes" level.
I have been expecting and hoping for the ability to change video mode timings without a modeset ever since I learnt that VRR is about front-porch adjustment, quite a while ago.
This is how I envision userspace making use of it:
Let us have a Wayland compositor, which uses fixed-frequency video modes, because it wants predictable vblank cycles. IOW, it will not enable VRR as such.
Well in general please keep in mind that this is just a short term solution for X11 applications.
I guess someone should have mentioned that. :-)
Do we really want to add more Xorg-only features in the kernel?
Well, my preferred solution was to add the mode in userspace instead :)
It feels like "it's a short term solution for X11" could be almost used as an excuse to avoid proper uAPI design process. However, with uAPI there is no "short term". Once it's in, it's there for decades. So why does it matter if you design it for Xorg foremost? Are others forbidden to make use of it? Or do you deliberately want to design it so that it's not generally useful and it will indeed end up being a short term feature? Planned obsolescence from the start?
Yes exactly. We need something which works for now and can be removed again later on when we have a better solution. Adding some extra modes is not considered UAPI since both displays and drivers are doing this for a couple of different purposes already.
Another main reason is that this approach works with existing media players like mpv and kodi without changing them because we do pretty much the same thing in the kernel which TVs do in their EDID.
E.g. when starting to play a video kodi will automatically try to switch to a mode which has the same fps as the video.
Aha! That is very valuable information to put this proposal into perspective. I'll leave you to it, then. :-)
Thanks, pq
On 2020-12-14 9:57 p.m., Christian König wrote:
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100 Christian König ckoenig.leichtzumerken@gmail.com wrote:
I think the general idea we settled on is that we specify an earliest display time for each frame and give feedback to the application when a frame was actually displayed.
That is indeed something completely different, and feels like it would be several years in the future, while the proposed scheme or the min/max properties could be done fairly quickly. But I'm not in a hurry.
X11 already supports that with the DRI3 extension. Also see VDPAU present and the Vulkan extension for reference application API implementations, so that stuff is already present.
I suspect you mean the Present extension, specifically PresentOptionUST. There is no working implementation of this yet (the xserver tree has never had any code which would even advertise PresentCapabilityUST, let alone do anything with a timestamp passed in by the client).
Am 11.12.20 um 14:58 schrieb Michel Dänzer:
On 2020-12-14 9:57 p.m., Christian König wrote:
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100 Christian König ckoenig.leichtzumerken@gmail.com wrote:
I think the general idea we settled on is that we specify an earliest display time for each frame and give feedback to the application when a frame was actually displayed.
That is indeed something completely different, and feels like it would be several years in the future, while the proposed scheme or the min/max properties could be done fairly quickly. But I'm not in a hurry.
X11 already supports that with the DRI3 extension. Also see VDPAU present and the Vulkan extension for reference application API implementations, so that stuff is already present.
I suspect you mean the Present extension, specifically PresentOptionUST. There is no working implementation of this yet (the xserver tree has never had any code which would even advertise PresentCapabilityUST, let alone do anything with a timestamp passed in by the client).
Good point, what I wanted to say is that this is already specified in those extensions.
What we are missing is somehow wiring it all together and see how it works.
Christian.
dri-devel@lists.freedesktop.org
-
Christian König -
Christian König -
Michel Dänzer -
Pekka Paalanen -
Shashank Sharma -
Simon Ser