RadeonSI OpenGL vs. RADV Vulkan Performance For Mad Max

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

  • haagch
    replied
    Originally posted by agd5f View Post
    Moreover, the only reason the vulkan driver is bundled with the pro driver is because the extra kernel bits needed for it can't go upstream yet because the only user is closed source. Once it gets open sourced, all those changes can land upstream.
    Which bits exactly are that? Everything I tried so far with the closed source Vulkan driver works on the mainline kernel. Only libdrm with various patches from the mailing list is needed... I only noticed that performance isn't as good as I expected e.g. in The Talos Principle. Are there missing kernel bits that would make it perform better?

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post

    Isn't Beignet more of an example of what can happen when a big company puts resources into a project ?
    Is there such a thing as a flabbergasted smiley?

    Leave a comment:


  • bridgman
    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.
    Isn't Beignet more of an example of what can happen when a big company puts resources into a project ?

    Leave a comment:


  • bridgman
    replied
    Originally posted by ossuser View Post
    AMD is supposed to have the superior architecture, especially when doing Vulkan stuff.
    So, I'm wondering, what are those "things you can't expose publicly" exactly, AMD hardware details or 3rd party code/IP ?
    Pretty much all third party IP from the non-Linux OSes the code also supports. I don't think hardware details have been an issue yet.

    Originally posted by ossuser View Post
    Also, what's the planning for this AMD opensource Vulkan driver ?
    Will we see it when VEGA is released ?
    Unfortunately it has to be one of those "you'll see it when it's safe to release".

    Removing sensitive third party information is not something that can be done in public, for obvious reasons.

    Leave a comment:


  • duby229
    replied
    Originally posted by schmidtbag View Post
    Yes, there will always be someone who complains, but your overall statement is a bit too generalized. For starters, Nvidia fanboys also have to deal with closed drivers, so their cheers would be a bit hypocritical. Meanwhile, Intel doesn't exactly have any GPU hardware worth bragging about.
    I, for one, am happy that there is an AMD-supplied Vulkan driver that, to my knowledge, is fully compliant and stable. Sure, I think we'd all be a lot happier if it was open-sourced a long time ago, but at least it was supplied early on. For me personally, I'd rather it leave experimental status on GCN 1.0-1.1 GPUs before it gets open-sourced.
    So this brings up a fairly complicated topic. Two of them in fact. And they're not particularly related. The first thing is that we are both pretty familiar with other members of this forum. We've come to be familiar with many other peoples opinions on matters. It's not that difficult for you or I to recognize an AMD fan over an nVidia fan. Maybe that's not our place, but we are humans and we have the ability to recognize patterns among people.

    The second thing is that it really isn't so much GCN1.0 and GCN1.1 support that is experimental. Rather it's that the earliest GCN parts used an ASIC that was very similar to the ASIC used by the VLIW4 parts. To support those ASICs required initially porting support for them from r600. Now that support needs to be duplicated further into amdgpu. At least that is how I come to understand the difficulty.

    A community is only as good as its members/contributors. Take a hard look at all the open-source GPU drivers out there that don't have a corporation backing them. Most of them struggling to keep up (especially on ARM), to put it lightly. Open-sourcing drivers doesn't magically make them better. It will not guarantee somebody will step up and make something better. GPUs are complex beasts, and most people who volunteer for the good of the community just don't have the knowledge, time, or skills to handle modern GPUs.

    I'd like to clarify - I see no reason not to open-source these drivers, but as long as these drivers work as advertised and will be open-sourced, just be patient and thankful you have them at all.
    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.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by duby229 View Post
    On a) That's just the nature of marketing. You'll always have someone complaining. Right now it's AMD's fanboys complaining and their competitors fanboys cheering them on.
    Yes, there will always be someone who complains, but your overall statement is a bit too generalized. For starters, Nvidia fanboys also have to deal with closed drivers, so their cheers would be a bit hypocritical. Meanwhile, Intel doesn't exactly have any GPU hardware worth bragging about.
    I, for one, am happy that there is an AMD-supplied Vulkan driver that, to my knowledge, is fully compliant and stable. Sure, I think we'd all be a lot happier if it was open-sourced a long time ago, but at least it was supplied early on. For me personally, I'd rather it leave experimental status on GCN 1.0-1.1 GPUs before it gets open-sourced.
    On b) No of course not, radv gives you something waaaay better than that. A community supported driver with open source code sharing within a common framework.
    A community is only as good as its members/contributors. Take a hard look at all the open-source GPU drivers out there that don't have a corporation backing them. Most of them struggling to keep up (especially on ARM), to put it lightly. Open-sourcing drivers doesn't magically make them better. It will not guarantee somebody will step up and make something better. GPUs are complex beasts, and most people who volunteer for the good of the community just don't have the knowledge, time, or skills to handle modern GPUs.

    My point is, if AMD open-sourced these Vulkan drivers from the very beginning, we likely wouldn't have seen much (if anything) change from 3rd party devs. On the other hand... Arlie could've devoted his time to something else (not that he couldn't have done that anyway *sigh*).

    I'd like to clarify - I see no reason not to open-source these drivers and I do absolutely see it as a good thing that in the long term will be helpful. But, as long as these drivers work as advertised and will be open-sourced, just be patient and thankful you have them at all.
    Last edited by schmidtbag; 31 March 2017, 03:33 PM.

    Leave a comment:


  • ernstp
    replied
    bridgman What _are_ the kernel dependencies of the closed source Vulkan driver?
    Are they in amd-staging-4.9 ?
    edit: or perhaps that's more of a question for agd5f
    Last edited by ernstp; 31 March 2017, 03:29 PM.

    Leave a comment:


  • duby229
    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.
    On a) That's just the nature of marketing. You'll always have someone complaining. Right now it's AMD's fanboys complaining and their competitors fanboys cheering them on. On b) No of course not, radv gives you something waaaay better than that. A community supported driver with open source code sharing within a common framework.

    Leave a comment:


  • oooverclocker
    replied
    I think there shouldn't be unjust criticism but it would make sense to set the priority quite high when the work on Vega is done and DC is in the Kernel. With Dota 2 and The Talos Principle it wasn't really necessary to have well performing Vulkan drivers. But with the Dolphin Emulator and now Mad Max it looks like one could really profit a lot and these images of an 980 Ti running much faster vs. a Fury not running faster also arrive in articles of gaming magazines not having that much to do with Linux. And they don't know what RADV is and mention that AMD and Intel GPUs aren't supported anyway.

    So to be very honest, from the perspective of AMD there shouldn't be too many more games showing AMD cards being unable to benefit from the Vulkan implementation on Linux while the Nvidia driver works well.
    In the end I don't know the agenda and were it fits in... but I hope it will get a higher priority with a growing number of Vulkan titles.

    Leave a comment:


  • bridgman
    replied
    Originally posted by smitty3268 View Post
    But how many people using OEM pre-loads are using a Vulkan driver?
    The intersection of that Venn diagram seems small.
    Agreed (although I'm sure someone somewhere is gaming on a big-iron RHEL server as we speak), but remember that initially we were also pushing the -PRO driver out as a stopgap solution for consumer users, in order to get (a) fast OpenGL before the performance work we were doing on Mesa GL showed results and (b) Vulkan before the open sourcing effort showed results.

    Leave a comment:

Working...
X