Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • So the upcoming Vulkan video decoding won't be including GCN 1.0 GPUs then? Well there goes some of my plans for doing mpv benchmarks.

    Comment


    • Originally posted by bridgman View Post

      For clarity, driconf is the GUI for the drirc file(s) and is what all the distros include today AFAIK... it's just that driconf does not seem to include support for setting DRI_PRIME yet. The adriconf project is creating an alternative GUI.


      Not so much... the database contains options for our Windows DirectX drivers, while WINE translates DirectX calls into OpenGL calls and then runs them on a different driver. Different driver = different quirks/bugs/performance unfortunately.
      There is a project called gpuchooser that uses ~/.drirc to add games' filenames to be switched automatically to dGPU. If a database with all games' filenames can be added to this project from the Windows driver database, it will help to add Switchable Graphics from Windows to Linux. Games' filenames could be native games or Windows games. I tried both, and both work.

      Please, take a look at this project, and tell me if anything can be done to achieve Switchable Graphics on Linux.
      Last edited by torbido; 04 January 2020, 10:14 AM.

      Comment


      • Originally posted by torbido View Post

        There is a project called gpuchooser that uses ~/.drirc to add games' filenames to be switched automatically to dGPU. If a database with all games' filenames can be added to this project from the Windows driver database, it will help to add Switchable Graphics from Windows to Linux. Games' filenames could be native games or Windows games. I tried both, and both work.

        Please, take a look at this project, and tell me if anything can be done to achieve Switchable Graphics on Linux.
        I'm not sure why you think a list of windows games would be helpful. Wouldn't it be easier to just detect if WINE is running? And for native games, it would be different.

        Comment


        • Originally posted by smitty3268 View Post

          I'm not sure why you think a list of windows games would be helpful. Wouldn't it be easier to just detect if WINE is running? And for native games, it would be different.
          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.

          Comment


          • Originally posted by torbido View Post

            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.
            Last edited by smitty3268; 04 January 2020, 06:46 PM.

            Comment


            • Originally posted by smitty3268 View Post

              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.

              Comment


              • Originally posted by torbido View Post
                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).

                Comment


                • Originally posted by asdfgh View Post
                  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:
                  Phoronix: The Experimental GCN 1.0 GPU Support Might Be Dropped From AMDGPU Linux Driver By default the Linux kernel selects the aging Radeon DRM driver for GCN 1.0 "Southern Islands" and GCN 1.1 "Sea Islands" hardware (as well as all older ATI/AMD GPUs) while it's GCN 1.2 and newer that defaults to the

                  Comment


                  • Originally posted by ermo View Post
                    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.

                    Comment


                    • 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.










                      Comment

                      Working...
                      X