RADV Gets A Big Performance Boost Thanks To DCC

[bridgman]

Maybe the problem is just word choice - your "rampant speculation" comes across as statement of fact without the qualification that would usually accompany statements that were so speculative. Sorry if I over-reacted.

I'll respond to the other points later - need to get back to working outside before the sun goes down and it gets really cold

[duby229]

Maybe the problem is just word choice - your "rampant speculation" comes across as statement of fact without the qualification that would usually accompany statements that were so speculative. Sorry if I over-reacted.

I'll respond to the other points later - need to get back to working outside before the sun goes down and it gets really cold

Everything that anyone can say would be speculation, AMD doesn't talk about unreleased products. Amdvlk was only just recently released and so you can see how speculation is the only option. Not to mention that most of what you just said in the two posts above -only- you or someone else in your similar position could know and not a linux user sitting on a forum somewhere.

You are the -only- source for more than half of what you just said and you've proven so extremely biased that your words can't be trusted as being the best possible thing for Linux. Amdvlk definitely isn't.

[bridgman]

I certainly have no doubt that there is some common shared code. That seems irrelevant to the discussion. There'd be shared code by using Mesa too - I guess your point is that there is more shared code this way, and I'll just have to take you at your word there.

How can it be irrelevant to the discussion ? Code sharing is what the discussion is all about.

What is obvious to everyone, though, is that radv took advantage of that shared code and a very small labor force was able to come up with a working solution that apparently requires very little maintenance.

That "very small labor force" is comparable to what it took us years to get funded for OpenGL. Developers don't actually grow on trees. Being able to share existing Vulkan/PAL code rather than having to build up another (albeit small) team to maintain radv and add good support for new GPUs makes a *big* difference in what we can do.

It seems you disagree with that point and think that there's been lots of work going on there. I guess maybe you know more there than I do in terms of the ongoing amount you think amdvlk will require, it just seems like radv is a pretty low bar to start with there.

Interesting. Can you share an example of something finicky and difficult to get right? Something that isn't already in Mesa for radesonsi, that is, and would need to be duplicated separately for the Vulkan driver?

Saying "that isn't already in Mesa for radeonsi" misses the point - that code isn't shared, it's somewhere between "refactored" and "rewritten" between radeonsi and radv. We actually share the code between AMDVLK and other OSes/APIs without having to rewrite/refactor for every new GPU generation.

I meant major parts, obviously. Here's what's bothering me - the entire shader compiler code is apparently linux specific. Right? Or is that another misunderstanding? The shader compiler seems like a highly complicated part of the driver, especially given how minimal the actual Vulkan API is. And it something that will need to be constantly updated for new hardware. It seems like the very definition of what you'd most want to share code with, and it seems like it would be a large portion of any vulkan driver. But you seem to be indicating the opposite, i guess? That's it's a minor detail that will be trivial to maintain linux code for, and it's the rest of the driver that's complicated?

I'm not saying either of those things - it's not a new shader compiler we wrote just for open source Vulkan and it's not trivial. It's the third thing - existing code that multiple AMD teams (and community devs) have been working on since ~2011. What we did was take the shader compiler back-end we already use in radeonsi and ROCM/HCC and use it for open source Vulkan as well.

Uh, no. I have no idea how you got that from the text you quoted.

Simple - you asked why we didn't use the Intel open source Vulkan code but you ignored the point that the code was not open source at the time it would have been useful... it didn't exist in open source form until maybe 18 months after we had written our Vulkan driver.

I was trying to get that perhaps the difficult part of the vulkan driver is specific custom behaviors you wanted to add such as the CodeXL support or other stuff like that, which would also have to be added/maintained in Mesa? Stuff that Intel had already done differently in Mesa which would need to be changed and require lots of work. Again, rampant speculation on my part that was not intended to provoke.

I think we might also have a disconnect in terms of how much of the Intel Vulkan driver you think radv is using. My understanding is that it is relatively little other than the API-related headers and maybe some parsing code, but none of the really time consuming bits.

We definitely want to include support for developer-focused tools like CodeXL though.

I honestly have a hard time reconciling "2 years of hard work", "new shader compiler", and "nothing more than a sanitized version". It's very difficult to accept that. I guess I need to though.

