RadeonSI OpenGL vs. RADV Vulkan Performance For Mad Max

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

  • bridgman
    replied
    Originally posted by duby229 View Post
    Fine, then let's take this very moment as an example then. How many games run on AMD's <snip> Vulkan driver today? How many of them were tested on AMD's <snip> Vulkan driver?
    All of them, and more importantly games which have not yet been announced as well. They can also do that on radv today but that was not possible back when the most important decisions were being made.

    I guess you typed "oss" in there a couple of times by accident, since open vs closed would not have been a factor for major game developers making decisions 6-12 months ago - or are you saying that game developers completely ignore NVidia ?.

    Originally posted by duby229 View Post
    That's not at all what I'm saying. I'm specifically talking about AMD's oss Vulkan. I never mentioned a single word about their dx12 driver.
    They *are* the same driver (along with other APIs and other platforms). If you keep ignoring this point it will continue to be easy to draw different conclusions, however those conclusions will also continue to be incorrect.

    Originally posted by duby229 View Post
    How does it matter? How does sharing code with windows which the driver will not support help it? Don't you think that sharing code with other linux drivers in a actually shared codebase is what actually matters?
    Yep, that's what I said about "turning the code sharing model around". The goal would be to share with other Linux drivers *and* with other platforms.

    Originally posted by duby229 View Post
    You didn't have a solid <snip> Vulkan driver a year ago, in fact you still don't.
    You accidentally typed "oss" in there again, when the open-ness would not have had any relevance back when major game studios were making API decisions for their Windows games. Maybe there is something wrong with your keyboard, a rogue macro or something ?

    Originally posted by duby229 View Post
    No, what I was saying was, why share a codebase for a platform that will not be supported in the end? It's like sharing code for the sole purpose of never using it. (edit: it's more like you guys are trying to buy up all the green cars so that nobody else can buy a green car.)
    I don't understand what is so hard about this. It's the difference between maintaining one set of HW-specific code and maintaining two sets (or three actually, since we currently have to write new HW-specific code for Mesa GL as well with every new HW generation.

    Originally posted by duby229 View Post
    Duh! That is literally the only and entire point I've been trying to make. This proves you understood the point completely and simply chose to beat around the bush with nonsensical excuses.
    Then why did you keep saying "open source" if you meant "works with the upstream kernel driver" ? We could have saved a bunch of time and thread space if you had said "works with the upstream kernel driver" from the start. In the end I had to ignore your words and guess at what you meant.
    Last edited by bridgman; 02 April 2017, 01:46 PM.

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post

    Right. Long before Dave & Bas started working on it, radv was there to make sure game developers (who frequently didn't give a rat's rear end about open source) had a solid target for testing & making porting decisions.
    Fine, then let's take this very moment as an example then. How many games run on AMD's oss Vulkan driver today? How many of them were tested on AMD's oss Vulkan driver?
    The answer is plainly obvious.

    It's actually more like taking out API-dependent parts in a repeatable way. The OS-dependent parts were cleanly segregated from the start.

    Where the nitpicking comes in is if you say (for example) "oh DX12 is only on Windows so that's what I meant by OS-dependent".
    That's not at all what I'm saying. I'm specifically talking about AMD's oss Vulkan. I never mentioned a single word about their dx12 driver.


    The open source driver will not be multi-platform (obviously), but the internal code base it gets refreshed from will continue to be multi-platform, and it's the latter part that matter.
    How does it matter? How does sharing code with windows which the driver will not support help it? Don't you think that sharing code with other linux drivers in a actually shared codebase is what actually matters? The fact of the matter is that you're so called shared codebase will only ever be used by you and never really be shared with anything else. It will technically be open source, but it will effectively be proprietary. If DC is any indication.

    A driver that works with the upstream kernel would certainly have been the best idea from the start. Don't think anything else has been proven yet, and until we have gone through a cycle of adding new HW support to the open stack with the open source Vulkan driver in play it's too soon to draw any conclusions.

    Remember why the open source devs were interested in this - done properly, it offers the chance to turn the code sharing model around and make it easier to add new HW support to not just the open source Vulkan driver but to Mesa GL as well. We are trying to bring the open and closed code bases together more to reduce the amount of "developing stuff twice", first with the amdgpu initiative, then with ROC, and now with Vulkan.

    You can choose to believe that having a solid Vulkan driver a year ago was not a factor at all in terms of game developers deciding to use Vulkan rather than stay with OpenGL, but I think you would be at least slightly deluding yourself.
    You didn't have a solid oss Vulkan driver a year ago, in fact you still don't.

    That's like saying "a green car will be meaningless because it won't be green". Doesn't make sense. Can you try again with a different set of words ?
    No, what I was saying was, why share a codebase for a platform that will not be supported in the end? It's like sharing code for the sole purpose of never using it. (edit: it's more like you guys are trying to buy up all the green cars so that nobody else can buy a green car.)

    I still think you are getting upset about the wrong thing. What you are really trying to say AFAICS is that we should have had a Vulkan driver which worked with upstream kernels by now, and you would be absolutely right IMO... and correct in saying that radv is filling that gap.
    Duh! That is literally the only and entire point I've been trying to make. This proves you understood the point completely and simply chose to beat around the bush with nonsensical excuses.
    Last edited by duby229; 02 April 2017, 09:47 AM.

    Leave a comment:


  • Tomin
    replied
    Originally posted by suberimakuri View Post
    Good o.
    I think we should stop beating around the bush about AMD open sourcing their Vulkan. Bridgeman, you're not really helping here by keeping this topic alive.
    For whatever reason it didn't work out, oh well, move on. It doesn't really matter.
    We definitely don't need more banter on it on here.
    I think the issue is not that AMD can't/won't open up their Vulkan driver, but that it takes too long for these impatient people. It just won't happen overnight. Also, I'm saying this because someone brought it up earlier, DC efforts don't slow down Vulkan drivers, since kernel and user space developers generally don't overlap that much.

    Leave a comment:


  • suberimakuri
    replied
    Good o.
    I think we should stop beating around the bush about AMD open sourcing their Vulkan. Bridgeman, you're not really helping here by keeping this topic alive.
    For whatever reason it didn't work out, oh well, move on. It doesn't really matter.
    We definitely don't need more banter on it on here.

    AMD have done OpenCL with ROCm right? So integrate that into mainline (if not already?), it's a good contribution.
    RADV continues to mature and with Valve/RedHat/etc getting behind it, no problems.

    Leave a comment:


  • bridgman
    replied
    Originally posted by smitty3268 View Post
    Just out of curiosity, have you actually heard that from developers, or was it meant as a hypothetical?
    It was meant as sarcasm, in response to duby229's post which ignores passage of time and ends up implying that radv was what influenced developers to use Vulkan before anyone even knew it was being worked on.

    Maybe I need to add <sarcasm>...</sarcasm> tags.

    I'm saying it was important to have Vulkan drivers on Linux & Windows at the same time so that there would be justification for developers to think about Vulkan during initial implementation rather than just going with DX12.

    Originally posted by smitty3268 View Post
    Because everything I've heard is that game developers have focused their efforts on the Windows Vulkan drivers first (both AMD and NVidia), then port to Linux second, and the ones that have done so have focused on the NVidia drivers there. radv/anv then seem to be secondary targets there after the NVidia linux support is confirmed.

    Or maybe you are just talking about the windows drivers?

    Leave a comment:


  • smitty3268
    replied
    Originally posted by bridgman View Post

    Right. Long before Dave & Bas started working on it, radv was there to make sure game developers (who frequently didn't give a rat's rear end about open source) had a solid target for testing & making porting decisions.
    Just out of curiosity, have you actually heard that from developers, or was it meant as a hypothetical?

    Because everything I've heard is that game developers have focused their efforts on the Windows Vulkan drivers first (both AMD and NVidia), then port to Linux second, and the ones that have done so have focused on the NVidia drivers there. radv/anv then seem to be secondary targets there after the NVidia linux support is confirmed.

    Or maybe you are just talking about the windows drivers?
    Last edited by smitty3268; 01 April 2017, 11:25 PM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by duby229 View Post
    Except it hasn't been you supporting Vulkan linux games from the start, it's been radv.
    Right. Long before Dave & Bas started working on it, radv was there to make sure game developers (who frequently didn't give a rat's rear end about open source) had a solid target for testing & making porting decisions.

    Originally posted by duby229 View Post
    "That" what you said AMDs plan is. i.e. AMD is taking their proprietary Vulkan driver and redesigning out the OS dependent parts, then writing a Linux dependent part and open sourcing the result.
    It's actually more like taking out API-dependent parts in a repeatable way. The OS-dependent parts were cleanly segregated from the start.

    Where the nitpicking comes in is if you say (for example) "oh DX12 is only on Windows so that's what I meant by OS-dependent".

    Originally posted by duby229 View Post
    The end result is that the open source driver will not itself be multiplatform, even though you've repeatedly used that excuse.
    The open source driver will not be multi-platform (obviously), but the internal code base it gets refreshed from will continue to be multi-platform, and it's the latter part that matters.

    Originally posted by duby229 View Post
    EDIT: A separate community driver probably was the best idea from the start as radv is already proving.
    A driver that works with the upstream kernel would certainly have been the best idea from the start. Don't think anything else has been proven yet, and until we have gone through a cycle of adding new HW support to the open stack with the open source Vulkan driver in play it's too soon to draw any conclusions.

    Remember why the open source devs were interested in this - done properly, it offers the chance to turn the code sharing model around and make it easier to add new HW support to not just the open source Vulkan driver but to Mesa GL as well. We are trying to bring the open and closed code bases together more to reduce the amount of "developing stuff twice", first with the amdgpu initiative, then with ROC, and now with Vulkan.

    You can choose to believe that having a solid Vulkan driver a year ago was not a factor at all in terms of game developers deciding to use Vulkan rather than stay with OpenGL, but I think you would be at least slightly deluding yourself.

    Originally posted by duby229 View Post
    A shared codebase with windows is proving meaningless in that it won't be usable on windows.
    That's like saying "a green car will be meaningless because it won't be green". Doesn't make sense. Can you try again with a different set of words ?

    Originally posted by duby229 View Post
    And it's costing AMD's linux support dearly in that radv is here now and AMD's driver is not and meanwhile radv is going it alone.
    I still think you are getting upset about the wrong thing. What you are really trying to say AFAICS is that we should have had a Vulkan driver which worked with upstream kernels by now, and you would be absolutely right IMO... and correct in saying that radv is filling that gap.
    Last edited by bridgman; 01 April 2017, 10:43 PM.

    Leave a comment:


  • ossuser
    replied
    bridgman

    Thanks for telling us what the choices were, it makes sense to me, and I hope to others.

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post

    Yes and no. The developers were aware of a possible requirement to open source the Vulkan driver when they were writing it, so wherever a design decision could be made that would simplify future open sourcing without significantly delaying the project those decisions were made.

    On the other hand design choices which would have simplified open sourcing but resulted in the initial Vulkan driver being significantly delayed (or significantly slower), eg writing separate drivers for Vulkan/Linux, were generally not taken.

    The only practical option if we wanted to avoid writing a difficult-to-open-source driver would have been to launch Vulkan on Windows only then write a separate Linux Vulkan driver later which could have been more easily open sourced. We didn't think that made sense because we wanted to support game developers on Linux Vulkan from the start.



    What do you mean by "that", ie what are you asking ?
    Except it hasn't been you supporting Vulkan linux games from the start, it's been radv.

    "That" what you said AMDs plan is. i.e. AMD is taking their proprietary Vulkan driver and redesigning out the OS dependent parts, then writing a Linux dependent part and open sourcing the result. The end result is that the open source driver will not itself be multiplatform, even though you've repeatedly used that excuse.

    EDIT: A separate community driver probably was the best idea from the start as radv is already proving. A shared codebase with windows is proving meaningless in that it won't be usable on windows. And it's costing AMD's linux support dearly in that radv is here now and AMD's driver is not and meanwhile radv is going it alone.
    Last edited by duby229; 01 April 2017, 05:09 PM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by ossuser View Post
    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 ?
    Yes and no. The developers were aware of a possible requirement to open source the Vulkan driver when they were writing it, so wherever a design decision could be made that would simplify future open sourcing without significantly delaying the project those decisions were made.

    On the other hand design choices which would have simplified open sourcing but resulted in the initial Vulkan driver being significantly delayed (or significantly slower), eg writing separate drivers for Vulkan/Linux, were generally not taken.

    The only practical option if we wanted to avoid writing a difficult-to-open-source driver would have been to launch Vulkan on Windows only then write a separate Linux Vulkan driver later which could have been more easily open sourced. We didn't think that made sense because we wanted to support game developers on Linux Vulkan from the start.

    Originally posted by duby229 View Post
    As I said in a different thread, don't you think that's exactly what the problem is?
    What do you mean by "that", ie what are you asking ?
    Last edited by bridgman; 01 April 2017, 03:55 PM.

    Leave a comment:

Working...
X