David Airlie Tackling RADV Vulkan Conformance

[smitty3268]

I think the probabilities are higher than that of the earth being eaten by a giant space goat, but what I also wrote was "all kinds of things could happen". Public companies as a rule do not make "firm commitments" about future events; they talk about current plans and current activities.

So in other words, no. That's what I expected. And for the record, as noted before companies commit to future events all the time. Ryzen had a 1Q2017 date attached, and the logistics of getting a new piece of hardware out are far greater than open sourcing an existing software driver.

What you mean is that AMD isn't committed enough to the open source drivers to guarantee a time, even a timeline as rough as a year. Which is fine and typical for a lot of software, but therein lies precisely some of the uncertainty that is being discussed.

I don't get the connection with the pro drivers. In the short term game developers need a driver *now* to work with and don't care whether it is open or closed, or which stack it gets deployed with as long as they see it leading to a suitable HW base.

You yourself just mentioned needing to get a large installed base of Vulkan drivers out there so that devs will start targeting it. If that's the goal, the pro drivers on linux are not the solution. They are probably targeting the windows drivers first, though. Anyway, you can see for yourself that Feral and Valve seems focused entirely on radv (unless you are privy to some knowledge I'm not) which just goes to show exactly how little the developers you are talking about think of those pro drivers.

Perhaps I don't spend enough time surfing the internet, but I don't remember seeing anything like "prominent people from Red Hat and Valve going on and on about how difficult it is to work with AMD and to get them to do anything". I certainly don't remember Dave citing that as a reason for working on RADV.

That's probably a good thing. I'm primarily talking about a recent conference where Dave presented radv. There was much snark about whether AMD would ever release their code, and if they did whether it would be another DC situation (aka 'thrown over the fence' and 'useless'). He also intimated that Valve came to him extremely frustrated, though that was all kind of just suggested and he didn't get into details. There was also something a while back from an ex-Valve employee who was pretty unflattering towards AMD, though again they didn't really spill the beans and really flame you. You could just see that they were hinting about things in that direction.

So all in all, it's fair to say i exaggerated this bit, but I definitely think it's something that immediately comes to mind when you think about AMD proprietary drivers and from my view in the cheap seats seems fairly well documented, if all very nebulously. Obviously most people aren't going to go around repeating private conversations, or at least I would hope they don't.

[bridgman]

So in other words, no. That's what I expected. And for the record, as noted before companies commit to future events all the time. Ryzen had a 1Q2017 date attached, and the logistics of getting a new piece of hardware out are far greater than open sourcing an existing software driver.

What you mean is that AMD isn't committed enough to the open source drivers to guarantee a time, even a timeline as rough as a year. Which is fine and typical for a lot of software, but therein lies precisely some of the uncertainty that is being discussed.

OK, I don't think you understand how much behind-the-scenes work is required to make a public commitment like that. Probably a more correct rewording of your statement would be "AMD didn't think diverting all those effort from working on drivers to working on commitments was a good use of time".

You yourself just mentioned needing to get a large installed base of Vulkan drivers out there so that devs will start targeting it. If that's the goal, the pro drivers on linux are not the solution. They are probably targeting the windows drivers first, though. Anyway, you can see for yourself that Feral and Valve seems focused entirely on radv (unless you are privy to some knowledge I'm not) which just goes to show exactly how little the developers you are talking about think of those pro drivers.

You are cherry-picking here, although I don't think it is deliberate. Feral is one of the few developers / porting houses that has actively embraced Mesa and actually gets into the open source driver code. Not quite the only one but pretty close. I would expect them to want the same experience on Vulkan, so radv would be the obvious choice for them. Same with Valve but for different reasons - they are working on VR infrastructure and again having open source is a big help to them. It doesn't have to be open source - we can and do share closed source driver code - but open source is much more convenient for both us and the developers.

What you can't do is generalize that "must have open source" thinking across to Windows developers. Even explaining the idea of open source upstream drivers outside of the Linux world is a tough sell and often a waste of time. If you come from the windows world then drivers are what you download from the HW vendor site and install using Setup. From that point of view the -pro drivers seem "real" and the open source drivers seem like some kind of voodoo. Seriously.

I'm primarily talking about a recent conference where Dave presented radv. There was much snark about whether AMD would ever release their code, and if they did whether it would be another DC situation (aka 'thrown over the fence' and 'useless').

I'll check with Dave, but my impression was that his reasoning was more "radv is moving fast enough that eventually AMD will give up on their plans to open source" rather than "AMD might never have released Vulkan source even if radv had never happened". Could be either though, depending on when he had last been updated on progress.

[bridgman]

Don't you realize that what I bolded here is -exactly- what the problem is?

*bridgman scratches head

Nope. Can you try to explain with more or different words please ?

[duby229]

*bridgman scratches head

Nope. Can you try to explain with more or different words please ?