Replace "new shader compiler" (since it wasn't a new shader compiler other than new-to-AMD-Vulkan) with "sanitizing code which was already shipping in production in support of multiple performance-critical APIs" and maybe it will be easier to reconcile ?

I think that's kind of the point though. Did the commitment make any sense? Does it still? Maybe it does, but I don't think you can criticize someone just for questioning that.

Hard to say. It certainly made sense when we made the commitment, and it still made sense when we did most of the hard work (which was before the final integration which took a lot of the calendar time). You need to distinguish between effort (developer-months or whatever) and calendar time - there are parts of a project where you can have a lot of people working effectively, and parts where having more people doesn't help much. Sanitizing projects tend to be the opposite of typical (back-heavy) projects in the sense that most of the "wide" part of the project is near the front.

What happens behind closed doors is irrelevant to users. The open source driver didn't exist until it was released.

Huh ?

Most of the code existed in 2015, and the open source driver (albeit with different shader compiler) was released in closed source form from early 2016. If you can get it into your head that they are not two different drivers this will all (hopefully) make more sense.

See the sunk cost fallacy - and no, I'm not trolling you by saying that any of this was wrong by AMD. I'm just saying that it's very easy to get caught up in the fact that you've spent money trying to get this driver out the door and therefore it must be made useful, without evaluating freshly whether it really is or not. Sometimes circumstances change. And sometimes that doesn't matter, and your initial plan was right anyway.

[bridgman]

Everything that anyone can say would be speculation, AMD doesn't talk about unreleased products. Amdvlk was only just recently released and so you can see how speculation is the only option. Not to mention that most of what you just said in the two posts above -only- you or someone else in your similar position could know and not a linux user sitting on a forum somewhere. You are the -only- source for more than half of what you just said and you've proven so extremely biased that your words can't be trusted as being the best possible thing for Linux. Amdvlk definitely isn't.

Don't think I am "the only source" here - agd5f has posted a lot about this and a couple of other devs have commented as well.

It seemed you guys were ignoring agd5f so I jumped back in, but you seem to be ignoring what I say too

Anyways, I don't think I have ever claimed that something is "the best possible thing for Linux" so I don't know why you're questioning whether I can be trusted to say that. The closest I have ever come over the years is "this is the best thing we can do right now, and it's a heck of a lot more than our major competitor in this space", which I still think is fair.

[duby229]

How can I be "the only source" ?

agd5f has posted a lot about this - it seemed you guys were ignoring him so I jumped back in, but you seem to be ignoring what I say too

Anyways, I don't think I have ever claimed that something is "the best possible thing for Linux" so I don't know why you're questioning whether I can be trusted saying that. The closest I have ever come to that is "this is the best thing we can do right now, and it's a heck of a lot more than our major competitor in this space".

If Red Hat and Google call up and say that Dave & Bas will be responsible for ongoing support of radv including new GPU support under NDA" that would be different, but right now all you are saying is that we should spend more money on a new radv team rather than using code we already have. That's a tough sell, although it may get easier with time once the ongoing cost of community engagement is better understood.

The "ongoing cost of community engagement" says it all IMO. You're the one who said it and yet you probably have absolutely no idea why that sounds so bad. I don't ever want to have to say to someone, "hmm, remember when it was AMD and not Redhat who pioneered their drivers?". It's not if, it's when amdvlk dies, we are all going to bre forced into recognizing that unfortunate fact. And your words make it sound like that's etire actual plan, because it's definitely whats gonna happen.

EDIT: I don't think you'll ever admit how expensive and enormous amdvlk really is. Tell me again how long did it take to port to linux? Whether you like it or not, you -just- said a few posts above this one it took 4 years! And your telling people here that radv would've been more expensive then that! BS. Meanwhile the real truth is Radv is something like a fifth of the size of amdvlk, is nearly feature complete already, and is outperforming it almost across the board. And it was developed primarily by 2 guys, which isn't even their primary responsibility! Tell me another lie about what cost more. Please.

EDIT: I am absolutely convinced Amdvlk cost many times more than radv. Sorry, but your "cost savings" cost way more than you possibly -could- have spent otherwise. You wouldn't even have been able to spend that much on radv. You say it took 4 years to get amdvlk running on linux, the real fact is radv with only 2 part time devs took less than 1! The -only- reason radv even exists -at all- is because AMD didn't already do it! Talk about expense, that was truly expensive.

[bridgman]

The "ongoing cost of community engagement" says it all IMO. You're the one who said it and yet you probably have absolutely no idea why that sounds so bad. I don't ever want to have to say to someone, "hmm, remember when it was AMD and not Redhat who pioneered their drivers?". It's not if, it's when amdvlk dies, we are all going to bre forced into recognizing that unfortunate fact. And your words make it sound like that's entire actual plan, because it's definitely whats gonna happen.

Let's see... Corbin started the current r300 Gallium3D driver, Jerome (RH) started the current r600 Gallium driver... nope, world hasn't ended yet.

EDIT: I don't think you'll ever admit how expensive and enormous amdvlk really is. Tell me again how long did it take to port to linux? Whether you like it or not, you -just- said a few posts above this one it took 4 years! And your telling people here that radv would've been more expensive then that! BS. Meanwhile the real truth is Radv is something like a fifth of the size of amdvlk, is nearly feature complete already, and is outperforming it almost across the board. And it was developed primarily by 2 guys, which isn't even their primary responsibility! Tell me another lie about what cost more. Please.

Like smitty3268, you have to stop thinking about AMDVLK as a single driver in isolation if you want things to start making sense. It's not a substantially different driver from Vulkan on Windows, and it's not even that different from drivers for other APIs. It's not even different from the closed source Vulkan driver other than using the LLVM back end for compiling shaders and a bunch of sanitizing work.

We did spend 4 years writing a set of drivers for multiple APIs and OSes running over a common code base (PAL), but Linux is only one of those OSes and Vulkan is only one of those APIs. Taking one OS/API combination out of the set doesn't reduce the total effort that much.

Am I correct in understanding that you have switched from complaining about the effort we invested in finishing the open-sourcing work on Linux Vulkan to complaining about us implementing Linux Vulkan support in the first place ?

If you want to argue that we spent a lot of money writing a "Linux plus other OSes" Vulkan driver (the one we started shipping in early 2016) and could have just written a Vulkan driver for "other OSes" because of radv, I agree completely, but that wouldn't have saved much in the way of overall work.

Back in early 2016 would you really have been OK if we had said "we're not making a Vulkan driver but don't worry, someone in the community will write one and it'll be in pretty good shape by the end of 2017" ? You want "bad for Linux" ?

IMO Vulkan was the best hope Linux gaming has seen in a long time (maybe since the original DRI work) but it only had a chance of changing the gaming landscape if (a) all the vendors had Vulkan drivers close to initial release and (b) the Vulkan drivers on Windows were sufficiently competitive with DirectX to let game developers think seriously about implementing for Vulkan instead of DX.

I don't think waiting for a community driver was a viable option, if that's what you are implying we should have done.

[duby229]

Let's see... Corbin started the current r300 Gallium3D driver, Jerome (RH) started the current r600 Gallium driver... nope, world hasn't ended yet.

Both of which AMD officially supports and helped tremendously to develop after 2007. In fact after 2007 AMD devs really were the main contributors and it became the officially recommended drivers for those generations. It's pretty clear now that's not gonna happen with radv....

Am I correct in understanding that you have switched from complaining about the effort we invested in finishing the open-sourcing work on Linux Vulkan to complaining about us implementing Linux Vulkan support in the first place ?

Um no, radv already exists.... In fact it -only- exists -because- AMD didn't already do it.

If you want to argue that we spent a lot of money writing a Linux/Windows Vulkan driver (the one we started shipping in early 2016) and could have just written a Vulkan driver for the other OSes because of radv, I agree completely, but that wouldn't have saved much in the way of overall work.

There we go, that's the other lie I was waiting for ---- again....

Back in early 2016 would you really have been OK if we had said "we're not making a Vulkan driver but don't worry, someone in the community will write one and it'll be in pretty good shape by the end of 2017" ? You want "bad for Linux" ?

The -only- reason radv exists at all is because AMD didn't already do. Radv is here now because you didn't do it.... What you did was already bad for linux.. Radv tried to fix it fortunately.

IMO Vulkan is the best hope Linux gaming has seen in a long time (maybe since the original DRI work) but it only had a chance of changing the gaming landscape if (a) all the vendors had Vulkan drivers close to initial release and (b) the Vulkan drivers on Windows were sufficiently competitive with DirectX to let game developers think seriously about implementing for Vulkan instead of DX. I don't think waiting for a community driver was a viable option, if that's what you are implying we should have done.

Don't you mean waiting for amdvlk? Cause we didn't wait for radv, it was developed in the open from the beginning, we all had access to it from the first day, it was functional to some degree over a year before amdvlk even had a name! We -didn't- wait for a comunity driver, what we actually waiting well over a year for was amdvlk!

Don't you think you got that completely backwards? History already happened. Facts are facts.

We did spend 4 years writing a set of API drivers for multiple OSes running over a common code base (PAL), but Linux is only one of those OSes and Vulkan is only one of those APIs. Taking one OS/API combination out of the set doesn't reduce the total effort that much.

And that total effort doesn't mean jack shit at all. It took way longer, cost way more, and in the end radv is smaller, faster, better in many, many metrics. If those were your goals then you failed well over a year ago! It was time then to pick up the peices and move on to the correct strategy. Unfortunately you still haven't moved on to the correct strategy, so were does that leave AMD? Well it leaves AMD with a horribly expensive amdvlk driver that only the most rabid fanboys are gonna use and that radv beats handily..

[bridgman]

You keep changing frames of reference between posts. Please stop.

In the previous post you talked about us spending 4 years creating AMDVLK. Most of that time went into creating the Vulkan driver that we shipped as closed source in early 2016, and most of *that* time was shared with other OSes and other APIs, so you can't use "4 years" and "AMDVLK" in the same discussion. AMDVLK is a sanitized version of the driver we shipped in early 2016, with the sanitizing work going back into the common code base.

Please be specific and consistent with what you are criticizing. Otherwise we will just keep going in circles.

[bridgman]

And that total effort doesn't mean jack shit at all. It took way longer, cost way more, and in the end radv is smaller, faster, better in many, many metrics. If those were your goals then you failed well over a year ago! It was time then to pick up the peices and move on to the correct strategy. Unfortunately you still haven't moved on to the correct strategy, so were does that leave AMD? Well it leaves AMD with a horribly expensive amdvlk driver that only the most rabid fanboys are gonna use.

Oh boy, accounting games. I didn't think we would go there. OK, let's play.

You're saying that the total cost of developing a full set of drivers for multiple APIs and multiple OSes should all go on AMDVLK, which makes it a bad decision and a bad investment. By those rules, I agree completely.

On the other hand, it did come with "free" drivers for a bunch of other OS/API combinations, so there's that.

Are you willing to talk about the cost of developing and maintaining the full set of drivers vs the cost of one API/OS combination ? If not then I don't see how we can have an intelligent discussion.

[duby229]

You keep changing frames of reference between posts. Please stop.

In the previous post you talked about us spending 4 years creating AMDVLK. Most of that time went into creating the Vulkan driver that we shipped as closed source in early 2016, and most of *that* time was shared with other OSes and other APIs, so you can't use "4 years" and "AMDVLK" in the same discussion. AMDVLK is a sanitized version of the driver we shipped in early 2016, with the sanitizing work going back into the common code base.

Please be specific and consistent with what you are criticizing. Otherwise we will just keep going in circles.

Haha! Yet amdvlk was simply nowhere at all for all that time when radv already existed and already worked. While amdvlk was developed behind closed doors, radv was developed in the open and actually got contributions from game devs. What makes amdvlk a bad decision is the fact that it was completely unnecessary, radv itself proves beyond any doubt that everything linux needed for a native vulkan driver already existed. Radv itself also proves it could have been done faster in less time and with fewer devs spending fewer hours on it. These are not questionable, history already happened, it's already done.

Since amdvlk was so "free" as you say then please tell me why the hell was it simply nowhere at all for well over a year? If you guys had released it on that same day you announced it and just continued to develop it in public, then radv wouldn't even exist at all. It's here -because- AMD didn't have anything. Which brings me to my point.... again.... The total cost, the cross platform infrstructure you guys developed don't mean jack shit to linux because open source development always produces superior code. While amdvlk was simply nowhere at all, radv was being developed openly, it was being improved by game devs, it was being used by gamers. All the while for an end users perspective amdvlk didn't even exist.

Oh yeah, sure now that it's -finally- released it's convenient to make it seem like it's just always been here, but the real truth is it just got released recently. And we all already know AMD doesn't talk about unreleased products.

EDIT: Sorry, but I have been completely consistent. My argument is and has been that amdvlk cost more to develop than radv. Additionally that cost is exacerbated by the fact that amdvlk was totally unnecessary. And what makes amdvlk's cost even worse, the real capper of it all, is that radv only exists because AMD didn't make it first! -THE- very thing you say would have been "bad for linux" actually happened and it's called radv! The real fact is that radv -proved- it's good for linux. The whole time amdvlk was nowhere at all, radv was was being developed openly and was available more than a year before amdvlk. And when amdvlk was -finally- released radv outperformed it impressively on a few metrics and it's plainly obvious why.