Marek Takes To RadeonSI Tweaking For Unigine Superposition

[FireBurn]

I put R600_DEBUG=sisched,unsafemath,precompile in my /etc/environment ages ago and totally forgot it was there

[bridgman]

And how does calling it R600 help? It's also specific. At least RADEON itself is a generic enough name.

The code implementing the debug option is in the r600 mesa driver, and options generally follow the name of the driver they appear in. The "radeon" mesa driver is only used for R100-family hardware.

https://lists.freedesktop.org/archiv...ch/035537.html

[dungeon]

Hardcoded instead of using drirc? Brrrrr

Brrrrr, Gentoo user runs profiles since forever, but call them USE flags

[shmerl]

The code implementing the debug option is in the r600 mesa driver, and options generally follow the name of the driver they appear in.

I see, but at the same time it's shared with radeonsi isn't it? So the name is actually confusing given that radeonsi supposedly should get the vast majority of usage

Also, why are such variables not documented here: https://www.mesa3d.org/envvars.html ?
One very useful I found which helps some old games is for enabling forced anisotropic filtering (great for example for VtM Bloodlines in Wine):

R600_TEX_ANISO=16

But I really had to dig through the code to find its name.

[marek]

We often consider optimizing benchmarks cheating, too... I mean that's more common an accusation in the Android world, I suppose, with companies like OnePlus. But I mean if sisched is almost dead, rarely used, not going to be the default... but we're using it specifically to optimize benchmarks?

There is a plan to have a better solution and one that would work with all apps. I can't tell you more. This tweak is just an interim solution, and also a way to inform and inspire people within and outside of AMD about a potential to improve performance everywhere. Note that it's a small performance improvement, not one that has a huge impact. The current driver performance is already mostly within market expectations, though it's always good to have more.

[marek]

I understand that, but following the news specifically for Radeon drivers on Linux, a LOT of work appears to be going on involving environment variables and application-specific optimizations. AMD drivers are the only ones I see being discussed with using various environment variables to improve performance to a point that is still not very good. I'm not saying you're wrong to do this thing but your answer doesn't really help me understand it (which is fine in itself; our opinions don't have to be the same).

Application-specific optimizations are common in closed drivers. Not so much with Mesa. If I add one app-specific tweak to Mesa, you'll hear about it pretty quickly. If a competing company adds two hundreds app-specific tweaks to their drivers in order to be competitive, nobody will know.

[smitty3268]

There is a plan to have a better solution and one that would work with all apps. I can't tell you more. This tweak is just an interim solution, and also a way to inform and inspire people within and outside of AMD about a potential to improve performance everywhere. Note that it's a small performance improvement, not one that has a huge impact. The current driver performance is already mostly within market expectations, though it's always good to have more.

Well now we know what's holding up the Vulkan driver, hmm.

I was about to say that this at least needs to be investigated to determine why the different scheduler is faster. At the very least to just leave as a code comment so others later on will know what could change with new hardware that might affect it's usefullness.

But i guess if it's designed to be a temporary measure it all doesn't matter that much.

[bridgman]

I see, but at the same time it's shared with radeonsi isn't it? So the name is actually confusing given that radeonsi supposedly should get the vast majority of usage

The drivers inherit & share code "forward" not "backward" (since newer drivers are written after the earlier drivers) so shared code generally lives in the oldest driver that participates in sharing. Same with naming conventions - the driver handling r3xx/4xx/5xx is called r300 rather than r500 because when it was written we knew what the first HW generation was but not what the last generation would be.

Also, why are such variables not documented here: https://www.mesa3d.org/envvars.html ?

Good question -- I'm not sure how updates get into that page, maybe via Brian. Looking at the page I get the impression that slower changing drivers are covered but fast changing drivers are not.

Well now we know what's holding up the Vulkan driver, hmm.

Huh ?

[dungeon]

Looking at the page I get the impression that slower changing drivers are covered but fast changing drivers are not.

Fast changing shouldn't have nor does not deserve documentation ... Joke aside - it is a mess Say on SI/CIK with radeon you see one options while with amdgpu another, on different versions one options or another and so on.

It is better to say run R600_DEBUG=help and maybe xdriinfo options to see what you have currently available or as OP said just reads the code

Rolling mess you know - proper docs impossible to be written

[bridgman]

Fast changing shouldn't have nor does not deserve documentation ... Joke aside - it is a mess Say on SI/CIK with radeon you see one options while with amdgpu another, on different versions one options or another and so on.

Are you sure ? My understanding was that the same options were available no matter which kernel driver was used.

It is better to say run R600_DEBUG=help and maybe xdriinfo options to see what you have currently available

Yep, adding the parts that don't change quickly would be a good idea - then again it's possible that the only reason newer drivers aren't documented there is that nobody scrolled down far enough to realize there were driver specific options on the page. I hadn't done that until today.

or as OP said just reads the code

That's what the page says now