Radeon RX 550: AMDGPU-PRO vs. DRM-Next + Mesa 17.2-dev

[nuetzel]

And r600g should be slightly better with today's Mesa-git, because there was some more small optimizations.

He, he,...;-)

Well, as far as I can see, the last one actively contributed to r600g was Vadim Girlin, the author of r600g/sb compiler. He disappeared around 2014. From that point r600g was just occasionally tweaked by different peoples.

Hello Hi,
you missed reg spilling efforts by Glenn:
[Mesa-dev] r600g: Support spilling temp arrays
https://lists.freedesktop.org/archiv...ch/146653.html
No one tested it so far except me.
https://lists.freedesktop.org/archiv...ch/147424.html
But no reply from Glenn...

and
Elie's work on fp64 for r600g:
[Mesa-dev] [PATCH 3/3 v2] r600g: get rid of dummy pixel shader
https://lists.freedesktop.org/archiv...il/153178.html

AMD are focused on radeonsi.

Yes, mostly.
Do you want my Turks XT / HD 6670, 2 GB for free?
My Nitro+ RX580 8 GB arrived on Thursday and is up and running since Saturday (some complications with my Fujitsu _server_ mobo and PSU (connectors)).
Or should I try to swap it in and out from time to time?

Maybe offer it Elie?

Greetings from Germany!

Dieter

[marek]

My question is (and i believe that i speak with someone intelligent), why don't you offer a Gallium D3D11 state tracker? You know that you will win Linux if you do right? It doesn't have to be officially by you, you can just donate a sum to someone outside AMD and without giving technical assistance. We can also assist with donation or other means if there is a request.

There are multiple factors why a D3D11 state tracker is not happening:
- Some DX11 games have native ports (e.g. by Feral).
- Wine wouldn't accept it.
- The user base would probably be very tiny (a few users with patched Wine at most).
- The development cost isn't worth it given the estimated number of users.
- There are no unemployed talented people to do it and if there were, they would already be hired by AMD, Red Hat, or Valve and working on something else.

[dungeon]

I think that mesa here looks much more better than it actually is, thanks to this horribly regressed pro

Or better to say pro is still borked than regressed, as it sort of borked since fglrx switch

Or the best to say AMD proved how they can do it even worse than before and i don't think their PRO customers are happy

[artivision]

- There are no native ports, thats why we call 'em ports, because they translate internally with no more than 70% efficiency and that from source.
- Almost all Linux gamers have a patched version of Wine that they didn't build them selves, from some repository.
- Many gamers stay on Windowz only because of gaming wile they are advanced crowd that can easily use Linux and teach that to others less advanced.
- The cost is just one developer like with the case of Gallium Nine. Similar work has be done in Wine. Also some OGL state tracker code may be valid.
- I'm sure that someone will do it eventually and we will be support him if he asks.
- Graphics API state trackers are old technology. We don't need talent to reproduce them today. Maybe it was hard ten years ago.

[boltronics]

There are multiple factors why a D3D11 state tracker is not happening:
...
- Wine wouldn't accept it.
- The user base would probably be very tiny (a few users with patched Wine at most).
- The development cost isn't worth it given the estimated number of users.

This strikes me as a lack of vision! Nine-patched Wine is massively faster than standard Wine, and likely always will be. It may well be the biggest killer feature AMD has over Nvidia's proprietary drivers on GNU/Linux (aside from being free, of course). Get someone to sort out a D3D11 state tracker, add some benchmarks to OpenBenchmarking for Michael to include in his articles, and release easily accessible and frequently updated patched Wine builds for the top 5 major distros (the community would assist with this). Soon enough, everyone will be using it instead of regular Wine, everyone will be purchasing AMD GPUs, and eventually the Wine project will have to surrender and include the patches because most users on GNU/Linux will be using them.

Also consider that there are plenty of SteamOS games that are simply distributed in Wine wrapped form. This would likely happen far more frequently with a D3D11 state tracker, and GNU/Linux users would be very happy to have the extra games available. Imagine... a bunch of games on Steam that are only compatible with AMD GPUs (as opposed to the bunch of games that were released during the AMDGPU transition that only officially supported Nvidia). Even when D3D11->OpenGL in Wine standard eventually works well enough that Nvidia is supported too, AMD will have a massive performance advantage for those Wine-wrapped Steam games.

[Hi-Angel]

He, he,...;-)



Hello Hi,
you missed reg spilling efforts by Glenn:
[Mesa-dev] r600g: Support spilling temp arrays
https://lists.freedesktop.org/archiv...ch/146653.html
No one tested it so far except me.
https://lists.freedesktop.org/archiv...ch/147424.html
But no reply from Glenn...

and
Elie's work on fp64 for r600g:
[Mesa-dev] [PATCH 3/3 v2] r600g: get rid of dummy pixel shader
https://lists.freedesktop.org/archiv...il/153178.html



Yes, mostly.
Do you want my Turks XT / HD 6670, 2 GB for free?
My Nitro+ RX580 8 GB arrived on Thursday and is up and running since Saturday (some complications with my Fujitsu _server_ mobo and PSU (connectors)).
Or should I try to swap it in and out from time to time?

