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

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

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

    With the continuously evolving RADV Mesa Radeon Vulkan driver and near-weekly updates to the AMD's official "AMDVLK" open-source tree Vulkan driver, how are these competing AMD Vulkan Linux drivers comparing these days? As it's been a while since our last benchmarking comparison of the official AMDVLK driver against the open-source and more common/popular Mesa RADV driver, here are some fresh benchmarks of RADV from Mesa 19.0 on Ubuntu 19.04 as well as 19.1-devel compared to the latest AMDVLK driver code.

    http://www.phoronix.com/vr.php?view=27748

  • boxie
    replied
    Originally posted by bridgman View Post

    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.
    Ay? Sorry! </canadian>

    It certainly would be a good talk to watch / discussion to be had!

    Leave a comment:


  • debianxfce
    replied
    Originally posted by boxie View Post
    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.
    My distribution is leading edge, I bet it is the worlds only one with vulkan freesync support.

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • boxie
    replied
    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.

    Leave a comment:


  • debianxfce
    replied
    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.

    Leave a comment:


  • boxie
    replied
    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.

    Leave a comment:


  • debianxfce
    replied
    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

    Leave a comment:


  • boxie
    replied
    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!

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:

Working...
X