Announcement

Collapse
No announcement yet.

AMDVLK 2021.Q3.2 Released With New Extensions, Implicit External Sync For All GPUs

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

  • AMDVLK 2021.Q3.2 Released With New Extensions, Implicit External Sync For All GPUs

    Phoronix: AMDVLK 2021.Q3.2 Released With New Extensions, Implicit External Sync For All GPUs

    AMD engineers today published their latest code drop of the AMDVLK official open-source Radeon Vulkan driver for Linux systems...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    While I read almost every AMDVLK article and wish it well, I don't think I've used it since this time last year when I was playing Hitman 2. When you fire up a game and RADV just works you don't bother with the other implementation.

    Comment


    • #3
      Originally posted by skeevy420 View Post
      While I read almost every AMDVLK article and wish it well, I don't think I've used it since this time last year when I was playing Hitman 2. When you fire up a game and RADV just works you don't bother with the other implementation.
      I haven't hesitated to use Mesa from the first day of my navi10. So I have never touched AMDVLK but sometimes I'm still wondering if I shouldn't try it at least once.

      Comment


      • #4
        Originally posted by CochainComplex View Post
        I haven't hesitated to use Mesa from the first day of my navi10. So I have never touched AMDVLK but sometimes I'm still wondering if I shouldn't try it at least once.
        It's pointless: In the vast majority of titles, amdvlk-open either is slower or similarly fast at best, while it has far more bugs, limitations and still a very slow shader compiler.
        RADV has recently gained more optimizations (which partially aren't enabled by default yet) that help titles like Doom Eternal where it used to be slower.

        I think it would be delusional to expect raytracing support in amdvlk-open to be any good, once it might be thrown over the fence some day. It probably will be even more useless than the experimental support in current amdvlk-pro driver (at least to users).

        Comment


        • #5
          For all GPUs?!
          AMDVLK dropped support for many GPUs, lately they dropped support for Pre-Polaris and Pre-Raven GPUs.

          It does not outperform RADV, it does not even work for a lot of games, and it does not even support a lot of older GPUs. If it wasn't for Mesa, a lot of AMD users will not even consider moving to Linux.

          Comment


          • #6
            Originally posted by torbido View Post
            ...wasn't for Mesa, a lot of AMD users will not even consider moving to Linux.
            Indeed Mesa is the Lighthouse of opensource GPU drivers.

            But to be honest I'm glad that AMDVLK exists. You always need at least two competing parties.

            Comment


            • #7
              I'm curious what Valve will use in the Deck with SteamOS 3. It must be a awkward situation to AMD, if they design a custom APU for a client and they choose not to use their driver...

              Comment


              • #8
                Originally posted by M@GOid View Post
                I'm curious what Valve will use in the Deck with SteamOS 3. It must be a awkward situation to AMD, if they design a custom APU for a client and they choose not to use their driver...
                Not really. You even can choose mesa in the pro driver provided by AMD. It's an official solution and even if radv is not supported by AMD I think they wont care much about it as long as they get your money.

                Comment


                • #9
                  Originally posted by M@GOid View Post
                  I'm curious what Valve will use in the Deck with SteamOS 3. It must be a awkward situation to AMD, if they design a custom APU for a client and they choose not to use their driver...
                  That is a no-brainer. It will use RADV. It is Valve that has developed the ACO compiler used by RADV and a lot of the optimization work that has been put into RADV.

                  Comment


                  • #10
                    Originally posted by M@GOid View Post
                    I'm curious what Valve will use in the Deck with SteamOS 3. It must be a awkward situation to AMD, if they design a custom APU for a client and they choose not to use their driver...
                    seeing amd's actions, i have the impression they want to get away from having to make their own drivers. at least on anything not windows. i wouldn't be surprised if internally they would like if someone else picked up the driver development for their products on windows too. i feel like if there was a big open source scene for gpu drivers on windows like there is on linux, amd would have gone the route they did on linux, on windows too.

                    on mac, i believe one of the reasons why apple <3 amd gpu's over nvidia is because apple makes their drivers for them and has more control over the process. and that amd hasn't screwed them over with bad hardware like nvidia did. its really just windows where amd foots most of the software bill.
                    Last edited by middy; 22 July 2021, 04:40 PM.

                    Comment

                    Working...
                    X