David Airlie Tackling RADV Vulkan Conformance

[smitty3268]

Absolutely. The earth could be eaten by a giant space goat. All kinds of things could happen. That is why we (and every other public company worth listening to) talk about current plans and current activities, not about future "firm commitments".

Are you saying the probabilities are equivalent to the earth being eaten by a giant space goat? Because i doubt that, in which case your argument is pretty weak. Can you categorically state that the chances of not opening the Vulkan driver are < 10%? That'd be nice to hear. Can you say there's even a small (10%-ish) chance of the drivers being opened before 2018? That'd also be nice to hear.

A year ago we were still working on getting the initial beta driver out. Time is a factor in getting the underlying driver released and solid as well, and IMO an even more important factor than whether or not the driver is available in source code form.

If you want game developers & porters to decide on Vulkan as the target for their next project then the top priority has to be getting a sufficiently large installed base of hardware with Vulkan drivers, not diverting developers from driver implementation to open sourcing before the driver is even finished.

That makes a ton of sense from the windows side of things, which I assume is where you're coming from. On linux, though, I have to imagine the pro driver install base is quite a bit smaller than the OSS drivers, which is why I think there's a disconnect here. The pro drivers are pretty meaningless on linux right now (in the non professional rendering setting), and becoming more so by the day.

I have to say, it doesn't help when you have 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, and that's the reason they're writing their own drivers. I mean, that's kind of a devastating assessment. You can keep saying it's all about not having enough time/money/manpower, but... That's pretty much the problem, isn't it?


By the way, congrats on the Vega code drops today. At least the GL driver is looking to be in a good place right now (well, once DC lands......)

Personally I don't really doubt that AMD's Vulkan driver will get open sourced eventually. I'm much less confident that anyone will care by the time it happens though.

[bridgman]

Well, to put it mildly your expertise far exceeds mine, so.... But I need to ask why did you guys even bother writing a -Vulkan- without making damn sure on the very first attempt it could be entirely open sourced? That's what is truly redundant right there.

You're messin' with the timeline there, buddy. You can only do that in the movies

Seriously, Vulkan was a relatively last-minute arrival that grew out of our Mantle work. By the time Vulkan started to gel we already had a relatively mature "next generation API" shared code base covering multiple APIs, all of which were tied to specific OSes (and none of which were targeting Linux). Vulkan was just one more API on top of the same code.

Did you know about radv as it was being contemplated?

We had been shipping Vulkan on Linux for ~4 months before Dave started working on RADV.

Just the fact itself that radv even exists proves beyond any doubt that the need for an OSS Vulkan implementation is real. You should have done something -publicly- right then and there. But you didn't and still haven't. (and have no change in plans)

We had already *done* something publicly before RADV started - announced our plans (in Oct 2015) to eventually open source the Vulkan driver that we would be shipping in the amdgpu-pro stack.

[duby229]

You're messin' with the timeline there, buddy. You can only do that in the movies

Seriously, Vulkan was a relatively last-minute arrival that grew out of our Mantle work. By the time Vulkan started to gel we already had a relatively mature "next generation API" shared code base covering multiple APIs, all of which were tied to specific OSes (and none of which were targeting Linux). Vulkan was just one more API on top of the same code.

We had been shipping Vulkan on Linux for ~4 months before Dave started working on RADV.

We had already *done* something publicly before RADV started - announced our plans (in Oct 2015) to eventually open source the Vulkan driver that we would be shipping in the amdgpu-pro stack.

That makes some amount of sense and I can be ok with that.

But you are playing on words, you have not shipped an Open Source Vulkan implementation on linux yet. And that is why radv was written. And that is right when you should have adjusted your plans and then made it publicly known. But you didn't, still haven't, and just said you have no plans to change that. Even though earlier in this very same thread you said you would be willing to tweak release in order to benefit radv... So what is it? Either you tweak release to benefit radv or the plan is still the same one you just referenced above. Its got to be one or the other. It cannot be both.

[bridgman]

Are you saying the probabilities are equivalent to the earth being eaten by a giant space goat? Because i doubt that, in which case your argument is pretty weak.

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.

Can you categorically state that the chances of not opening the Vulkan driver are < 10%? That'd be nice to hear. Can you say there's even a small (10%-ish) chance of the drivers being opened before 2018? That'd also be nice to hear.

I can tell you what our current plans are and our current activities are. Anything past that (for us or any public company) needs a team of lawyers and a page of disclaimer text, so I stick to current plans that's it.

That makes a ton of sense from the windows side of things, which I assume is where you're coming from. On linux, though, I have to imagine the pro driver install base is quite a bit smaller than the OSS drivers, which is why I think there's a disconnect here. The pro drivers are pretty meaningless on linux right now (in the non professional rendering setting), and becoming more so by the day.

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.

I have to say, it doesn't help when you have 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, and that's the reason they're writing their own drivers. I mean, that's kind of a devastating assessment.

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.

Personally I don't really doubt that AMD's Vulkan driver will get open sourced eventually. I'm much less confident that anyone will care by the time it happens though.

