Announcement

Collapse
No announcement yet.

AMDVLK 2019.Q4.2 Brings Several More Extensions, Game Tuning

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

  • #11
    Originally posted by jrch2k8 View Post
    RADV is the community Vulkan Driver started before AMD have any open source support for Vulkan on Linux
    Minor correction above...

    Comment


    • #12
      Originally posted by bridgman View Post

      Minor correction above...
      Thanks i forgot AMDGPU-PRO existed at that time.

      Comment


      • #13
        Originally posted by jrch2k8 View Post

        Basically, this is what happened:
        1. AMDVLK is the official AMD opensource vulkan driver but it took way too long to release and by that time the community created RADV and was already in excellent shape.
        2. RADV is the community Vulkan Driver started before AMD have any support for Vulkan on Linux.
        3. AMDGPU-PRO basically AMD closed(ISH) driver for Linux and is basically meant for Enterprise and Enterprise Distros like RedHat(it can work on other distros of course)
        What should you use?:
        1. RADV is the best of the lot and is the official driver that Valve and Co uses for testing, also the official driver used by DXVK/D9VK devs on AMD. Also usually receive bug fixes very very fast from a huge miriad of developers and is integrated on Mesa and available OOB. If you want the faster compiler for games just export RADV_PERFTEST=aco and that is all(you need Mesa 19.2+)
        2. AMDVLK it goes from totally broken to somewhat useful in some games/GPU depending the release version, Only developed by AMD developers, very broken for DXVK/D9VK in a huge list of games, not tested by anyone by default, huge delays on bug fixes BUT with some GPUs it may help until RADV catch up but i usually don't find it worth it because is very annoying to switch back and forth and usually RADV catches up very fast.
        3. AMDGPU-PRO honestly haven't bothered too much with it and last time i tried was extremely broken for 100% of my DXVK/D9VK games and my Native Vulkan games have all kind of issues as well but could have changed at some point. To be fair this driver is meant for Enterprise operation not gaming.

        Rule of thumb for an easy live:

        USE MESA's RADV/RADEONSI, that's it. for 99.99% of the case is the best driver hands down.
        Compute Rule of Thumb

        Install all the LLVM packages and a bare minimum set of packages by hand from the AMDGPU-PRO stack to get OpenCL cranking out in Blender. ROCm is a bag of hurt for that.

        Comment


        • #14
          So in summary, AMDVLK has basically become something thrown over the fence for the RADV devs to inspect and the rest of us to ignore or frown at? Sort of a 'driver resource' or 'documentation' more than a driver anyone really expects to work?

          If this is the case, perhaps someone can shed some light on why the people in charge of AMD driver decisions curiously don't seem to 'get' the benefits of a true 'open development' model as Dave Airlie put it...? What other factors might influence such a decision? Vendor control and cadence?

          Comment


          • #15
            Originally posted by ermo View Post
            So in summary, AMDVLK has basically become something thrown over the fence for the RADV devs to inspect and the rest of us to ignore or frown at? Sort of a 'driver resource' or 'documentation' more than a driver anyone really expects to work?

            If this is the case, perhaps someone can shed some light on why the people in charge of AMD driver decisions curiously don't seem to 'get' the benefits of a true 'open development' model as Dave Airlie put it...? What other factors might influence such a decision? Vendor control and cadence?
            From AMD's perspective, it's an open source driver that they have 100% control over and can do whatever they want with whereas the Mesa driver isn't necessarily the case.

            Here's the Mesa license table:

            Code:
            Main Mesa code    src/mesa/              MIT
            
            Device drivers    src/mesa/drivers/*     MIT, generally
            
            Gallium code      src/gallium/           MIT
            
            Ext headers       include/GL/glext.h     Khronos
                              include/GL/glxext.h
            
            GLX client code   src/glx/               SGI Free Software License B
            
            C11 thread        include/c11/threads*.h Boost (permissive)
            emulation
            It's those "generally" and "permissive" parts may cause issues with closed source drivers they have on Linux, Windows, Xbox 1, PS4, the next gen consoles, etc and having AMDVLK rids them of any such worry.

            Comment


            • #16
              Originally posted by skeevy420 View Post

              From AMD's perspective, it's an open source driver that they have 100% control over and can do whatever they want with whereas the Mesa driver isn't necessarily the case.

              Here's the Mesa license table:

              Code:
              Main Mesa code src/mesa/ MIT
              
              Device drivers src/mesa/drivers/* MIT, generally
              
              Gallium code src/gallium/ MIT
              
              Ext headers include/GL/glext.h Khronos
              include/GL/glxext.h
              
              GLX client code src/glx/ SGI Free Software License B
              
              C11 thread include/c11/threads*.h Boost (permissive)
              emulation
              It's those "generally" and "permissive" parts may cause issues with closed source drivers they have on Linux, Windows, Xbox 1, PS4, the next gen consoles, etc and having AMDVLK rids them of any such worry.
              Not sure that'd be really an issue. src/mesa/drivers contains nothing AMD would ever ship in binary form (just some legacy drivers you can disable during build time), and Boost is a permissive license like MIT (and you can build without if you have a C11 compiler which I hope everyone does these days ...).

              (not saying there won't be other potential skeletons in the closet. I personally find the entire SGI software licensing stuff quite confusing at times myself)

              Comment


              • #17
                Originally posted by loganj View Post
                so you need so many drivers to play 1 game?
                Only one. But AMD and Valve cannot agree.

                Comment


                • #18
                  Originally posted by BNieuwenhuizen View Post

                  Not sure that'd be really an issue. src/mesa/drivers contains nothing AMD would ever ship in binary form (just some legacy drivers you can disable during build time), and Boost is a permissive license like MIT (and you can build without if you have a C11 compiler which I hope everyone does these days ...).

                  (not saying there won't be other potential skeletons in the closet. I personally find the entire SGI software licensing stuff quite confusing at times myself)
                  It's the best guess that I have -- something that's 100% theirs for all their proprietary needs -- because there aren't that many reasons that make sense outside of lawyers and licenses and proprietary, oh my (especially with how open source and Linux friendly AMD is).

                  I suppose bridgman or agd5f may be able to answer "Why AMDVLK?" better, but "100% theirs with no legal worries" is the most logical.

                  Personally, I like multiple options from multiple sources. If you're playing a game with an Nvidia GPU and it doesn't work, that's it. If you're playing a game with an AMD GPU, you have a few more things to try before giving up as well as you can report to a project like DXVK that one works and one doesn't which can potentially help due to having two open source drivers to reference to see how they're doing things.
                  Last edited by skeevy420; 11-09-2019, 08:46 AM.

                  Comment


                  • #19
                    It's quite ironic that SotTR just crashes for me with amdvlk-open, while the changelog of the new version is advertising improvements for the older RotTR. Meanwhile, it just runs on radv and even months old amdvlk-pro without issues.

                    Comment


                    • #20
                      Originally posted by ermo View Post
                      So in summary, AMDVLK has basically become something thrown over the fence for the RADV devs to inspect and the rest of us to ignore or frown at? Sort of a 'driver resource' or 'documentation' more than a driver anyone really expects to work?

                      If this is the case, perhaps someone can shed some light on why the people in charge of AMD driver decisions curiously don't seem to 'get' the benefits of a true 'open development' model as Dave Airlie put it...? What other factors might influence such a decision? Vendor control and cadence?
                      This question comes up a couple of times a year.

                      If you think of AMDVLK as just an open source Vulkan driver for Linux then it seems obvious that a fully open development model would make sense. The point though is we're not talking about just a Linux Vulkan driver - AMDVLK+PAL is a periodic open source extract from a larger (closed source) code base that supports multiple OSes and multiple APIs, some of which we can't even talk about let alone expose.

                      The question then becomes something more like "would it make sense for AMD to fork AMDVLK away from the common code and maintain it independently just for Linux Vulkan ?" and so far the answer to that question has been "no".
                      Last edited by bridgman; 11-09-2019, 03:47 PM.

                      Comment

                      Working...
                      X