Announcement

Collapse
No announcement yet.

Radeon RX 6600 Linux Performance Rising Even Higher With Newest Open-Source Driver

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

  • #11
    Sorry, but as far as I'm concerned these benchmarks are meaningless. The "Pro" in the Pro drivers' name tells us that it's not meant for gaming but rather professional grade applications, such as compute, OpenCL, heavy OpenGL rendering, etc.

    Retest with GPU powered Blender benchmarks, or any Linux GPGPU Compute benchmarks and I think you see a different outcome.

    Comment


    • #12
      Originally posted by Black_Fox View Post
      RX 6600 (either XT or non-XT) is something I'm eyeing as a replacement for my RX 570 - twice the performance for zero additional PSU wattage. Appreciate the additional test, after the previous kinda disappointing results the non-XT makes sense again!
      Ditto. It sucks that they're basically limited to $700-ish combos, I don't need all the items in the combo, and don't feel like trying to sell the other part. It's like as much as I'd love the 6800 XT + Zaku bundle, I already have a B550 motherboard of the same form factor so it does me no good if I'm not prepared to either sell stuff or build a 2nd rig.

      Comment


      • #13
        Without AMDVLK, the test is not complete

        Comment


        • #14
          Originally posted by mphuZ View Post
          Without AMDVLK, the test is not complete
          AMDVLK hasn't released an RX 6600 official driver yet.
          Michael Larabel
          https://www.michaellarabel.com/

          Comment


          • #15
            Originally posted by Melcar View Post
            Shame you can't get the cards (the few in stock are like $500). Windows comparison would be nice too, since last I checked there was still a substantial gap between the two drivers in many situations.
            I'd like some Windows numbers too: specifically, for the *DX* versions of things under WINE/Proton/etc, because those matter a lot more in practice. But we have to accept that Michael's time is finite.

            In a nutshell: the Windows *GL* drivers are painfully slow for Superposition, unsurprisingly performing at the same sort of level as AMD PRO. The Windows *DX* drivers though show the same sort of 150%-ish results of the Mesa GL driver.

            Comment


            • #16
              Originally posted by arQon View Post

              I'd like some Windows numbers too: specifically, for the *DX* versions of things under WINE/Proton/etc, because those matter a lot more in practice.
              Here's a little tidbit I can provide:

              Just yesterday I tried out "Werewolf: the Apocalypse - Earthblood" {yeah, ideally don't ask but my nephew somehow is a fan of werewolves} and I was sceptical at first since my i5-3350P is below the minimum CPU requirement of a i5-3470, while the recommended GPU is a Radeon R9 290 and my PC has a R9 380.

              So I said to myself: "Let's see how this masterpiece of a game (partially funded by the European Union, no less) would perform when the odds are turned against it."

              Then I proceeded to run it with the following setup:

              - Xubuntu 20.04 LTS & Linux 5.11_"lowlatency"
              - 'Schedutil' CPU governor + mitigations=auto
              - Lutris-GE 6.19 with disabled Esync
              - All maximum settings @ 1080p

              And quite frankly, I was actually impressed how smooth this Unreal Engine 4 title was performing here!
              Only slight hitching when firstly traversing through new areas, but no slowdown whatsoever even during intense combat with all the PhysX goodness!

              I always knew that Linux could easily become the best gaming platform in existence, but now I'm more confident than ever before!

              Steam Deck + SteamOS 3 [for the Exodus of Windows 11 victims] really should bomb Microsoft like they intended to hit the Japanese gaming industry with DirectX (codenamed "Project Manhatten"; you know, like the first atomic bomb project)!

              How's Your experience with gaming on Linux, BTW?

              Comment


              • #17
                Originally posted by Linuxxx View Post
                How's Your experience with gaming on Linux, BTW?
                Minimal, these days: as with historically, WINE continues to be not good enough for even a small library, where "good enough" is defined as "*100%* of that library works acceptably, even if not flawlessly" - because that's the point it needs to reach for it to be practical. Until it clears that bar, ANY other approach, even GPU passthrough, is a better solution because you have to do it at least part of the time, so you might as well do it all of the time.

                Despite the enormous progress that's been made over the last couple of years with Proton etc, it's still just not there yet. But it's getting closer, and at this point it seems to be viable IFF your particular library does work and you only buy games infrequently enough (or ones that are simple enough) that you aren't likely to end up wanting to play something that flat out doesn't work: because as soon as that happens, you're back to square one and either dual-booting or using two cards and passthrough again.

                WineDB tends to present an incredibly dishonest picture of things because WINE users WANT it to work, so you see stuff like "Sound doesn't work at all, mouse actions randomly get lost, and it crashes every few minutes", and then rating the game as Gold or better. I mean, WTF?!

                Despite all that, I'll probably try again sometime next year, because things are moving quickly enough that the picture could be quite different 6+ months from now - but my current system works perfectly for me, so it would be fair to say that spending days screwing around with WINE just to get a worse end result is kind of stupid at best, and outright masochistic at worst. But it's fun to tinker with this stuff if you're in the mood and have the time to waste, so we'll see how it goes...

                Comment


                • #18
                  So this marks the first test where RADV bested AMDGPU-PRO's Vulkan driver in all titles, see the Strange Brigade and Basemark GPU 1.2 results. Or did I miss something?

                  Comment


                  • #19
                    Minor typo alert:

                    For the Vulkan-powered games, using the packaged AMD Linux driver stack at this time was delivering good performance too for those on AMD's supported enterprise Linux distributions. It's namely for the OpenGL games where AMDGPU-PRO performance is atrocious.
                    Guessing the bolded word should be "mainly" ?

                    And yes I realize that me pointing out a typo in that sentence and ignoring the rest of it is reminiscent of at least one Dilbert cartoon:

                    https://dilbert.com/strip/1994-05-24
                    Last edited by bridgman; 27 October 2021, 01:59 PM.
                    Test signature

                    Comment


                    • #20
                      I have recently bought a Radeon RX6600 card, and it works fine with a stock Fedora kernel (5.15.4-201.fc35.x86_64), but I am having a lot of problems configuring my own kernel to use it! I can only assume that the card has some non-obvious dependencies, possibly for the PCIE bus or memory management? For reference, i am currently using:
                      Code:
                      CONFIG_DRM_AMDGPU=m
                      CONFIG_DRM_AMDGPU_CIK=y
                      CONFIG_DRM_AMDGPU_USERPTR=y
                      CONFIG_DRM_AMD_DC=y
                      CONFIG_DRM_AMD_DC_DCN=y
                      CONFIG_DRM_AMD_DC_HDCP=y
                      CONFIG_DRM_AMD_SECURE_DISPLAY=y
                      CONFIG_HSA_AMD=y
                      CONFIG_HSA_AMD_SVM=y
                      CONFIG_DRM_AMD_ACP=y
                      and I have also added:
                      Code:
                      CONFIG_AMD_IOMMU=y
                      CONFIG_AMD_IOMMU_V2=m
                      which provides me with the same kernel modules as the Fedora kernel. However, the GNOME desktop fails during login when using my own kernel, and the dmesg log fills with errors like:
                      Code:
                      Nov 28 12:32:38 endgame kernel: [drm] Fence fallback timer expired on ring gfx_0.0.0
                      Nov 28 12:32:38 endgame kernel: [drm] Fence fallback timer expired on ring sdma1
                      Nov 28 12:32:39 endgame kernel: [drm] Fence fallback timer expired on ring sdma0
                      The fact that Fedora's kernel works OK must mean that my hardware is fine. Does anyone know of any kernel config options I may have missed please?

                      Thanks,
                      Chris

                      Edit: Other significant options seem to be:
                      Code:
                      CONFIG_PCI_P2PDMA=y
                      CONFIG_HOTPLUG_PCI=y
                      CONFIG_HOTPLUG_PCI_SHPC=y
                      
                      CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
                      CONFIG_MEMORY_HOTPLUG=y
                      CONFIG_MEMORY_HOTPLUG_SPARSE=y
                      CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y
                      CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
                      CONFIG_MEMORY_HOTREMOVE=y
                      
                      CONFIG_HMM_MIRROR=y
                      CONFIG_DEVICE_PRIVATE=y
                      but I'm still not there yet..
                      Last edited by chrisr; 29 November 2021, 06:37 AM. Reason: More information...

                      Comment

                      Working...
                      X