Yep, that is a fair concern. That said, if we want to make it easy for game developers to choose Vulkan as a cross-platform solution one of the things they ask for is a consistent implementation across the platforms, and it's more practical to share the closed-source implementation than to start over and move a Mesa-based implementation back to Windows and other OSes.

You also see how complicated new HW support is becoming; one of the reasons we like the idea of sharing the closed-source Vulkan driver is that it gives us a decent chance to start leveraging some of that work in the Mesa GL driver rather than having to do all that from scratch like we do today.

[duby229]

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

Ummm obviously game devs want to test their code on the actual driver that actual people will actually be using. And right now that is not amdgpu-pro, it is radv. The reference to the proprietary driver is because that's the Vulkan driver you are going to open source.

I want to know why you think it would be beneficial for game developers to design and test their games on a driver that very few people use today and no indication at all of when it will be open sourced and therefore used more. Especially considering radv already exists and is already being developed on and tested for.

[bridgman]

But you are playing on words, you have not shipped an Open Source Vulkan implementation on linux yet. And that is why radv was written.

I have to call BS on that. We had just started shipping the Vulkan driver in any form, and had only started talking about open sourcing the Vulkan driver ~5 months before that. Dave understands how long it takes to open up closed source code.

If you want to try blaming us for making Dave write radv then at least do it right - say something like "radv was written because Dave knew that the opened Vulkan driver would probably not be integrated with Mesa" or that "radv was written because Dave knew it would probably take us a year or more to open up our driver". Don't claim the only reason Dave worked on radv was because "it had been three whole months since we started shipping Vulkan on Linux and the driver still wasn't open".

And that is right when you should have adjusted your plans and then made it publicly known. But you didn't, still haven't, and just said you have no plans to change that.

I'm sorry, I have absolutely no idea what you are talking about here. Let's go back to the timeline, OK ?

Oct 2015 - first mention of including Vulkan driver in -pro stack, initially closed source then open source later
Mar 2016 - first "preview" amdgpu-pro stack
May 2016 - first "beta" amdgpu-pro stack
Jul 2016 - first mention of Dave working on a Vulkan driver

At this point we reviewed our plans, decided not to change them, and I have been saying that ever since with no apparent success.

Even though earlier in this very same thread you said you would be willing to tweak release in order to benefit radv... So what is it? Either you tweak release to benefit radv or the plan is still the same one you just referenced above. Its got to be one or the other. It cannot be both.

Auggh, stop pulling things out of context, mashing them together and then going "I don't understand" when the results don't make sense.

"In this very same thread" I said that SEVERAL MONTHS AGO I mentioned that it might make sense to see if we could resequence the open sourcing plans in a way that would help radv efforts, and I said that SUBSEQUENTLY we concluded there were no options worth pursuing. Multiple events spread across time, none of them happening today other than reminding indepe what I said at the time.

[indepe]

Absolutely. The earth could be eaten by a giant space goat. All kinds of things could happen. That is why we (and every other public company worth listening to) talk about current plans and current activities, not about future "firm commitments".

Rest assured I won't blame you if earth gets eaten by a giant space goat (and not for climate change either, although I think research does in fact show it exists, and is most likely, if not certainly, human caused).

Companies do make commitments such as "XYZ will be released in Q2 2017". I understand there is no such commitment for open source Vulkan, however when you say "over time we were going to work on open sourcing it", in the beginning, I expect that to mean 'within a few months'. Apparently that wasn't just me, and it is my understanding, from a public talk, that even Dave Airlie was surprised a few months ago that AMD "open sourcing" wasn't happening.

At that time I would expect such a statement to mean that you are committing to open source in the near future. Maybe you can argue that "over time" can be reasonably interpreted to mean "in a sequence of smaller steps over the next few years", however that would come as a surprise to me.

A year ago we were still working on getting the initial beta driver out. Time is a factor in getting the underlying driver released and solid as well, and IMO an even more important factor than whether or not the driver is available in source code form.

Personally I would agree, but not everyone here. Many here believe "open source" means that the development process, in certain steps, also happens openly. But I don't think that's the point here.

...
If you want game developers & porters to decide on Vulkan as the target for their next project then the top priority has to be getting a sufficiently large installed base of hardware with Vulkan drivers, not diverting developers from driver implementation to open sourcing before the driver is even finished. Or do you disagree, as duby229 seems to ?
...
I can't stop you from choosing to interpret my statements as meaning the opposite of what I actually say, but if you do that it is going to make conversation really difficult. Could you try taking my words at face value and asking questions if you see gaps or contradictions instead?
...
I just don't get this. What "firm promise" do you think we stepped away from ?

I'm not sure if you want to make the point that you never made a firm promise, if so, then I am not saying I can prove the opposite. What counts for me is that several people here, including knowledgable and well-meaning ones, where both surprised and disappointed that this still isn't happening.

In the original amdgpu presentation at XDC (Oct 2014) Vulkan did not even exist and there was no mention of it in the slides. In the 2015 XDC update (less than 18 months ago) we said that the hybrid stack (amdgpu-pro) was going to start with a closed source Vulkan driver but that over time we were going to work on open sourcing it.

