The Experimental GCN 1.0 GPU Support Might Be Dropped From AMDGPU Linux Driver

[ZePanzerTiger]

Are there any news or updates about this?

[sweetsuicide]

>Word has, Navi is HARDLY getting ROCm support any time soon.

Just curious, where is that word coming from ? It's certainly not coming from us.

It seems you guys are VERY careful with your statements about ETAs : https://github.com/RadeonOpenCompute...ment-532886041

[bridgman]

>Word has, Navi is HARDLY getting ROCm support any time soon.

Just curious, where is that word coming from ? It's certainly not coming from us.

[sweetsuicide]

I am too very disappointed. I was researching a bit for a video card working with tensorflow. Surprise surprise, my GCN 1.0 is NEVER going to work. No biggie, I was thinking about changing it with a Navi one. Word has, Navi is HARDLY getting ROCm support any time soon. Ok, I bought my R9 280x for pci-passthrough support, but now nVidia has support for it, too. I am hardly getting a new AMD graphics card, then, if I don't get to use DXVK (which, btw, was working GREAT on my R9 280x) again, after having it working! I feel ashamed of myself.

[hackmatic]

Let me tell you about a tale of 2 architectures.

I'm an AMD user since K6... I replaced my P1-133mhz with an AMD CPU in the long ago. I've been buying your products ever since.

First my original HTPC: Had an RV300 card. No GPU video decoding in linux, not in firefox, not in chrome: shame. It works fine on windows so I use windows.

The computer dies, I get an athlon 64 x2 system. The onboard card is crap. I buy an RV600 card. No video decoding in linux... well at least in firefox. We've now got ungoogled and patched chromium where it's supported. The radeon driver chugs so my video gets out of sync with the audio. I downgrade my kernel to use fglrx and it's passable. Unfortunately I'm stuck at an ancient kernel version for a couple of years. All this on a dedicated video watching machine. Finally this year, in Mint 19.3 performance in the open source driver is acceptable.

Buy a thinkpad Z61. Comes with a firegl GPU! AMD so it has to be great... power management doesn't work in linux: have to run windows Too much heat under Linux, forget about battery It finally works this year when the laptop is good and obsolete.

Last year: I'm gifted some AMD A6 APUs, they are relatively new! Perfect HTPC... Ugh, radeon driver again. At least it supports video decoding... but only H264. Power management is difficult to get working but it finally does and the experience is smooth. Let me try out some dxvk and vulkan... wait! what! Unsupported? But it's on the list and would work under windows. Guess I can't use that.

And finally my main computer: Phenom II Black Edition and R9 280X... was an expensive card over $200. It churns hashes, encodes/decodes and does all sorts of great things: in windows. But 7 is getting out of support so new software will soon stop running. I'm not going to 10, maybe I can use 8.1 or something. I know! I'll use linux. SI is supported in AMDGPU! Between vulkan and wine I can surely replace windows now. Fresh install: wait it's using the RADEON DRIVER AGAIN !!!!!

I do my reading and enable AMDGPU... desktop is flying. Vulkan support! Much faster than the radeon module. Someone even wrote in 2017 it was getting UVD just waiting on AMD to release FW... /lib/firmware.... tahiti_uvd.bin is missing, wtf? I've seen it before. It's under radeon where vulkan doesn't work? Can't I just use the same FW? vdpauinfo/vaapinfo says I can only decode Mpeg2?!?!?!

Now I hear rumblings of discontinued support period. Even though the FW just needs some patches? On my expensive card? Just great... not like there is a pattern here.


Intel:

I hate intel, have to hardware flash the ME support away with a programmer. Always expensive and full of unwanted "features". Drivers have spyware.. even freaking XTU.

Buy some thinkpads, T440 and X250. Around the same vintage as my pricey 280x. Install linux: things just work. New kernel/mesa and X250 can use the iris driver. Vulkan support. Decodes H264 AND VP8. Power management support is great. Windows is fine too. I have a completely different experience and performance is surprising... especially vs the A6 built in.


So gentlemen this is where we are at. The architecture I have hated for years has great support with minimal pain. The hardware I have been buying, even new has let me down almost every single time and it doesn't matter how much money I throw at it, soon it's legacy and only finished when obsolete if at all. I can boot with radeon to watch videos and amdgpu for everything else? HW decoding isn't as important on this system because of the fast CPU but on many machines (including those intels) that is not the case, the heat/battery costs are huge (unless it's just unplayable). The phenom will need upgrades at some point in the future, do I keep coming back to AMD after all of this? As it stands I'll have to run hacks to get 8.1 working and it doesn't look like linux support is any better most of the time. Don't know how bad the Nvidia drivers are since I never bothered to look but it does make one wonder.

[agd5f]

E.g. GNOME Shell, KDE, Xfce, Cinnamon and MATE all have a Display entry in their Settings/Control Panel. Putting on my ordinary user hat, this is where I would expect to be able to control the various knobs for my graphics card(s) (be it intel, AMD or possibly both in the same system), including tweaking per-app rules for iGP or dedicated GPU rendering via RandR.

Therein lies the problem. You have Gnome, KDE, MATE, Xfce, etc. They all store user preferences differently. They all use different toolkits. When we had the Qt GUI for fglrx, it was always breaking because the different desktop environments would regularly change the way they stored user preferences. On top of that we got flack for not supporting native toolkits for other desktops. Now, for non-X desktops, the commonality of X goes away and you need to implement support for GPU specific features in all the compositors directly rather than using randr for display related features. If you want a nice GUI integrated into the existing desktop display tools, you really need to do a direct implementation for every desktop you want to support.

[agd5f]

Shame on AMD. Video decoding was created ages ago by a community member, all they need is to provide a firmware with proper headers.

There is no firmware requirement. See:
https://www.phoronix.com/forums/foru...93#post1149293

[smitty3268]

I tried that, and it doesn't work, I can't just adding wine, it has to be the filename of the game executable like: game.exe.

My point is that Mesa could be trivially updated to make this possible. By writing C code to implement this behavior. It'd be a lot faster and simpler than getting some partial list from AMD that will never be complete, even if you could get it. (Which is probably already possible by just decompiling the windows drivers if you really cared).

[torbido]

My point is you could easily change how it works. .drirc already accepts engine names for Vulkan applications, so it can easily detect all DXVK applications for example. The engine name unfortunately isn't available for OpenGL apps, but it should be fairly trivial to detect WINE in the general case. So just add that and you've automatically got every windows game without having to manually track tens of thousands of application names manually and constantly updating that list every month with new games. That's not sustainable.

Really, something should probably be built into Feral's gamemode to handle this, as the point of that is to try and change how the system responds to games.

I tried that, and it doesn't work, I can't just adding wine, it has to be the filename of the game executable like: game.exe. A shortcut from the right-click menu to pass this application to the dGPU will be a solution, or Mesa passing the games to the dGPU by default will be a better solution, but no, everything has to go the hard way on Linux.

[smitty3268]

When you open any application with WINE it appears in Process Names by its file name, and when you add that file name to the ~/.drirc, and chose to be opened by dGPU, it will be opened automatically by dGPU. That is how it works.

My point is you could easily change how it works. .drirc already accepts engine names for Vulkan applications, so it can easily detect all DXVK applications for example. The engine name unfortunately isn't available for OpenGL apps, but it should be fairly trivial to detect WINE in the general case. So just add that and you've automatically got every windows game without having to manually track tens of thousands of application names manually and constantly updating that list every month with new games. That's not sustainable.

Really, something should probably be built into Feral's gamemode to handle this, as the point of that is to try and change how the system responds to games.