Announcement

Collapse
No announcement yet.

Testing The Open-Source "RADV" Radeon Vulkan Driver vs. AMDGPU-PRO

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

  • bridgman
    replied
    Originally posted by Mystro256 View Post
    Does this mean the release is just stalled but is still coming? or do you have no idea/not allowed to say?
    If it were not for radv I would have said "still coming but going very slowly" (whereas OpenCL is going better). Given the progress with radv my thinking has been to change our open sourcing focus from tackling the hard parts first (rewriting the big chunks) to tackling the easy parts first in areas where they might help radv. Still under discussion.

    There has been enough progress that we might be able to do something like releasing sooner but with "raw" replacement code, then improve the replacement code after release. Ask again in a week or two.
    Last edited by bridgman; 30 August 2016, 05:08 PM.

    Leave a comment:


  • LinuxID10T
    replied
    Originally posted by Kano View Post
    @lethalwp

    Maybe try Kodi and vlc as well. Also vdpau would be interesting...
    His patch is just for mplayer to get it to recognize that it is being accelerated. It doesn't work on Kodi or VLC as of right now. The only player which works that I've tried is Windows Media Player, and that definitely doesn't run on Linux. Oddly enough, VLC on Windows will not accelerate decode with DXVA2 either.

    Leave a comment:


  • Kano
    replied
    @lethalwp

    Maybe try Kodi and vlc as well. Also vdpau would be interesting...

    Leave a comment:


  • pal666
    replied
    Originally posted by Evil Penguin View Post
    Would it then just make more sense to support the RADV driver?
    if you will be happier by adding zero developers to radv, then sure, let them add zero developers to radv

    Leave a comment:


  • Evil Penguin
    replied
    Originally posted by bridgman View Post

    Right... we knew at the start that any IP/Legal review would fail dramatically (and it did)... the work involved rewriting big chunks of the driver, and the driver itself is already much larger because it shares code across multiple OSes and multiple APIs.
    Would it then just make more sense to support the RADV driver?
    It seems to be off to a really good start.
    Sigh, pesky legal BS...

    Leave a comment:


  • Mystro256
    replied
    Originally posted by bridgman View Post

    Right... we knew at the start that any IP/Legal review would fail dramatically (and it did)... the work involved rewriting big chunks of the driver, and the driver itself is already much larger because it shares code across multiple OSes and multiple APIs.
    Does this mean the release is just stalled but is still coming? or do you have no idea/not allowed to say?

    Leave a comment:


  • Mystro256
    replied
    Originally posted by nadro View Post
    Those results look really nice! Great work! Thanks Michael for this benchmar.

    BTW. I think that you should run benchmarks in fullscreen mode, because in windowed/borderless mode compositor affects performance.
    Straight from the article:

    Originally posted by phoronix View Post
    When trying Dota 2 with fullscreen mode at various resolutions, the screen basically appeared locked and wouldn't update past the loading screen. But when alt-tabbing out of the game, a few new frames of the game's demo would proceed to appear... Alt-tabbing again, a few more frames. Or if leaving the game minimized so it would be off-screen, the demo would complete but would get just a few frames per second.

    I tried enabling/disabling the Steam overlay, switching between the AMDGPU and modesetting DDX drivers, switching from Compiz/Unity to Xfce with/without compositing, and other steps to try to figure out why the screen wouldn't update in the full-screen mode. But the easiest approach for now was just running Dota 2 in windowed mode. When in windowed mode, there were no issues.

    Leave a comment:


  • bridgman
    replied
    Originally posted by pal666 View Post
    it's not just legal review. somebody has to turn windows vuklan driver to opensourceable form. they have no resources for that, so do not expect they will magically find resources to maintain another driver
    Right... we knew at the start that any IP/Legal review would fail dramatically (and it did)... the work involved rewriting big chunks of the driver, and the driver itself is already much larger because it shares code across multiple OSes and multiple APIs.

    Originally posted by nadro View Post
    BTW. I think that you should run benchmarks in fullscreen mode, because in windowed/borderless mode compositor affects performance.
    In the article Michael said that the driver wasn't working in fullscreen, so he had to run in windowed mode.
    Last edited by bridgman; 30 August 2016, 02:22 PM.

    Leave a comment:


  • nadro
    replied
    Those results look really nice! Great work! Thanks Michael for this benchmar.

    BTW. I think that you should run benchmarks in fullscreen mode, because in windowed/borderless mode compositor affects performance.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by grigi View Post
    Wow. This is impressive. Well done David & Bas!
    Do you have plans to backport it to CI and SI?
    Well if the GCN 1.0 AMDGPU support lands on 4.9, it should be mostly doable on all GCN able hardware except when you need hardware specific fixes that could take more time

    Leave a comment:

Working...
X