On 09/12/2018 12:22 PM, Michel Dänzer wrote:
On 2018-09-12 2:48 p.m., Kazlauskas, Nicholas wrote:
On 09/12/2018 04:13 AM, Michel Dänzer wrote:
On 2018-09-11 6:18 p.m., Nicholas Kazlauskas wrote:
These patches are part of a proposed new interface for supporting
variable refresh rate via DRM properties.
https://patchwork.freedesktop.org/series/49486/
When notified of a window that is FreeSync capable via X these
patches help track when the window is fullscreen to manage the
variable_refresh property on the CRTC.
I'm afraid the Xorg driver support will have to be more or less redone
from scratch for upstreaming:
Whether or not a client wants variable refresh rate enabled can be
tracked via the window property mechanism supported by the core X11
protocol, no need for a protocol extension.
That should also allow simpler tracking of when variable refresh rate
can actually be enabled: It can be enabled while a window is flipping,
and its corresponding property allows it. This should be straightforward
with the Present extension, because that also explicitly marks the end
of a window flipping (via an "unflip"). DRI2 is trickier; it's probably
okay not to support variable refresh rate with that, at least initially.
I can look into this after the upcoming Xorg driver 18.1 releases. Or I
can give guidance if one of you wants to look into it.
I can a look into this. I agree that the extension method is less than
ideal - in being vendor specific mostly. It does have the nice property
that it remains independent of the application's render backend, though.
Not sure what you mean by that. Surely a window property is just as
independent. :)
I was mostly referring to being independent from the backend specific
code in the DDX driver - DRI2/DRI3/present etc. This change turns the
notification from being a callback into polling.
I imagine you're suggesting specifying a window property hint like
_NET_WM_BYPASS_COMPOSITOR - maybe a define new one like
_NET_WM_VARIABLE_REFRESH (even though the two are closely related in
terms of fullscreen behavior). Then in each backend the property could
probably be checked before the present as appropriate.
Right. (Not sure the _NET_WM prefix is appropriate, as it's nothing to
do with the window manager, but that's a detail)
I guess an application could operate independently from the window
manager with variable refresh enabled but it's not certainly a common
use case. I suppose this would probably need additional documentation
patches for the extended window manager standards.
_NET_VARIABLE_REFRESH is probably fine as a name.
This patch series already has the problem you're describing about DRI2
where there's not a nice explicit end notification for flipping - it's
only disabled when the window no longer covers the CRTC or the window is
destroyed (which is the case for most applications but likely not all).
Right. I think it's better to just not bother with DRI2, at least until
there's a specific scenario where variable refresh is really needed with
DRI2.
Nicholas Kazlauskas
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
