Announcement

Collapse
No announcement yet.

RADV vs. AMDVLK Vulkan Drivers Continue Stiff Performance Battle

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

  • #21
    Hmm... so what's the point behind AMDVLK then? Is there any reason why it should continue to be maintained?

    Comment


    • #22
      Originally posted by sarmad View Post
      Hmm... so what's the point behind AMDVLK then? Is there any reason why it should continue to be maintained?
      As many have said, its needed for Windows and professional customers. Even if it ends up not bein the default on linux, that doesn't mean that having it open on github is not an advantage. The developers behind RADV can look at the code to see what AMDVLK is doing that makes them better at 4K, and there might be bug reports and suggestions coming up on the bugtracker for AMDVLK. It's not that many days aog since I saw a bug on the AMDVLK github reported by one of the RADV developers. Likewise, one might imagine the oposite happening. Just look at the advancemens that has happened to GCC error reporting and build time, and LLVM code generation, that has come as a result of competition, and you can see why two implementations might be good for both parties.

      Edit: Similar story with HipHop / HHVM and PHP 6/7 performance
      Last edited by helland; 18 April 2018, 03:26 PM.

      Comment


      • #23
        Once the CPU bound issues are resolved eventually, AMDVLK and RADV will merge with AMDVLK effectively absorbing the bits that make sense. Or people can keep them separate with AMDVLK absorbing the bits and expanding its overall lead as the code base matures and the cross-platform strategy steadily matures with shared optimizations.

        Comment


        • #24
          Hey AMD, why not just climb on-board RADV for the Linux target? That's were all the cool kids want to be.
          Last edited by Xaero_Vincent; 18 April 2018, 04:04 PM.

          Comment


          • #25
            Originally posted by shmerl View Post
            amdvlk never worked with dxvk for me. Is it a driver bug, or dxvk is doing something incorrectly?
            Read the github. AMDVLK is not currently supported because of poor support for what Mr Rebhole is doing.

            Comment


            • #26
              Originally posted by tomtomme View Post
              Guys. Most of you seem to forget that amdvlk has a big userbase on windows.
              It doesn't with the llvm compiler backend, so parts of the AMDVLK code has, but major parts don't.

              Comment


              • #27
                Originally posted by marek View Post
                Valve seems to lead RADV development and Feral also contributes to it. That might indicate what game developers care about.
                Are these two really game developers? AFAIK, Feral is porter and Valve's game development looks to me like minor and part time job, considering what else that co do

                In industry it is normal that everbody does his job, so game developers should do game development and driver developers should do driver development... these might only share ideas and bugs of course

                Do you want perfect driver? Cool, then game developers should be like any other user, yes like any other. Just share ideas (and code) and bugs, ideas and bugs... and pretty much nothing else

                Real game developers won't touch your driver, they would only say "please implement this or that, please fix this or that, etc..".
                Last edited by dungeon; 18 April 2018, 07:22 PM.

                Comment


                • #28
                  Originally posted by airlied View Post

                  It doesn't with the llvm compiler backend, so parts of the AMDVLK code has, but major parts don't.
                  That's an interesting tid bit. I think I will have to adjust my wild shared code estimate from 90% down to 75%.

                  Comment


                  • #29
                    Originally posted by tomtomme View Post
                    Guys. Most of you seem to forget that amdvlk has a big userbase on windows.
                    The new LLVM-based shader compiler stack that is unique to the Linux version is the main issue with AMDVLK at the moment. Everything else seems pretty solid. With DXVK I've seen driver crashes, shaders failing to compile for no reason, shaders producing wrong results, and stuff that was working in one revision regressing in the next one. What I haven't seen so far is a single game that actually works.

                    As a developer, why would I bother with it? Everyone and their mother targets RADV on Linux. It's part of Mesa so people usually have it installed anyway (if not, there's a package for it), it works reasonably well, it's actively being tested with a lot of Vulkan games, and if you have a problem with it, it's easy to get in touch with the devs and get things fixed (unless it's an LLVM bug, but AMDVLK runs into those as well). If you need support for a new Vulkan extension, annoy them for a bit and eventually you'll get your extension implemented.

                    It's not a bad thing that AMDVLK exists as an open-source driver, quite the contrary. To AMD's credit, they *do* take bug reports seriously and fix them in a resonable amount of time. But I really don't see why the average Linux gamer would start using it over RADV.

                    Originally posted by SethDusek View Post
                    Maybe if they follow the vulkan spec properly instead of doing driver-specific hacks, that AAA game will work fine on pretty much any driver?
                    If only it was that easy.

                    Spoiler: It isn't. Just recently I spent one and a half days debugging this little issue in RADV which broke FInal Fantasy 14. On the Nvidia side of things, this small bug popped up a few days ago which prevents some games from running.

                    No CTS test or real-world application have triggered those bugs before so nobody noticed them until now. And you'll always stuble across issues like that. Especially since we're not talking about an old API like D3D11 here that has been around for almost a decade with a massive user base. This is Vulkan, 2 years old, used almost exclusively for Linux gaming and mobile devices.
                    Last edited by VikingGe; 18 April 2018, 06:50 PM.

                    Comment


                    • #30
                      Originally posted by tomtomme View Post

                      But amdvlk is largely Amds windows driver. Only very limited manpower is needed to drop the new windows Vulkan driver code every week once the Linux build system for the driver was up and running. Legal review was likely what took them so long
                      I understand that the original hold up was largely due to legal reasons but that does not change the case of which takes less effort? And it certainly takes more than very limited manpower to do their code drop. Don't underestimate the effort involved in the platform specific bits even if it makes up only 10% of the codebase. The in-kernel driver and parts of the compiler backend are quite drastically different on Linux compared to Windows and require very platform specific optimisations to get the very best performance on-top of the extra testing required.

                      I'm curious if the legal reviews still and will persist for AMDVLK? bridgman do you guys still have to go through those reviews before your code drops or is it non-existant now?

                      Comment

                      Working...
                      X