RadeonSI OpenGL vs. RADV Vulkan Performance For Mad Max

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

  • mitch074
    replied
    Back to the thread's original subject, I bought the game (straight from Feral) and ran the PTS on it (2560x1440, Very High). Results show quite a lead on RADV compated with radeonsi - more so than Mickael's article says, I've got more than 50% better performance in Vulkan mode. Now, main differences are:
    - I'm using a much more recent Padoka build than Mickael did: improvements may have landed these past few days
    - my CPU is weaker: 4.2 GHz Haswell i5 doesn't pack as much punch as a 4.5 GHz i7, exacerbating Vulkan's advantages on CPU-limited machines
    - I haven't run as many tests: 1 in Vulkan, 2 in OGL (just to make sure the shader cache not being ready didn't skew the results).

    Results here: http://openbenchmarking.org/result/1704017-TA-MITCH074449

    As for the game itself, the only gripe I have with it for now is that maximum settings don't have a preset: I had to push each setting to maximum to really enjoy the game. Note that even with the extra load, it plays very nice in Vulkan.

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post

    Written (by us) *for* other OSes (using information supplied by those OS vendors), not written *by* other parties. We have one shared code base that supports multiple APIs on multiple OSes, basically a dozen or so different usage scenarios from a single code base.

    Opening it up involves separating out Vulkan from the other APIs, and separating Linux from the other OSes. Not quite as bad as doing a spine transplant on a complex living organism but not simple either.
    As I said in a different thread, don't you think that's exactly what the problem is?

    Leave a comment:


  • ossuser
    replied
    Originally posted by bridgman View Post

    Written (by us) *for* other OSes (using information supplied by those OS vendors), not written *by* other parties. We have one shared code base that supports multiple APIs on multiple OSes, basically a dozen or so different usage scenarios from a single code base.

    Opening it up involves separating out Vulkan from the other APIs, and separating Linux from the other OSes. Not quite as bad as doing a spine transplant on a complex living organism but not simple either.
    I get the feeling that part of the problem is reorganising the code tree.
    So the opensource part can be more easlily extracted.

    Would that be a correct assumption ?

    Leave a comment:


  • bridgman
    replied
    Originally posted by ossuser View Post
    So, if I understand right, if the code parts written by Microsoft/Sony are removed there will be an AMD open source Vulkan driver ?
    Written (by us) *for* other OSes (using information supplied by those OS vendors), not written *by* other parties. We have one shared code base that supports multiple APIs on multiple OSes, basically a dozen or so different usage scenarios from a single code base.

    Opening it up involves separating out Vulkan from the other APIs, and separating Linux from the other OSes. Not quite as bad as doing a spine transplant on a complex living organism but not simple either.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by bridgman View Post

    Yeah, you guys are going to have fun writing snarky comments if radv catches up with features & performance before our driver gets open sourced, but...

    (a) if we simply stopped work on it the criticism would probably be even worse ("wah wah, AMD lied and never intended to open source the driver, it's a good thing Dave worked on radv or we would have all been screwed by AMD"), and...

    (b) radv doesn't give us what our Vulkan driver does, which is a direct path for leveraging closed-source development work into the all-open stack.
    Making snarky comments is fun, though.

    Anyway, I am just growing increasingly worried about the AMD Vulkan driver. I hope you don't think that making it open source is a magical fix for everything and that's all that needs to be done to make it successful.

    The radeonsi drivers are a great improvement over the old fglrx stack, but just being OSS is not what put it in the position it's at today. You need to build a community around the project. You need it to be easy to install and run everywhere. It needs to be relatively bugfree and stable. You need all the other stuff the Mesa project has provided for radeonsi, and I'm not convinced AMD really gets that. You need all that PLUS a good reason for people to switch away from the current driver - which for the moment would be performance, but who knows how long/if that will last.

    If you just throw the code over the wall and say it's OSS, and think that's going to replace radv I think you're going to be disappointed.

    Really hope I'm just being pessimistic here, but that's where I'm at right now re: AMD's vulkan driver.

    Anyway, I lasted a whole year with no driver before I started making snarky comments, and if you ever thought people's patience would last more than a year you were very wrong. 1 year was right when people started getting antsy/snarky about the missing r9 285 driver support too. I know you'll never do it, but you'd do yourself a big favor to just throw out a rough timeline. "We're hoping for Q2 2018 launch, but no promises" would at least cause people to give you another 6-9 months before the questions start up again.
    Last edited by smitty3268; 31 March 2017, 10:16 PM.

    Leave a comment:


  • ossuser
    replied
    Originally posted by bridgman View Post
    Pretty much all third party IP from the non-Linux OSes the code also supports.
    ...
    So, if I understand right, if the code parts written by Microsoft/Sony are removed there will be an AMD open source Vulkan driver ?

    Leave a comment:


  • Mystro256
    replied
    Originally posted by schmidtbag View Post
    Agreed. Some of the nouveau devs blow my mind sometimes. And as we both know, RADV made tremendous progress in a relatively short time. But I am not proposing that AMD keeps their drivers closed. Again, I want to stress that I do want these drivers open-sourced. However, AMD released them as closed for whatever upper-management reasoning they had. Perhaps they wanted to polish it themselves before they were flooded with commits elsewhere that may contradict other plans.
    If you're referring to Vulkan, AFAIK there are third party IP issues blocking the release of code; i.e. it would take time to remove unreleasable code and approve it before releasing things openly.

    Leave a comment:


  • oooverclocker
    replied
    The big problem of all this is that when you invest hours to implement a Vulkan feature in RADV and it would take ages to get on a level near the proprietary drivers, as soon as AMD open sources their driver all your efforts were useless when it's faster. And it's even good that way because that means everyone would quickly support only one driver. So for the open source development optimizing RadeonSI, reducing overhead etc. has the highest priority and I guess there will be enough optional features left to be implemented and things to be optimized for at least this year and parts of the year after until the commitments slow down.

    But this means on the other hand that RADV will evolve slowly, and it isn't even nearly feature complete so the process of optimization will take a lot of time. And when I read that perhaps it would be even faster than the closed source implementation when it's open sourced... from how it evolved in a whole year that sound like a very long time. Although such a low level API should usually be faster to implement than the old ones...
    It's still important to have another ace in the hole for the case that something goes wrong with the open sourcing process though.

    Using the proprietary Vulkan driver and OpenCL implementation with RadeonSI might be an option if you're able to do it and interested enough but as long as the transition process hasn't been finished it reduces the attractiveness of AMD GPUs for Linux users significantly. When Ubuntu 17.04 comes out I could finally say: "Take an AMD GPU so everything works immediately or will be implemented in a short time." Now the poor RADV performance crosses the line because Vulkan is becoming important. I would still recommend an AMD card because I believe it's the better choice but it is harder to justify. Because all options that are left to get the missing performance are equal to buying an Nvidia card instead and installing the proprietary drivers.

    I really hope the next months will prove my estimations wrong.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by duby229 View Post
    Exceptional individuals do in fact exist. What you just proposed is essentially the same thing as eliminating the environment in which exceptional individuals can flourish.I don't have to thank them for that. It's just plain wrong. Look at beigenet as a perfect example of how an open source project can effectively be the exact same thing as proprietary.
    Agreed. Some of the nouveau devs blow my mind sometimes. And as we both know, RADV made tremendous progress in a relatively short time. But I am not proposing that AMD keeps their drivers closed. Again, I want to stress that I do want these drivers open-sourced. However, AMD released them as closed for whatever upper-management reasoning they had. Perhaps they wanted to polish it themselves before they were flooded with commits elsewhere that may contradict other plans. Many people look at these closed drivers as though they will remain that way forever, and that they should be avoided simply by principle. It's fine if that's someone's personal opinion, but my opinion does not agree with that, and I also feel that AMD devs should not be ridiculed because of it (I'm not suggesting you are, I'm just generalizing).

    I'd much rather take something than nothing. I prefer functionality, performance, and compliance over available source code. Of course, there is absolutely nothing stating you can't have both. But sometimes you just have to take what you can get. Sometimes life isn't fair. We can tell Nvidia "f*** you!" because they have proved to make life more difficult for some Linux devs. But on the other hand, if they didn't provide those drivers and didn't change their involvement with nouveau, Nvidia GPUs just wouldn't be a viable option for Linux. We may not have ever seen the availability of Steam as a result.
    Last edited by schmidtbag; 31 March 2017, 05:11 PM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by duby229 View Post
    Is there such a thing as a flabbergasted smiley?
    I have never found a good one.

    My impression was that most of the developers working on Beignet were Intel employees - do you disagree ? Or am I missing something different ?

    Leave a comment:

Working...
X