Announcement

Collapse
No announcement yet.

AMDVLK vs. RADV Radeon Vulkan Driver Performance For Linux Gaming On Ubuntu 19.04

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

  • #21
    Originally posted by andrei_me View Post
    Both AMDVLK and RADV are open source. If anything, that source would indicate google is using AMDVLK because it links to https://gpuopen.com/games-cgi/ and the open source driver listed there is AMDVLK https://gpuopen.com/gaming-product/a...er-for-vulkan/ (github at the bottom)

    Comment


    • #22
      Originally posted by LeJimster View Post

      They definitely could do a per-game thing. But let's be honest, which driver is more stable, open and well supported with dxvk? If you were going to tell developers to target Linux you would choose RADV every time.

      If google have any driver issues, they will be in a better place to fix them with RADV then AMDVLK.
      RADV has 2 main devs who volunteered to undertake a project that got it working.
      AMD has teams of devs who are paid to make their stuff work.

      AMD and Google have a vested interest in making this happen.

      AMD has the industry contacts and do some of the engineering to help game engines to work on their platform.

      Both implementations are open source. Mesa has a more open contribution model AFAIK.

      While I would prefer a "meeting of the minds" and a single implementation that everyone can focus on as the way forward - I am not involved in the creation of either of these systems, so my say is very small - about 2c worth.

      bridgman is there a chance that AMD VLK will make it into mesa and the powers of RADV and AMDVLK combined? It certainly would help with messaging to game devs/porters and be a net benefit to the community

      Comment


      • #23
        Originally posted by boxie View Post
        bridgman is there a chance that AMD VLK will make it into mesa and the powers of RADV and AMDVLK combined? It certainly would help with messaging to game devs/porters and be a net benefit to the community
        Having more developers not mean better software quality. Examples: AMDVLK and all IBM software.

        Comment


        • #24
          Originally posted by boxie View Post
          bridgman is there a chance that AMD VLK will make it into mesa and the powers of RADV and AMDVLK combined? It certainly would help with messaging to game devs/porters and be a net benefit to the community
          The challenge is that the Vulkan driver supports multiple OSes and the core code (PAL) supports multiple APIs as well, some of which more-or-less require closed source, so having the master copy in Mesa would be tricky. It would require agreement to use Mesa for all the other OSes as well, which does not feel very likely at the moment.

          Splitting the problem into three parts makes answering the question easier - maybe, no and yes:

          Vulkan API layer - supports multiple OSes but not multiple APIs so not too closely tied to the HW. Changes relatively slowly (new extensions/versions) so not impossible to maintain a separate Linux-specific copy in Mesa, and in the meantime OS differences have largely been abstracted out already and we only publish the Linux bits.

          Hardware layer (PAL) - supports multiple OSes and multiple APIs - APIs are much harder to abstract out than OSes because they end up having to be visible all the way down to the code banging on HW. Maintaining a separate Linux-specific copy in Mesa with identical behaviour looks to be quite expensive.

          Shader compiler - any non-LLVM bits could probably be maintained in Mesa fairly easily and we are constantly pushing updates to llvm upstream - probably the easiest to make community friendly (and arguably mostly there already) although "upstream" in this case is llvm rather than mesa.

          As always the tradeoff is between perceived benefits from code sharing via abstraction layers (over-rated in most cases IMO) vs the efficiency of small, single-use code bases with some consideration for sharing low-level code snippets, and people have been disagreeing about that for as long as any of us have been alive.

          It's probably no surprise that teams working with Linux lean towards the "helper functions rather than abstraction layers" model while teams that have to write bottom-to-top code for Windows anyways lean towards the idea of finding ways to re-use that code rather than maintaining a separate copy for Linux.
          Last edited by bridgman; 04-17-2019, 08:46 PM.

          Comment


          • #25
            Originally posted by bridgman View Post

            The challenge is that the Vulkan driver supports multiple OSes and the core code (PAL) supports multiple APIs as well, some of which more-or-less require closed source, so having the master copy in Mesa would be tricky. It would require agreement to use Mesa for all the other OSes as well, which does not feel very likely at the moment.

            Splitting the problem into three parts makes answering the question easier - maybe, no and yes:

            Vulkan API layer - supports multiple OSes but not multiple APIs so not too closely tied to the HW. Changes relatively slowly (new extensions/versions) so not impossible to maintain a separate Linux-specific copy in Mesa, and in the meantime OS differences have largely been abstracted out already and we only publish the Linux bits.

            Hardware layer (PAL) - supports multiple OSes and multiple APIs - APIs are much harder to abstract out than OSes because they end up having to be visible all the way down to the code banging on HW. Maintaining a separate Linux-specific copy in Mesa with identical behaviour looks to be quite expensive.

            Shader compiler - any non-LLVM bits could probably be maintained in Mesa fairly easily and we are constantly pushing updates to llvm upstream - probably the easiest to make community friendly (and arguably mostly there already) although "upstream" in this case is llvm rather than mesa.

            As always the tradeoff is between perceived benefits from code sharing via abstraction layers (over-rated in most cases IMO) vs the efficiency of small, single-use code bases with some consideration for sharing low-level code snippets, and people have been disagreeing about that for as long as any of us have been alive.

            It's probably no surprise that teams working with Linux lean towards the "helper functions rather than abstraction layers" model while teams that have to write bottom-to-top code for Windows anyways lean towards the idea of finding ways to re-use that code rather than maintaining a separate copy for Linux.
            First up - Thank you for your time in responding and as always providing excellent information!

            Your explanation makes sense - the way AMD is setup to develop code is not 100% open source friendly so you do what you can given the constraints you have.

            I guess the root of the problem is fragmentation across various distributions and that makes it harder for a developer to target something. And the story is complicated by required kernel and various driver repo's to get the latest support/features/fixes - and this being left up to the distro's to put in when they feel like it.

            As the Linux desktop gets more and more gaming ability I feel that the current model is a little disjointed - for example:
            * You want the latest perf? add this PPA/COPR to get the latest mesa
            * Oh you have AMD, add this repo to get some extra stuff
            * and if you want to configure something add this adriconf flatpak
            * oh you care about latest feature X, please compile that kernel or install it from a PPA/COPR).

            The distros to their best to get a cut every 6 months or 2 years - but that's a long time between updates.

            There may be an opportunity here though to streamline things though - AMD and Intel are going to both face this problem.

            My ideal solution would be to enable "Gaming Updates" on my desktop/distro of choice and forget about it. Its the sort of frictionless polish that would be awesome to have.

            My question to you bridgman, if you would be so kind, Is :

            Do you see any benefit in some sort of common initiative to get the latest and greatest out to the desktops and can you see AMD leading this effort?

            Thanks again for your time!

            Comment


            • #26
              Originally posted by boxie View Post
              The distros to their best to get a cut every 6 months or 2 years - but that's a long time between updates.
              You can create and use a distribution that is up to date with Debian simple-cdd easily. https://www.youtube.com/watch?v=fKJ-IatUfis

              Comment


              • #27
                Originally posted by debianxfce View Post

                You can create and use a distribution that is up to date with Debian simple-cdd easily. https://www.youtube.com/watch?v=fKJ-IatUfis
                That's not what I want. That's not what my gamer mates want. It is certainly not what Joe Public wants.

                At most I want to be presented with a choice of "Best Performance and newest features" or "Long Term Stability".

                Yes, I know that distro's would need to get on board - but first there needs to be a common graphics setup that all distros can pull from.

                Comment


                • #28
                  Originally posted by boxie View Post
                  That's not what I want. That's not what my gamer mates want. It is certainly not what Joe Public wants.
                  Try my distribution before you judge it. Many people have liked it.
                  Originally posted by boxie View Post
                  At most I want to be presented with a choice of "Best Performance and newest features" or "Long Term Stability".
                  A rolling release OS with latest possible GPU drivers is the way to go.

                  Originally posted by boxie View Post
                  Yes, I know that distro's would need to get on board - but first there needs to be a common graphics setup that all distros can pull from.
                  There are hundreds of Linux distributions. AMD binary packages are for the most popular distributions.

                  Comment


                  • #29
                    Originally posted by debianxfce View Post
                    Try my distribution before you judge it. Many people have liked it.


                    A rolling release OS with latest possible GPU drivers is the way to go.



                    There are hundreds of Linux distributions. AMD binary packages are for the most popular distributions.
                    again, you are missing the point. I am not after each distro implementing some bespoke variation of driver choice.

                    I am looking at the whole ecosystem.

                    I want (those that want to) to adopt a common strategy towards gaming by the industry and distros so that we always have the latest and greatest features supported.

                    AMD release windows drivers more than once a month, these drivers come with fixes and optimisations. The current development models do not allow for this.

                    Comment


                    • #30
                      Originally posted by boxie View Post
                      Do you see any benefit in some sort of common initiative to get the latest and greatest out to the desktops and can you see AMD leading this effort?
                      Definitely see benefit here, and it does get discussed between HW vendors and distros from time to time. A few people have tried leading the initiative at various times (including us IIRC) but everyone seems to get sucked back into more urgent work before being able to get very far.

                      It would be a great topic for the next XDC... which IIRC is actually in Canada this year.

                      EDIT - yep - Montreal, Oct 2-4. Everyone is going to have to learn how to speak Canadian.

                      Comment

                      Working...
                      X