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

[duby229]

How about all the recent r600g work, such as gaining fp64, tessellation support, and GL4?

Isn't that pretty much the equivalent? After all, bridgman isn't saying these drivers would have to be built from scratch with no AMD documentation at all. It'd just be extending support from the existing drivers.

I guess my advice would be to prove me wrong. I don't think the community outside of AMD devs will actually do it. But if you think it can be done and you can do it, then please, by all means go for it.

At best it's wishful thinking and at worst it's sabotage. I don't know if someone is just dumb or evil.

[smitty3268]

Show me a history of AMD's drivers being developed successfully by anyone but AMD themselves? You remember before 2007 don't you? Do you really want to let you drivers fall into that position again? That is exactly what relying on community contributions will lead to.

How about all the recent r600g work, such as gaining fp64, tessellation support, and GL4?

Isn't that pretty much the equivalent? After all, bridgman isn't saying these drivers would have to be built from scratch with no AMD documentation at all. It'd just be extending support from the existing drivers.

[duby229]

... because being open source means that only the HW vendor can work on drivers ??? You're not really being serious, are you ?

Show me a history of AMD's drivers being developed successfully by anyone but AMD themselves? You remember before 2007 don't you? Do you really want to let you drivers fall into that position again? That is exactly what relying on community contributions will lead to.

[duby229]

I have said that we have pretty much rejected (a) but I have emphatically NOT said that (b) requires contributions outside of AMD.

Where do you think you read that ?



Seriously, what makes you think option (b) means "AMD doesn't have to support their hardware" ? And again, what makes you think that option (b) has anything to do with relying on outside contributions ?

Ok, fine. In that case, for an end user, b: is -exactly- the same as c:... Again, the bottom line is out of box Vulkan support. I was reasonably certain that Mr, Writers posts at the minimum implied that AMD would not pursue option b: themselves, but would allow community contributions to be considered. Which is not at all what you just said.

[bridgman]

That leaves only c: and only AMD is in a position to make that happen.

... because being open source means that only the HW vendor can work on drivers ??? You're not really being serious, are you ?

[bridgman]

Or you can simply add support for SI in the amdgpu kernel driver and make it so that it can be disabled by a kernel config option, then disable radeon *by default* and put out a notice for distributions that they need to enable radeon and disable SI support in amdgpu as long as they do not ship libdrm+mesa with the new support.

Or you can provide an installer for the user space drivers like intel does: https://01.org/linuxgraphics/downloa...er-linux-1.2.1

Not sure what I'm failing to make clear here, but the problem with disabling radeon by default too quickly is that if any user picks up a new kernel build (Linus requires that new kernels be able to replace old kernels) and they aren't already running userspace that can transparently switch over to amdgpu then every user who does that gets broken.

It's not just a matter of talking to distros, although individual distros still might be good test cases before flipping the switch upstream.

[artivision]

No, no and no. The most of as we don't care about Amdgpu, Radeon and what goes to what. We need zero day open source Vulkan support for all SM5 hardware (HD5-6 series included). If we can have that, then we may see some good native ports.

[bridgman]

You have lready said a: isn't going to happen, and b: requires contributions outside of AMD. So what does that leave? Pretty obvious huh? And for those of you that knew it already, it must have been obvious for a long time now.

I have said that we have pretty much rejected (a) but I have emphatically NOT said that (b) requires contributions outside of AMD.

Where do you think you read that ?

Expecting that suddenly things will change and AMD doesn't have to support their hardware because Option b: is available is pretty dumb considering that it almost certainly -won't- happen. If AMD is saying that they are relying on Option b:, then we all might as well forget about Vulkan on SI.

Seriously, what makes you think option (b) means "AMD doesn't have to support their hardware" ? And again, what makes you think that option (b) has anything to do with relying on outside contributions ?

[duby229]

We live a universe that abides fractal dynamics. What happens tends to happen. Outside developers don't tend to contribute to AMD's graphics drivers. AMD is itself responsible for bringing up the OSS drivers for their hardware. They've done a fantastic job at it and have developed top notch drivers for Linux. Expecting that suddenly things will change and AMD doesn't have to support their hardware because Option b: is available is pretty dumb considering that it almost certainly -won't- happen. If AMD is saying that they are relying on Option b:, then we all might as well forget about Vulkan on SI.

EDIT: Like I already said the bottom line is out of box Vulkan support. Options a: and b: aren't going to happen. That leaves only c: and only AMD is in a position to make that happen.

[duby229]

Did you actually read anything I wrote ?

First, there are a few different ways to achieve the goal you described, with the most obvious ones being (a) Vulkan over libdrm-radeon using radeon kernel driver, (b) Vulkan over libdrm-amdgpu using radeon kernel driver, (c) Vulkan over libdrm-amdgpu using amdgpu kernel driver... not just option (c) as you suggest.

We will probably end up going with (c) but (b) lets us get there more quickly because we don't need to wait for new userspace to dribble out through distros onto user systems, so we have been exploring both options.

Second, you think you are reacting to what we have actually been doing for the last year, but in fact you are just reacting to an article Michael wrote. Big difference.



m saying ?

You have lready said a: isn't going to happen, and b: requires contributions outside of AMD. So what does that leave? Pretty obvious huh? And for those of you that knew it already, it must have been obvious for a long time now.

Yes, I'm responding to an article, but you must have known or intuited that this would be a problem a long time ago. You have and have had knowledge that I don't have. Of course I responded to an article. Your policy of trying to keep everything to yourself till the last second right before it backfires on you is part of that problem.