FreeSync Support For RADV Vulkan Driver Blocked By Lack Of Config System

[dungeon]

This article raises so many questions. Like, why the heck does this tech need a white- or blacklist in the first place?

Well, nothing require blacklist managment if people understand how things works, but also why it does not sometimes

Clearly I don't understand what freesync is...

Exactly becuase of that blacklist managment is needed, as some people seems don't understand

[ssokolow]

I don’t quite understand the explanations given so far. If the mouse pointer is the problem, then why isn’t it possible set the display frequency to some minimum frequency like 60 Hz (depending on the monitor), whenever the mouse pointer is being displayed (or moving) ?

Theoretically, anything is possible as long as it's within the range of FreeSync refresh rates the monitor hardware will accept. The problem is that the developers look at it and see it as not worth the amount of effort it would take to implement.

Heck, if it's a laptop display connected via Embedded DisplayPort 1.3 or newer, the display could support Panel Self-Refresh, which effectively brings the minimum refresh rate down to zero by putting framebuffer memory in the display itself and allowing it to hold an image for however long the PC wants to leave it static. IIRC, since then, a newer version of the eDP standard has added support for VNC-like partial update support.

[skeevy420]

Many Linux developers are so full of them that the customer is wrong always. Requiring to compile mesa to use this patch is communism. Communist forces you to work.

Here is the Padoka ppa Mesa git compatible /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so file, it is not compatible when the ppa is updated.

https://drive.google.com/open?id=13d..._LnA5uXcnN5aU4

Requiring to go to Google, discover Phoronix, find a post by debianxfce, download some file, and then run as root to cp -r that file is a lot of work.

debianxfce forces you to work. debianxfce is a communist.

[indepe]

I don’t quite understand the explanations given so far. If the mouse pointer is the problem, then why isn’t it possible set the display frequency to some minimum frequency like 60 Hz (depending on the monitor), whenever the mouse pointer is being displayed (or moving) ?

[LinAGKar]

So if you were watching a 24fps video in your opengl/vulkan video player (like mpv), and FreeSync got enabled, your entire display would be refreshing at 24Hz.

Which is what you want (or a multiple of it), otherwise you get unsmooth video playback, unless the screen just happens to be perfectly in sync with the video. For example, without Freesync, 24/25/29.97/59.94 Hz video on a 60 Hz screen is unsmooth.

[Ropid]

I thought that this technology originated in notebooks to save power. And browsing the web and working on the desktop is an important task. Are these limitations you talk about fixable? And by whom?

The argument about scrolling on a web page is not a good argument. Scrolling will work fine with FreeSync, the refresh will be done when the browser asks to redraw the contents of its window. Latency will be better than without FreeSync.

There really is just the mouse pointer being a problem. It is managed separately from the rest of the graphics you see on the screen. The image for the pointer is not part of the framebuffer. The hardware adds it to the output that it sends to your monitor.

So when you move the mouse pointer around, this does not change anything about the framebuffer contents. It only updates the internal position for the pointer in the GPU hardware. Things will then look terrible in practice, the pointer will stutter around at 35Hz or whatever the lowest possible refresh rate of your FreeSync monitor is.

A hack should be possible where software triggers a refresh whenever the mouse pointer position changed. I guess the problem is where to add this hack. The driver is maybe not a good place? Maybe it should be added to the compositor? Or maybe the Xorg server should have it?

It could be possible to get the compositor to lower refresh rate to save power whenever the screen is static, but I've not seen anyone interested in putting in the development effort to make that happen and I'm not sure it's worth it because some cheap displays flicker at low refresh rates and the power saving are small although it could make sense in battery powered devices.

This is already how compositors work, at least in the case of compton and xfwm's compositor and marco's compositor. They only do their compositing work when a damage event happened for window contents. If there's no window on the desktop that changed anything about its graphics, they will wait and do nothing.

A way to take a look at how this behaves in action is to first stop any compositor that's running, and then use compton's GLX backend and use the Mesa driver's "gallium hud" feature to get an fps counter. Start compton like this:

GALLIUM_HUD=fps compton --backend glx

You'll see that in a situation where nothing changes on the desktop, everything will freeze completely because compton will refresh at 0fps. If there's something on the screen that periodically updates its graphics, like a video player, then the fps of compton will be whatever rate that program uses to update its graphics.

[M@yeulC]

Interesting, I wonder if a Vulkan extension for opting in wouldn't help alleviate this issue somewhat (and would be better going forward, especially as not a lot of applications are Vulkan-native). I can see for instance DXVK and various game engines using this, or the lone desktop application tat wants to enable VRR (fullscreen videoplayer).

Otherwise, fullscreen Vulkan applications make a nice default target (while blacklisting compositors). Ideally, Wayland compositors would manually set the DRM property when they know the windows being displayed would benefit.

I think you haven't understood what I meant.

Let's say you have an n x m grid of color values and you diff one value in a square of x fields from each consecutive image, so when you move your mouse and diff enough pixels you will notice that the white pixel on your web page suddenly got black.
So increasing value gaps of many pixels mean increasing refresh rates and decreasing gaps mean decreasing refresh rates.

And indeed, I don't have the slightest clue what RadeonSI, RADV or even single windows have to do with that.

Edit: Except from providing an API call to fix a certain rate in fullscreen applications, or deactivating VRR, of course.

I must confess that I didn't really understand this. However, I know that cursor rendering is usually done on a hardware "cursor plane", to avoid changing the buffer the application draws/is composed in. Compositing the hardware planes is then done in hardware during scanout. This might or might not be related to what you were trying to say.

[Brisse]

I thought that this technology originated in notebooks to save power. And browsing the web and working on the desktop is an important task. Are these limitations you talk about fixable? And by whom?

It could be possible to get the compositor to lower refresh rate to save power whenever the screen is static, but I've not seen anyone interested in putting in the development effort to make that happen and I'm not sure it's worth it because some cheap displays flicker at low refresh rates and the power saving are small although it could make sense in battery powered devices.

IMHO, the only situation where Freesync really makes any sense outside of gaming is fullscreen video playback. Lots of common video framerates don't play nicely on a 60hz display. Freesync can solve that issue while also lowering power consumption during fullscreen video playback, but it needs a bit of development and testing efforts first. Windows 10 with it's default video app shows it can work well but that's because it specifically supports Freesync. You can't just enable it for any video player and expect it to work. I've tried with a few free open source video players on Windows and none of them work properly because they don't support the API that Windows provides for this purpose.

[oooverclocker]

I thought that this technology originated in notebooks to save power.

Not only but mainly.

Are these limitations you talk about fixable? And by whom?

I am pretty sure that they are fixable - see post #10 - and just from my feeling I would rather look at the AMDGPU code to find out...

[ms178]

No. Your mouse pointer would stutter and lag terribly, scrolling the page would be horrible and animations would look bad. Some cheap displays might even flicker.



If the video is played in fullscreen then yes, assuming it would work properly which probably isn't the case with any browser right now, so for now they need to be blacklisted.

I thought that this technology originated in notebooks to save power. And browsing the web and working on the desktop is an important task. Are these limitations you talk about fixable? And by whom?