Announcement

Collapse
No announcement yet.

AMD's Vulkan Driver Will Only Work With The AMDGPU Kernel Driver

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

  • duby229
    replied
    Originally posted by bridgman View Post

    I do understand the source of your confusion... did try to explain it a couple of times but that might have been in other threads. Graham is on the userspace side, and the userspace components are coded against the libdrm interface libraries. Our Vulkan implementation is coded against the libdrm-amdgpu interface, Graham doesn't want to change the userspace code to use the radeon interfaces, so "only the libdrm-amdgpu interface will support Vulkan", and AFAIK we all agree with that.

    Now, what happens under the libdrm-amdgpu interface is a different story. Adding SI support to the amdgpu kernel driver is the most obvious solution, but it's messy for a number of reasons including the fact that SI is basically NI with an GCN shader core, ie has little or no commonality with CI and higher. Adding radeon kernel driver support to libdrm-amdgpu is messy in its own way, but gives us quick access to an already-upstream, already-enabled and already-tested driver stack.

    From a userspace developer's point of view SI and CI are very similar, so using the amdgpu kernel driver seems like the obvious choice. From a kernel developer's point of view, however, SI and CI are much less similar and the choice is much less obvious. The only real argument in favour of amdgpu (albeit an important one) is that the long-term support costs will probably be lower with amdgpu. Downside of going with amdgpu immediately is the dependency on out-of-tree builds and the fact that there won't be much test coverage yet on pre-VI code paths.

    We have been working on the amdgpu path for quite a while now so we have a pretty good handle on pros & cons. I don't know where you got the idea that we only started looking at it after Michael's article, but that is simply not true.
    It's not at all that I believe AMD hadn't looked at it. It's that AMD doesn't say anything about anything until it explodes in their face. You guys really need to release more press. A lot more press. And secondly you guys need some sort of "red alert" system. When information needs to be dispersed, like it has been the last few days, a detailed press release needs to be written and then plastered all over the internet.

    I guess it must be easy to think that because you know something everybody else must know the same thing too. But that just isn't the case. There may be psychics, but I've never met a real one.

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post

    End of page, and moderated again. Interesting pattern.

    So my response to your summary of your moderated post was moderated too. Yay.

    BTW you said the following earlier...



    ... when you talk about our "chosen path" what do you think that is ?
    You've explained a little better since I wrote that edit. At that time I thought AMD was going to keep the status quo with amdgpu unofficially supporting GCN 1.1 and officially supporting GCN 1.2+. That would leave GCN 1.0 users in the cold and GCN 1.1 users with no out of box support. It's politically correct because that would be in accordance with the Linux kernel policy of one driver per device in kernel.

    Also at that time it was After I read Mr, Writers blogs and twitter posts about the topic where he said that radeon would not get support unless a community member or team stepped up to do it. And it was before you mentioned anything at all about libdrm-amdgpu, so I hadn't considered that an option. As radeon was not an option at that time yet, the only technically correct solution available would be to remove GCN 1.0 and 1,1 from radeon and add that support to amdgpu and then get that upstreamed.

    But at this point, you've made it clear that radeon will get libdrm-amdgpu support, which effectively means Vulkan support. That is a second viable technically correct solution, I wouldn't argue against.

    Leave a comment:


  • bridgman
    replied
    This is where having Michael's home phone number would be handy. Wouldn't even need to talk to him, just let it ring a couple of times and hang up.

    "As long as I'm awake I might as well check the moderation queue while the coffee is brewing"

    Leave a comment:


  • bridgman
    replied
    Replies below are on the next page. Click here to go to the next page.
    End of page, and moderated again. Interesting pattern.

    So my response to your summary of your moderated post was moderated too. Yay.

    BTW you said the following earlier...

    EDIT: The exists a politically correct method and a different technically correct method. The chosen path is the politically correct one, but which is definitely not technically correct.
    ... when you talk about our "chosen path" what do you think that is ?
    Last edited by bridgman; 24 January 2016, 09:39 AM.

    Leave a comment:


  • bridgman
    replied
    Originally posted by duby229 View Post
    I'm not arguing against the proper interface on radeon. However an AMD employee clearly stated that only amdgpu would support Vulkan. You must clearly see the source of my confusion.
    I do understand the source of your confusion... did try to explain it a couple of times but that might have been in other threads. Graham is on the userspace side, and the userspace components are coded against the libdrm interface libraries. Our Vulkan implementation is coded against the libdrm-amdgpu interface, Graham doesn't want to change the userspace code to use the radeon interfaces, so "only the libdrm-amdgpu interface will support Vulkan", and AFAIK we all agree with that.

    Now, what happens under the libdrm-amdgpu interface is a different story. Adding SI support to the amdgpu kernel driver is the most obvious solution, but it's messy for a number of reasons including the fact that SI is basically NI with an GCN shader core, ie has little or no commonality with CI and higher. Adding radeon kernel driver support to libdrm-amdgpu is messy in its own way, but gives us quick access to an already-upstream, already-enabled and already-tested driver stack.

    From a userspace developer's point of view SI and CI are very similar, so using the amdgpu kernel driver seems like the obvious choice. From a kernel developer's point of view, however, SI and CI are much less similar and the choice is much less obvious. The only real argument in favour of amdgpu (albeit an important one) is that the long-term support costs will probably be lower with amdgpu. Downside of going with amdgpu immediately is the dependency on out-of-tree builds and the fact that there won't be much test coverage yet on pre-VI code paths.

    We have been working on the amdgpu path for quite a while now so we have a pretty good handle on pros & cons. I don't know where you got the idea that we only started looking at it after Michael's article, but that is simply not true.
    Last edited by bridgman; 24 January 2016, 03:44 PM.

    Leave a comment:


  • duby229
    replied
    I'd much rather have an edit timeout than a moderation que. I know the new system formats the pages better, but dang...

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post

    You are still getting mad about future events though, and you are arguing passionately *against* approaches (like libdrm-amdgpu over radeon) that could help to give you what you are expecting (quick solution, upstream and enabled by default from the start), and getting angry with me for even discussing them.

    BTW are you talking specifically about SI or CI ?
    I'm sorry, I had quite a long post that got eaten by the forum. It may still show up.

    I'm not arguing against the proper interface on radeon. However an AMD employee clearly stated that only amdgpu would support Vulkan. You must clearly see the source of my confusion.

    Leave a comment:


  • duby229
    replied
    Originally posted by duby229 View Post
    Well, after reading this thread, I'm personally convinced that if AMD doesn't support Vulkan on -all- GCN cards, there will be an explosive backfire. And I think bridgmans excuse of blaming it on linus is asinine.

    EDIT: The exists a politically correct method and a different technically correct method. The chosen path is the politically correct one, but which is definitely not technically correct.

    EDIT: So we've got multiple AMD employees saying multiple incompatible things. One says Vulkan will only work on amdgpu, another says only GCN 1.2 and up will be supported on amdgpu (and blames that on linus torvalds), another says amdgpu will support older GCN revisions out of tree eventually.....

    Come on AMD. You can do better. (Fuck the out of tree bullshit. Fuck the blame game on linus bullshit.) Put -ALL- GCN support in amdgpu and get it upstreamed. If that requires removing GCN support from radeon, then that is exactly what it requires.
    Maybe the swearing was uncalled for, ok sorry. But the points still hold.

    --IMO--

    Option 1) Get all GCN generations supported on amdgpu and then get that support upstreamed.
    Option 2) I don't know how it would be done, but the radeon supported GCN generations can have support implemented and then get that support upstreamed.

    I think you are suggesting that Option 2) is viable. However I believe Writer said that wouldn't happen unless someone or group from the community stepped up to do that. If I'm wrong and that's not what he meant, then Option 2) may well be viable. But then that still leaves another AMD employee that clearly said that only amdpgu would support Vulkan. So you can clearly see why I might have been confused.

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post

    You are still getting mad about future events though, and you are arguing passionately *against* approaches (like libdrm-amdgpu over radeon) that could help to give you what you are expecting (quick solution, upstream and enabled by default from the start), and getting angry with me for even discussing them.

    BTW are you talking specifically about SI or CI ?
    Exactly full circle back to the beginning. The more I look the more fractals I see. I might as well just quote my first post in this thread, because it would accomplish the same thing.

    Leave a comment:


  • bridgman
    replied
    Originally posted by duby229 View Post
    Nothing I can do about the forum. Although I am right, I apologize for losing my temper. It's just one misstep after the next with AMD. and this one hits close to home because I bought a GCN card and recommended multiple because I knew it would get launch day support. Or at least I thought I knew.
    You are still getting mad about future events though, and you are arguing passionately *against* approaches (like libdrm-amdgpu over radeon) that could help to give you what you are expecting (quick solution, upstream and enabled by default from the start), and getting angry with me for even discussing them.

    BTW are you talking specifically about SI or CI ?
    Last edited by bridgman; 23 January 2016, 07:52 PM.

    Leave a comment:

Working...
X