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

[bridgman]

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.

[bridgman]

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 ?

[bridgman]

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"

[duby229]

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.

[duby229]

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.

[bridgman]

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+.

Ahh, now I understand. Sorry for the confusion.

Even if we were not able to have amdgpu be the default upstream driver for CI we were definitely going to make it "officially supported", since the hybrid driver will be using amdgpu for CI anyways. The open question for us was (and to some extent still is) how messy adding SI support to amdgpu would be. At the moment it still looks messy, although hopefully we will be able to make it less like "two drivers duct-taped together" then everyone will feel better about an amdgpu-based solution.

At the time we spoke with Michael we weren't sure if we were going to be able to make amdgpu the default driver for pre-VI parts, and that's how libdrm-amdgpu over radeon becomes a contender as well. Around the same time we were talking to Michael we were also discussing some more recent ideas for making amdgpu the default upstream driver; feedback was promising so at the moment the "amdgpu for all GCN" solution is looking more attractive than it did a couple of weeks earlier.

The other confusing thing AFAICS was that some people talking about radeon and community contributions were thinking about HD5000/6xxx family parts while others (like me) were talking about early GCN.

Anyways, thanks for taking the time to talk this through.

[bridgman]

Page break and moderated again. Woo hoo !!

EDIT... OK, that's really wierd... when I saved the previous post I got a message saying "following posts were on next page" and my post was unapproved. Then when I refreshed the page I'm still on page 13. Maybe it's because this post is shorter than the previous one...

Let's try
making
the post
longer
and see
if we
were close
to a break

Nope. Curiouser and curiouser.

[DoctorWho]

Hoping http://www.phoronix.com/forums/member/8184-bridgman can clear this up

So just to be clear let me tell you my situation.

Some buyers of $3000 - $4000 mobile workstations like me are independent contractors. Sometimes we use enterprise linux distros and sometimes not. I use customized hardened kernels, stock kernels, distro kernels, and customized kernels with various options. It all depends on the job and whatever else I'm working on. So just because it's a mobile workstation doesn't automatically mean I will be using the enterprise drivers.

For my workstation I chose the M6100 gpu which is Bonnaire, Sea Islands, GCN 1.1 if I understand correctly. These are workstations shipping today from vendors like HP and Dell not systems that are 1 or 2 years old. Yes I know the last refresh might have been early last year but the point is they are being sold today and people are buying them with either AMD gpus or Nvidia.

When I read in articles and when you say that amdgpu is "experimental" and not enabled by default I interpret that to mean that AMD is just testing that code but will drop support for it and will only support GCN 1.2 and higher for amdgpu. Is that the case? Are we who bought these workstations SOL?
Edit: What I'm saying is will the M6100 have official amdgpu support with closed source as well as open source?

I had hoped in 2016 to eliminate dependence on X and switch to Wayland which I think can only be done with amdgpu.

I might be buying a new workstation by the end of the year or early next year (hoping the Polaris mobile gpus will make it into those by then). Will I regret with sticking with AMD for my current and past systems? (meaning: based on how AMD handles this Vulkan issue I might decide to go with Nvidia rather than AMD. I hope to stick with AMD)

[smitty3268]

For my workstation I chose the M6100 gpu which is Bonnaire, Sea Islands, GCN 1.1 if I understand correctly.

Yep, that's a GCN 1.1 CI card.

When I read in articles and when you say that amdgpu is "experimental" and not enabled by default I interpret that to mean that AMD is just testing that code but will drop support for it and will only support GCN 1.2 and higher for amdgpu. Is that the case?

Nope. There was no information one way or the other before, but bridgman confirmed here that's not the case.

Are we who bought these workstations SOL?

Nope.

I had hoped in 2016 to eliminate dependence on X and switch to Wayland which I think can only be done with amdgpu.

If you want to stick to the proprietary drivers, then yes you'll need amdgpu. If you want to use Mesa, then any GPU at all will work. Your card will be supported by amdgpu, so you're fine either way.

Will I regret with sticking with AMD for my current and past systems?

Well, I guess you're the only one who can answer that.

[bridgman]

What smitty3268 said. We developed amdgpu on CI hardware and kept the code in, but unless/until we can enable it by default we need to mark it as experimental because the open source stack over amdgpu won't have the test coverage that radeon gets.

From a hybrid driver perspective (mix of open and closed userspace on amdgpu kernel driver) the plan has always been to support CI and up, with various options being explored to cover SI as well. This works because the initial amdgpu-based Catalyst replacement drivers will be out of tree builds anyways, so having amdgpu not be default upstream for earlier GCN parts doesn't matter.