Now I'm scratching my head because I don't know how to be more specific. A linux Vulkan driver is -not- going to encourage game studios to adopt Vulkan on windows. So this deal about a large installed userbase to encourage Vulkan adoption on Windows games seems like nonsense to me. Besides the largest installed userbase on linux right now is radv. And basically no thanks at all to AMD. (Obviously thanks AMD for the kernel driver, but what I'm talking about is the Vulkan implementation.)

Now read the quote that I bolded again. I don't know how to be any more specific than this.

EDIT: I can imagine a giant code drop that immediately gets rejected and then takes years more to clean up. I think it makes way more sense to contribute to radv right now. You should've changed plans and did so from the very first day you learned about radv.

[indepe]

We have schedules but don't have approval to publish them yet. That's why I am only saying "still following the same plan, work is proceeding" at the moment. If that changes, trust me we will say something.

An approval problem, then.

What you said in other posts, sounds like you are still supportive of RADV, if I may say so.

[bridgman]

Now I'm scratching my head because I don't know how to be more specific. A linux Vulkan driver is -not- going to encourage game studios to adopt Vulkan on windows. So this deal about a large installed userbase to encourage Vulkan adoption on Windows games seems like nonsense to me. Besides the largest installed userbase on linux right now is radv. And basically no thanks at all to AMD. (Obviously thanks AMD for the kernel driver, but what I'm talking about is the Vulkan implementation.)

Now read the quote that I bolded again. I don't know how to be any more specific than this.

EDIT: I can imagine a giant code drop that immediately gets rejected and then takes years more to clean up. I think it makes way more sense to contribute to radv right now. You should've changed plans and did so from the very first day you learned about radv.

Nope, not helping. A developer not interested in Linux is likely to go with DX12 since they already know that, so I don't understand how you can think Linux driver availability is not going to influence developers.

I also don't get your "largest installed base is radv" comment - certainly within Phoronix readership radv is probably higher (same for Mesa GL a couple of years back) but outside of power users I *think* what determines installed base the most is the combination of distro popularity, whether the distro includes radv out of the box, and whether amdgpu-pro support is available for the distro. Right now I think that probably works out in amdgpu-pro's favour although both numbers will be pretty low. Six months from now there's a good chance that will be different though (

Again, read what I said. Game developers asking about having the *same* driver on Linux & Windows.

I did go back and read your bolded comment again but it seems to be an attempt to summarize what I said. If there is some nuance in the colour or the font which is supposed to convey additional meaning I am not seeing it.

Who do you think is going to "reject" the open source Vulkan driver ? Assume you are talking about the distros ?

[duby229]

Nope, not helping. A developer not interested in Linux is likely to go with DX12 since they already know that, so I don't understand how you can think Linux driver availability is not going to influence developers.

I also don't get your "largest installed base is radv" comment - certainly within Phoronix readership radv is probably higher (same for Mesa GL a couple of years back) but outside of power users I *think* what determines installed base the most is the combination of distro popularity, whether the distro includes radv out of the box, and whether amdgpu-pro support is available for the distro. Right now I think that probably works out in amdgpu-pro's favour although both numbers will be pretty low. Six months from now there's a good chance that will be different though (

Again, read what I said. Game developers asking about having the *same* driver on Linux & Windows.

I did go back and read your bolded comment again but it seems to be an attempt to summarize what I said. If there is some nuance in the colour or the font which is supposed to convey additional meaning I am not seeing it.

Who do you think is going to "reject" the open source Vulkan driver ? Assume you are talking about the distros ?

So what you should be doing about it then is -educating- those retarded game developers. Catalyst proved beyond any doubt that the -same- driver between operating systems is completely irrelevant because it's wrong! Linux does not behave the same way that Windows does. It never will, even with amdgpu. They are going to be sadly disappointed and -you- are setting them up to be sadly disappointed. 1: Because radv exists, 2: because game devs actually do need to test their games on the drivers actually used.

Anyway, it's pointless to continue.

[bridgman]

I'm not involved in game developer discussions except for the ones using open drivers, although I assume "you" in this case means "our closed source teams" ?

[duby229]

I'm not involved in game developer discussions except for the ones using open drivers, although I assume "you" in this case means "our closed source teams" ?

You as in anybody working at AMD who shares the same stance you do. It's wrong it will harm linux, Catalyst already did and AMD must know that! AMDGPU-Pro is far more stable than Catalyst, but it didn't fix broken distro integration, it didn't fix OpenGL's abysmal performance. And because the kernel driver is effectively external it has exactly the same kernel compatibility problems Catalyst had and you guys are exacerbating the hell out of it with DC.

[bridgman]

You as in anybody working at AMD who shares the same stance you do. It's wrong it will harm linux, Catalyst already did and AMD must know that! AMDGPU-Pro is far more stable than Catalyst, but it didn't fix broken distro integration, it didn't fix OpenGL's abysmal performance. And because the kernel driver is effectively external it has exactly the same kernel compatibility problems Catalyst had and you guys are exacerbating the hell out of it with DC.

Please do not confuse "my stance" with the answers I give when you ask what our plans are.

Why would you expect a new kernel driver to help OpenGL performance ? We certainly didn't... we've been working on improving Mesa GL performance for that.

When you talk about distro integration are you talking about enterprise distros / WS users, or are you still thinking about -pro as "consumer driver for life" ?

If the latter, remember that once we have Vulkan open sourced (or use similar functionality in Mesa GL etc..) we can upstream the required kernel functionality and run the drivers over an upstream kernel. We're just stuck out-of-tree while we have kernel functionality that is only used by closed source userspace bits. Workstation OpenGL is the only part that might end up requiring out-of-tree kernel support but (a) I don't think it does today and (b) you (and the consumer users you are arguing for) don't care about that, do you ?