Maybe offer it Elie?

Greetings from Germany!

Dieter

Wow, thank you, I feel embarrassed Anyway, I don't have a desktop, my HD5730 is "unreplaceble" because it's a laptop GPU

[tomtomme]

This would be great if the open source drivers supported OpenGL 4.5, but since they don't, and the developers have promised they never will, the point is rather moot. If you want to run Steam under Wine or play many games that require it you have to use AMDGPU-PRO. And yes, I've tried the various environment variables that are supposed to "fool" software into believing the open source drivers support OpenGL 4.5 compatibility mode, but they didn't fool anything I've tried. And for those who say the multitudes of software that use compatibility mode are "crap" or "buggy", that's ridiculous. Steam itself uses compatibility mode, and if people want to claim it's buggy or crap, well, I don't believe any amount of reality will change their minds. And for a driver producer to believe that all the games and software in the world that use compatibility mode should be rewritten, instead of them supporting this common feature, well, again, no amount of reality will change their minds.

would you be so kind to add the games that use compat-profiles and don´t start for you on Mesa to this list? : https://www.gamingonlinux.com/wiki/G...bility_Context

devs will only consider improving the situation if the problem looks big - and right now the problem looks tiny. Only 4 games on this list that still require a compat profile.

[forkbomb]

This strikes me as a lack of vision! Nine-patched Wine is massively faster than standard Wine, and likely always will be. It may well be the biggest killer feature AMD has over Nvidia's proprietary drivers on GNU/Linux (aside from being free, of course). Get someone to sort out a D3D11 state tracker, add some benchmarks to OpenBenchmarking for Michael to include in his articles, and release easily accessible and frequently updated patched Wine builds for the top 5 major distros (the community would assist with this). Soon enough, everyone will be using it instead of regular Wine, everyone will be purchasing AMD GPUs, and eventually the Wine project will have to surrender and include the patches because most users on GNU/Linux will be using them.

Also consider that there are plenty of SteamOS games that are simply distributed in Wine wrapped form. This would likely happen far more frequently with a D3D11 state tracker, and GNU/Linux users would be very happy to have the extra games available. Imagine... a bunch of games on Steam that are only compatible with AMD GPUs (as opposed to the bunch of games that were released during the AMDGPU transition that only officially supported Nvidia). Even when D3D11->OpenGL in Wine standard eventually works well enough that Nvidia is supported too, AMD will have a massive performance advantage for those Wine-wrapped Steam games.

Nine-patched wine IS a killer feature. Honestly the performance difference between vanilla and patched Wine isn't even funny. Just one example, Guild Wars 2 is very choppy on Wine staging (10-20FPS), runs flawlessly (30-50 FPS) under Nine (R9 270x).

I run a patched Wine + Mesa/LLVM git repo for myself on OBS for OpenSUSE (based on Pontostroy's repo which sadly isn't maintained anymore. So far only for personal use (I don't do much testing except use it myself).

[coder111]

God dammit. I'm in the same boat (laptop with Radeon 6550M). I cannot replace, and I cannot buy a decent new AMD-based laptop with dGPU...

I'll probably build myself a small desktop with Ryzen soon once mini-ITX boards show up. The reason why I'm using a lapop is because I don't have enough space for a desktop, not because I travel. And then I'll get a monitor bolted to the wall with a monitor arm.

Wow, thank you, I feel embarrassed Anyway, I don't have a desktop, my HD5730 is "unreplaceble" because it's a laptop GPU

[nuetzel]

Nine-patched wine IS a killer feature. Honestly the performance difference between vanilla and patched Wine isn't even funny. Just one example, Guild Wars 2 is very choppy on Wine staging (10-20FPS), runs flawlessly (30-50 FPS) under Nine (R9 270x).

Hello forkbomb,
I haven't have that much games (I'm a developer) but demand from our kinds evolve...8-)
So I only have some numbers for Farming Simulator LS2015 and LS 2017 (!!! - started working with wine ~2.3 and shine since 2.7, only glance and some shadows are missing, now), Wine Steam (PES2015 and TS2017).
Wine staging shine here, too.

Now our son would buy DiRT Rally Linux Steam version, but ~50 € is to much for his pocket money.
So I have to look for a cheaper deal (devel key)?
Hello Feral!!! ;-)

I run a patched Wine + Mesa/LLVM git repo for myself on OBS for OpenSUSE (based on Pontostroy's repo which sadly isn't maintained anymore. So far only for personal use (I don't do much testing except use it myself).

I'm with 'you' for over 23 years (running S.u.S.E).
Now I'm on openSUSE Tumbleweed with Kernel:stable (Kernel:HEAD for amdgpu, 4.12 should fix the VM speed regression), KDE:Extra, XOrg, Packman and games.

For Wine+staging I'm runnig _YOUR_ 'repo' (home:forkbomb:turboAMD) after Pontostroy's fade out. - Thank you very much for your effort!
Dieter