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

[bridgman]

"Replies below are on the next page. Click here to go to the next page".... and post #130 unapproved again.

EDIT - now that's really interesting... this time I got a second "next page" message, one above and one below my unapproved post... and once again it was a bogus page break because the next post stayed on page 13 despite being equal length. Perhaps the server has been drinking Michael's good beer when he's not around.

BTW I think we've always said that the hybrid stack would support CI and up. Things just got confused recently when Michael's article suggested that what we supported in the hybrid stack might be limited to what was enabled by default upstream today, which was never the case.

[DoctorWho]

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.

CI includes M6100, i.e. Bonnaire or is it SI? There's Sea Islands and Southern Islands too. Can't keep track of all these geographical references.
So you're saying the initial amdgpu out of tree drivers will work with both open and closed source userspace, is that correct? It's less convenient that they're not in tree but it's not that much of a problem. What's important is that they work with both thereby letting me use whatever I need regarding graphics systems such as X or Wayland.

Will the code that covers the M6100 eventually be in tree thereby making upgrades much easier for me?

[DoctorWho]

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.

Wrote a reply and it didn't post when I clicked "post reply". It always says "saved to drafts". Where are these drafts??
Rewriting it again ugh.

CI includes M6100, which is Bonnaire, Sea Islands? There's Sea Islands and Southern Islands too. Can't keep track of all these geographical references.
Having the initial amdgpu be out of tree is less convenient but what's important to me is that it will still work with both open and closed source, is that the case even initially?

Will the amdgpu eventually be in tree for M6100, which will make it more convenient for upgrading?

Another totally unrelated question, way off topic which you don't have to answer, will the Polaris mobile workstation gpus be ready in time new HP and Dell refreshes by Sept/Oct this year? The gpu in this mobile workstation is upgradable to even the W7170M or other MXM-B gpu but not sure if I want to do that.

[smitty3268]

CI includes M6100, which is Bonnaire, Sea Islands? There's Sea Islands and Southern Islands too. Can't keep track of all these geographical references.

M6100 = Sea Islands = CI = GCN1.1

[antar1nd]

As a SI card owner (R7250), I was inspired by Michael's post to explore the possibility of contributing to the amdgpu support. However, it seems even AMD's not clear about the path to take on that effect. While we are definitely going to rely on libdrm-amdgpu for vulcan, the call hasn't been made between whether libdrm-amdgpu should be extended to use radeon or adding SI support within amdgpu kernel driver.

In my opinion the first makes more sense if it results in support for older hardware (pre GCN), while the second makes more sense if SI is the extent to what we want to extend this support to (talking about the long term of course). Whatever way we go has to be decided by AMD I guess, before the community support kicks in.