Announcement

Collapse
No announcement yet.

AMDVLK Radeon Vulkan Driver Updated With A Slew Of Additions

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

  • airlied
    replied
    It's pretty much impossible for non amd Devs to contribute to vlk more than bug reports

    Leave a comment:


  • L_A_G
    replied
    Originally posted by gurv View Post
    ...
    Your argument basically just boils down to complaining about how it's sharing code with the Windows driver with FUD comparable to what Microsoft was putting out in the late 90s to early 2000s and a whole bunch of misinformation on how it's supposedly not open because third party developers have mostly contributed to RADV, a third party driver.

    It seems like basic pragmatism is also a completely alien concept to you with the way you act like any and all closed source software is somehow unacceptable when the reality if you believe something that doesn't mean any significant number of people are going to agree with you and the simple fact that something like 99% of people simply don't give a damn about open or closed source.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by mphuZ View Post

    1. It is open. AMD promised to improve communication with developers. Wait December.
    That's just not true. All development is done behind close doors and just dumped out into the open every 2 weeks. That's not an open community project as the original poster said. It's open source code, at most. There's a big difference. I don't know what's coming in December. Maybe that will change things, but we should wait and see rather than just assuming anything.

    2. And this is great! One code for different platforms (perhaps not only Windows and Linux in the future). Developers must be complete idiots to not take advantage of this opportunity.
    It has pros and cons. I don't think devs are complete idiots, and for the moment they don't seem to be caring much about amdvlk. That can obviously change. I think Valve is probably the key to determining which driver devs rally behind, and it sounds like they've had some pretty awful interactions with AMD over the last few years trying to get their linux drivers up to scratch, so that's probably why they seem to focusing everything on the open source radv driver they can actually fix up and add to whenever they need to for some game, rather than relying so much on AMD to do things for them.

    3. AMDVLK is built on the same LLVM. They said that in the future they would try to completely switch to it.
    AMDVLK-PRO has a proprietary compiler which gives it better performance. AMDVLK-Open uses LLVM, and as a result tends to be slower than radv in most games. Yes, it sounds like AMD is trying to improve LLVM to get it on par with their proprietary compiler, but radv should also be able to take advantage of those same performance boosts, and this is all currently theoretical and not done yet. We'll see what things look like in a year or two. I certainly wouldn't count on it being done before then given history.

    L_A_G is right. RADV exists because it is needed for Valve experiments. Valve and AMD should as soon as possible to establish development AMDVLK, which develops very quickly, otherwise due to the fragmentation of the drivers on Linux again the problems begin.
    I don't think there is much fragmentation, actually. Pretty much everyone is fully backing radv at the moment, other than AMD of course. I think most game devs at least will follow whatever Valve recommends, as they are the ones driving most of the development to begin with. If they ever switch to amdvlk, that's when the fragmentation will occur, as some distros will follow suit while others will resist switching.
    Last edited by smitty3268; 20 October 2018, 11:17 PM.

    Leave a comment:


  • mphuZ
    replied
    Originally posted by gurv View Post

    - the most serious one: it's not an open community.

    - it's shared with Windows.

    - without the PROPRIETARY compiler, it's inferior to RADV.
    1. It is open. AMD promised to improve communication with developers. Wait December.

    2. And this is great! One code for different platforms (perhaps not only Windows and Linux in the future). Developers must be complete idiots to not take advantage of this opportunity.

    3. AMDVLK is built on the same LLVM. They said that in the future they would try to completely switch to it.

    L_A_G is right. RADV exists because it is needed for Valve experiments. Valve and AMD should as soon as possible to establish development AMDVLK, which develops very quickly, otherwise due to the fragmentation of the drivers on Linux again the problems begin.

    Leave a comment:


  • airlied
    replied
    Being in mesa gives a big advantage to radv, since distros know how to consume llvm and mesa already, the overhead of maintaining radv is negligible if you already ship radeonsi and anv. Packaging amdvlk would cause a lot of pain for most distros, it bundles an llvm fork for example which most distros won't have resources to maintain. I think radv has probably saved its development cost in saved distro nightmares :-)

    Leave a comment:


  • gurv
    replied
    Originally posted by L_A_G View Post
    Personally I've always considered RADV to be a temporary measure at best and an unnecessary duplication of efforts for the most part. We knew that AMDVLK was going to be open sourced and start receiving regular commits since RADV development started, meaning that it's development only made sense for as long as we were still waiting on AMDVLK being made open source. After that happened it's really just been an unnecessary duplication of effort driven by the developers' personal pride and paranoia of companies who haven't been dedicated to open source since the beginning.
    Wow, I could not disagree more!
    As an AMD customer I hope they ditch AMDVLK in favour of RADV.

    AMDVLK has three serious flaws that won't be fixed anytime soon if ever:
    - the most serious one: it's not an open community.
    AMD controls what gets in based on THEIR very own priority.
    The completely open nature of RADV is what enables so many contributions from the likes of Valve and Feral.
    - it's shared with Windows.
    Meaning features that benefit Windows integration will ALLWAYS have the priority over Linux ones if they conflict.
    I'd rather see the sharing be between hardware vendor on Linux than same vendor but cross-os.
    - without the PROPRIETARY compiler, it's inferior to RADV.
    And if it's proprietary, then why not buy NVidia in the first place.

    Personally, I hope Intel comes with some really good discrete GPU in the near future.
    That way, I'll always have the option of a fully open-source, fully vendor supported graphics driver.

    Leave a comment:


  • L_A_G
    replied
    Originally posted by Leopard View Post
    ...
    The fact that people chose to use RADV, particularly when it was the only alternative for developers who didn't want to work with closed source drivers, doesn't mean that they couldn't have done the same work with with AMDGPU-PRO or that active development of RADV ending immediately as it became unnecessary would have been the end of the world for them. Feedback from this dev you're talking about would probably have been valuable and helped make AMDVLK better.

    Seriously thou, nobody actually had to use RADV. Everybody who did, chose to do so.

    Originally posted by ms178 View Post
    ...
    AMD definitely should have gotten AMDVLK open sourced sooner, but I suspect the pretty significant refactoring they had to go trough with for DC/DAL probably threw their original plans out of whack.

    As for writing new drivers, doubt they're going to be doing anything even close to as extensive as when they moved to AMDGPU as drivers contain quite a few abstraction layers that aren't hardware dependent. The upshot of this is that more probably than not they're just going to support the new architecture that's supposed to come after Navi under AMDGPU/AMDVLK. After all, limiting AMDGPU to GCN-based hardware and not bothering to add official support for the really early GCN hardware had more to with not wanting to clutter the codebase to a brand new driver with loads of unique branches for legacy hardware.
    Last edited by L_A_G; 19 October 2018, 10:17 AM.

    Leave a comment:


  • wsxy162
    replied
    Originally posted by tomtomme View Post

    there is not that much duplication.
    As AMDVLK is essentially their windows driver, it can't be dropped, as you said yourself.
    RADV is where currently most game-specific tuning is happening by valve and other developers.
    A merge of the AMDVLK-PRO shader compiler would be nice though, as that is superior atm but NOT open source. So AMDVLK is not completely open source yet.
    RADV could only be dropped if all game/perf tuning would be transported to AMDVLK and if the shader compiler would go open source and then this thing would need to be accepted by the wider community as supperior.
    AMDVLK shares the same code with their Windwos driver, isn't this mean most tunings on Windows also work on AMDVLK.

    Leave a comment:


  • Leopard
    replied
    Originally posted by L_A_G View Post

    As I said, it was at best a temporary measure before AMDVLK was open sourced and now that it's been open sourced it's just an unnecessary duplication of effort. RADV could have been a much less ambitious effort and discontinued the day AMDVLK came out and we'd still have DXVK so there's really no need to make clearly false statements like that.



    I think you're mixing up developer effort to support something with the actual quality of that thing. Application developers were obviously going to focus on RADV before AMDVLK came out and when it's still got more users and what's installed by default on most distros they're obviously going to continue to do so even if all they're doing is perpetuating an unnecessary duplication of effort.



    The development of a second driver with the same goals is a duplication of effort no matter how you try to look at it. Literally the whole RADV effort is an unnecessary duplication of functionality while game and engine optimizations for it will just a plain waste of effort if sanity prevails and RADV is discontinued.
    Sorry but again ; wut?

    Do you know the hardware of DXVK dev? Also when he started to invest DXVK?

    Let me tell you ; he has RX480 and when he started DXVK ( which is months ago before he showed off Nier ) there was only RADV. He used it , not AMDGPU-PRO which at that time GPU-Pro was struggling to run even native Vulkan titles.

    Leave a comment:


  • ms178
    replied
    Originally posted by L_A_G View Post

    Personally I've always considered RADV to be a temporary measure at best and an unnecessary duplication of efforts for the most part. We knew that AMDVLK was going to be open sourced and start receiving regular commits since RADV development started, meaning that it's development only made sense for as long as we were still waiting on AMDVLK being made open source. After that happened it's really just been an unnecessary duplication of effort driven by the developers' personal pride and paranoia of companies who haven't been dedicated to open source since the beginning.
    Aye, I agree that this turned out to be rather unfortunate as it took AMD simply way too long to open up AMDVLK to the public. In the meantime RADV earned itself enough mindshare in the community and recieved quite a lot of attention that it is harder now to have one unified AMD Vulkan driver effort. Let's wait and see what a future new graphics architecture might bring to the table where they might need to build a new driver from scratch again.

    Leave a comment:

Working...
X