The plan is still the same; we're just a year or so further into it now and "we're going to open source the Vulkan driver at some point in the future" has been replaced with "we are working on open sourcing it now". I don't see how this could be interpreted as "stepping away".

So what kind of time frame are you thinking of? Can it take another year, or several years?

[bridgman]

Ummm obviously game devs want to test their code on the actual driver that actual people will actually be using. And right now that is not amdgpu-pro, it is radv. The reference to the proprietary driver is because that's the Vulkan driver you are going to open source.

I want to know why you think it would be beneficial for game developers to design and test their games on a driver that very few people use today and no indication at all of when it will be open sourced and therefore used more. Especially considering radv already exists today and is already being developed on and tested for.

OK, I think I see the missing bit of information here. Remember that we do have NDA relationships with developers and are able to talk about plans & schedules in a lot more detail with them... and that the big win for Linux is getting WINDOWS games developed using Vulkan so that subsequent porting to Linux can happen more easily.

Developers making plans for Windows generally just want to know that the driver will be available on Linux.

[duby229]

I have to call BS on that. We had just started shipping the Vulkan driver in any form, and had only started talking about open sourcing the Vulkan driver ~5 months before that. Dave understands how long it takes to open up closed source code.

If you want to try blaming us for making Dave write radv then at least do it right - say something like "radv was written because Dave knew that the opened Vulkan driver would probably not be integrated with Mesa" or that "radv was written because Dave knew it would probably take us a year or more to open up our driver". Don't claim the only reason Dave worked on radv was because "it had been three whole months since we started shipping Vulkan on Linux and the driver still wasn't open".



I'm sorry, I have absolutely no idea what you are talking about here. Let's go back to the timeline, OK ?

Oct 2015 - first mention of including Vulkan driver in -pro stack, initially closed source then open source later
Mar 2016 - first "preview" amdgpu-pro stack
May 2016 - first "beta" amdgpu-pro stack
Jul 2016 - first mention of Dave working on a Vulkan driver

At this point we reviewed our plans, decided not to change them, and I have been saying that ever since with no apparent success.



Auggh, stop pulling things out of context, mashing them together and then going "I don't understand" when the results don't make sense.

"In this very same thread" I said that SEVERAL MONTHS AGO I mentioned that it might make sense to see if we could resequence the open sourcing plans in a way that would help radv efforts, and I said that SUBSEQUENTLY we concluded there were no options worth pursuing. Multiple events spread across time, none of them happening today other than reminding indepe what I said at the time.

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

[bridgman]

Companies do make commitments such as "XYZ will be released in Q2 2017".

Yes, but if you read the fine print the commitment is wrapped up in so many disclaimers as to be of little real value. Not my style.

I understand there is no such commitment for open source Vulkan, however when you say "over time we were going to work on open sourcing it", in the beginning, I expect that to mean 'within a few months'. Apparently that wasn't just me, and it is my understanding, from a public talk, that even Dave Airlie was surprised a few months ago that AMD "open sourcing" wasn't happening.

At that time I would expect such a statement to mean that you are committing to open source in the near future. Maybe you can argue that "over time" can be reasonably interpreted to mean "in a sequence of smaller steps over the next few years", however that would come as a surprise to me.

OK, I have to admit I find this baffling. Anyone who has followed the open source graphics effort over the last 10 years would understand how time-consuming it is to open up a closed-source driver and how far you have to get into the work before you are sure it can even be done. We spent literally years trying to open up some Catalyst code in the early days and eventually concluded it would be faster to rewrite it from scratch. Maybe people have just gotten too used to the recent rate of progress and ignored the 10 years of hard work it took to build up the foundations for that.

Personally I would agree, but not everyone here. Many here believe "open source" means that the development process, in certain steps, also happens openly. But I don't think that's the point here.

Sure, but without time travel you can't do that with an existing closed-source driver other than by starting over.

I'm not sure if you want to make the point that you never made a firm promise, if so, then I am not saying I can prove the opposite.

I think part of the problem is that too few people look at the source material - so what starts as "we're probably going to do something like this" gets combined with existing knowledge and other equally non-committal snippets of news into a slick article that can leave you with the impression of a much more ambitious plan.

What counts for me is that several people here, including knowledgable and well-meaning ones, where both surprised and disappointed that this still isn't happening.

Yeah, maybe the problem is that it's been a long time since the last time we went through a big open sourcing effort for closed source code. Might be 8 years since the last time, long enough for people to forget. We also don't talk much about all the work that happens behind the scenes in order for the current open source activities to keep running, and maybe that is part of the problem too.

Anyways, bottom line here is that I don't think any of us expected you (in the broader sense) to think open sourcing the Vulkan driver was something that was going to happen in a few months from when we first talked about it, given that every other comparably sized project has taken years. If that is a problem (and apparently it is) then even if we can't make commitments for when something will happen we can at least make it clear that it won't happen in less than <time>.

So what kind of time frame are you thinking of? Can it take another year, or several years?

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.