David Airlie On Tweaking RADV For Better Performance In Deferred Demo

[Tomin]

The only thing thing I wish we had was a decent GUI control panel for the OSS drivers. There are some cool tools available, but AMD needs to get on the ball and put together a unified interface that makes sense. Imo at least. I wish I had the skillz to do it myself. It needs done.

I think there is plenty of other work in addition to actually coding it. First we would need to figure out what functionality we need or would like to have. There should be an Etherpad, Docs file or some wiki page of these. The document should list what can be tuned already and how (through sysfs or other means) and what still needs to be implemented in the drivers. When we have all that, then there is more work on designing it: User interface mockups and such needs to be done. Technically it can be done without, but the result might not be so great and it'd be much easier to implement it with mockups and good idea of what we want. So the most important thing you'd need is time. I'm pretty sure I could work on the coding side, once there is some design.

To my mind it should be a common configuration panel for all Mesa drivers (or at least the most used desktop drivers, i.e. radeonsi, r600, nvc0 and i965) and their kernel drivers (obviously). Whether it's GTK or Qt, I don't think it matters too much (there are other toolkits, but they are probably not worth to consider). I personally would prefer to use Qt since QML is fairly simple to use and one can make easily extendable interfaces with that. Only minor portions of the software would need to be implemented in C++ (or maybe Python). I have more experience with UI programming using Qt (QML and C++) than with GTK (mostly with some old Python bindings).

[haagch]

It's a shame that non-AMD developers do the whole work. – Why should I buy AMD again?!

Because AMD's docs and the existence of the radeonsi mesa driver and the amdgpu kernel drivers made it possible to write radv so quickly in the first place. That's why there is radv, but no open vulkan driver for nouveau. I believe noveau still doesn't even do dynamic power management even though they have amazing developers too.

[haagch]

Anyway, I tried the patch with SteamVR and didn't see the huge improvement I was hoping for. There must still be other areas where it should be possible to squeeze out a lot more performance out of radv.

[agd5f]

The only thing thing I wish we had was a decent GUI control panel for the OSS drivers. There are some cool tools available, but AMD needs to get on the ball and put together a unified interface that makes sense. Imo at least. I wish I had the skillz to do it myself. It needs done.

It's not quite so simple. What would be nice is if the desktop environments came up with a decent display control GUI that was not desktop environment specific. The biggest problem we used to run into with the old fglrx GUI was that every desktop environment stored their display configuration details differently and regularly changed how it was stored. It was a huge pain to keep up with all of them and there were some that we just couldn't support because we had to draw the line somewhere. Additionally when things would change the desktop environment and our GUI would get out of sync and trouble would ensue. Beyond that, we already expose knobs for most controls via sysfs and we use standard Linux hwmon interfaces for things like fans and thermal so desktop environment GUI designers could integrate support for other features into existing display control tools already. And since other drivers use the same hwmon interfaces, it could be done in a generic way to support all GPUs with fan control or thermal sensors for example. Same with drirc and other mesa options. There could be a generic GUI for those as well.

[linuxgeex]

The only thing thing I wish we had was a decent GUI control panel for the OSS drivers. There are some cool tools available, but AMD needs to get on the ball and put together a unified interface that makes sense. Imo at least. I wish I had the skillz to do it myself. It needs done.

Much of the functionality you're referring to is available via environment variables. It wouldn't take much 'skillz' to write a shell script with Zenity to query for some flags, store the results, and launch executables. Have at 'er.

[duby229]

Much of the functionality you're referring to is available via environment variables. It wouldn't take much 'skillz' to write a shell script with Zenity to query for some flags, store the results, and launch executables. Have at 'er.

That's part of it for sure, but not even close to being the biggest part of it for sure.

EDIT: You've heard posts here that the mesa devs say if it ever comes to pass they want the configuration GUI to be driver agnostic. And IMO that's the reasomn why it never happened yet is because configuring graphics requires configuring drivers. And that in turn requires drivers to expose configuration details. And AMD, Intel and whoever else is gonna have to develop there own. It needs done. It needed done in 2007. but here it is a decade later...

[Veto]

What is wrong with "just works (tm)"? A lot of the configuration options in the Windows drivers seem to be either opaque cryptic settings with little effect or just there for the placebo for gamer kidz. Most games provide plenty of configuration options directly anyway.

[duby229]

What is wrong with "just works (tm)"? A lot of the configuration options in the Windows drivers seem to be either opaque cryptic settings with little effect or just there for the placebo for gamer kidz. Most games provide plenty of configuration options directly anyway.

That actually has been the official stance so far. That configuration should be handled in game. The problem is that the quality of one game is not equal to the next and that theory quickly stopped working when games didn't follow suite. Sometimes overriding antialiasing is necessary, but so far impossible.

[linuxgeex]

That's part of it for sure, but not even close to being the biggest part of it for sure.

EDIT: You've heard posts here that the mesa devs say if it ever comes to pass they want the configuration GUI to be driver agnostic. And IMO that's the reasomn why it never happened yet is because configuring graphics requires configuring drivers. And that in turn requires drivers to expose configuration details. And AMD, Intel and whoever else is gonna have to develop there own. It needs done. It needed done in 2007. but here it is a decade later...

Oh I agree with that. xrandr and driconf already hit more things than the Gnome devs would like to expose in a settings manager... I thought you were referring only to tweaks above and beyond what xrandr/driconf expose. I'm pretty sure most of those tweaks are configurable via environment variables. What isn't configurable via environment variables, are configurable via kernel commandline and sysfs.

But what would be truly brilliant would be if, given only power / quality / FPS budgets/ weights via the desktop settings manager (and application-specific variants of those settings), the drivers somewhat intelligently adjusted settings which have performance/quality/power consumption impact to best meet those user-specified requirements. Making that work with multi-GPU and something like a puzzle game with constant radical changes in scenes... even more of a pipedream lol. But I don't think it would be specially challenging to make that work for the likes of Quake, video playback, a composited desktop, darktable.

When I'm on battery on my laptop I really don't need >60fps for Urban Terror... I'd rather have the extra half hour of play instead of the slight edge 120FPS or better might give me. For Trine even 20FPS would be fine. But for Darktable I'm going to want it to max out the GPU usage since taking longer means I can get less work done before the battery dies. For the composited desktop it should aim for 60FPS but on battery I might be OK with it dropping to 30FPS, or even 6FPS for window previews. Again I don't see anything standing in the way of these kinds of pleasantries other than myself being too lazy to implement it lol... and yes I do have scripts to load UT/Trine etc with limits in place depending on the power adapter state, and even to limit Firefox's composite FPS on battery, just not at the libGL.so link-time level.