RADV Gets A Big Performance Boost Thanks To DCC

[dungeon]

Hopefully with 2 options, 1 of them will actually succeed.

In capitalism, you always need to invent at least second one just to have competition and even third one if not more to play around just in case As always, God is one - just there are different POVs

In comparison to communism, where you shut up all competition but God too as both are not needed as everybody are virtually the same and looks boring except dictator

So, change is expected to happen when one of two sides from tireless mode goes into tired mode

[bridgman]

I find a lot of AMD's arguments here pretty questionable. They are simultaneously arguing that these drivers took no effort and that's why they're necessary instead of something like radv, and that they took a huge amount of effort and that's why it took 2 years to release and still aren't fully supporting new hardware... But whatever - radv has serious manpower issues and hasn't convinved me they can keep up with new hardware either, so whichever driver ends up working better is the one I'll end up using. Hopefully with 2 options, 1 of them will actually succeed.

You are misrepresenting what we are saying (in fairness, so is almost everyone). I find your version of our arguments questionable too

We are saying two things:

1. Now that the initial restructuring and open sourcing effort has been completed, the ONGOING effort to maintain the driver is relatively small because we are able to leverage work done for other OSes and APIs. We still need to do some work on community interaction, particularly in the area of managing commit history.

2. By the time that radv became a viable option (and Dave started talking about maintaining radv even after we released the open source version of AMD Vulkan) most of the open sourcing work had already been done and so the REMAINING effort (ie the effort people talked about us wasting) was relatively small.

So... big pile of effort to get where we are today... relatively small effort to keep going from this point. Make sense ?

[duby229]

So... big pile of effort to get where we are today... relatively small effort to keep going from this point. Make sense ?

And that's the part that is obviously a lie. Why do you think people keep questioning it? It's because its obviously not true. But like I said already, I'm content to let time do its thing. Almost all of us can easily predict what the future outcome is going to be. radv will overtake your driver eventually, even without your help. That's going to piss AMD off and they are going to pull out of open source. It's what ATi already did waaay back in something like 2001. Granted it was 16 or 17 years ago and under different corporate leadership, But right now AMD is behaving exactly the same way ATi was behaving back then. Its pretty easy to see which way precedence is going to take.

[bridgman]

And that's the part that is obviously a lie. Why do you think people keep questioning it? It's because its obviously not true.

Perhaps the way you use the word "obvious" is different from mine - why do you think it obvious ?

In other words, other than wishful thinking and alignment with your current world view why do you think the last line of my post was a lie ?

Almost all of us can easily predict what the future outcome is going to be. radv will overtake your driver eventually, even without your help. That's going to piss AMD off and they are going to pull out of open source.

Yep, that's exactly what happened with OpenGL. Mesa overtook the closed source driver; that pissed AMD off and we pulled out of open source.

Oh wait, that's not what happened. Instead we made Mesa the official consumer OpenGL driver and introduced packaged build options which used Mesa GL rather than the closed source driver.

It's what ATi already did waaay back in something like 2001. Granted it was 16 or 17 years ago and under different corporate leadership, But right now AMD is behaving exactly the same way ATi was behaving back then. Its pretty easy to see which way precedence is going to take.

So your thesis is that ATI's behaviour in 2001/2002 is a better predictor than AMD's behavior in 2016/2017 ? With respect, that's not obvious either.

[dungeon]

And that's the part that is obviously a lie. Why do you think people keep questioning it? It's because its obviously not true.

Ha, ha, you should obviosly maybe sleep a bit or take a break, if you are so obsessed with extremes like virtual truths and lies stories

Almost all of us can easily predict what the future outcome is going to be.

And now you even predict future

radv will overtake your driver eventually,even without your help. That's going to piss AMD off and they are going to pull out of open source.

Are you are some kind of anarchist or just extremist or maybe sado-maso?

[dungeon]

I was thinking where is the user dungeon with his personal insults and Sim Sala Bim, here he is again after a long pause.

Forcefully Unmap Complete Kernel With Interrupt Trampolines

[dungeon]

Yes, you are fuckwit.

Yes i am - fuckwit but near two times that, since God gave me this IQ 130 but i don't want to be Mensa member as i would be stupidest there

[smitty3268]

So... big pile of effort to get where we are today... relatively small effort to keep going from this point. Make sense ?

I'm not sure it's very helpful to continue this, but for the sake of discussion...

Can you explain easily *WHY* it was a big effort to get to this point and a small future effort?

I understand that you've said that maintenance will be easier - i just don't see any reasonable explanation of why that is.

You already have to add support into Mesa in order to get the GL driver working. Unless you're planning to abandon RadeonSI support for new hardware in favor of some new driver based on this new framework your Vulkan driver is built on top of? I don't get that impression at all, which is why this is so confusing. It seems like you are doubling up work, not reducing it, unless you throw away Mesa entirely. And we have pretty decent proof in the form of radv that sharing Mesa code makes for a pretty easy driver to create and maintain. It's difficult to see why that would change. Unless maybe there's going to be a radically different architecture coming up that requires completely redoing everything the way that r600->radeonsi broke everything and that's where the benefit will come from? Or the idea is to make Mesa a 2nd-class driver that doesn't have initial support for new hardware and will just slowly fill that in through non-AMD employees post-launch? That doesn't sound like anything I've heard is happening either.

And the idea that this new framework code is free because you had to have it from the start seems false on it's face. First, you didn't need it for the last 2 years, because it clearly didn't exist yet until now. And you can't say that it's all just cross-platform and free from now on - it's already been explained that certain parts of the code are linux-specific, which is why Vega support isn't fully working. So that code is very clearly not at all shared with the Windows driver, and completely separate - meaning all the maintenance work is still going to be there, just as if you had been working on it in Mesa.

Is it all about not wanting to share vulkan front-end code with Intel, so that you can do AMD specific extensions they don't want in Mesa, debugging stuff, etc. that matches the Windows AMD driver behavior instead of the Intel code? That's currently what makes the most sense to my mind, and personally it doesn't seem like a very good reason for AMD users. I can see why AMD management would like it, though.

I don't know - obviously no one on this forum knows the driver code and the workload AMD is doing nearly as well as anyone inside AMD, so on one level I'm fairly certain you have solid points that you're making. On the other hand, a lot of it just doesn't seem to make very much sense, and you're asking me to just trust you. I'm not 100% sold that's reasonable when dealing with a for-profit company. Even one that's trying to do their best can sometimes just be wrong, even if they think they're right, and changing positions that have been set in stone for years can sometimes be difficult even when changing circumstances mean they should be.

In the end, none of that really matters. Reality is what it is - 2 drivers exist, and it seems clear they will both continue existing for at least a while. I'm content to just use whichever turns out to work the best.

[bridgman]

I'm having trouble knowing how to respond - almost everything you say as "fact" is incorrect, and your outrage is clearly based on those "facts"... yet when I try to tell you the actual history and code sharing structure you come back with a fresh set of "not-facts" and renewed outrage. Feels like a troll but I think I know you well enough to be fairly sure that's not the case...

Can you explain easily *WHY* it was a big effort to get to this point and a small future effort? I understand that you've said that maintenance will be easier - i just don't see any reasonable explanation of why that is.

The Vulkan driver (along with a few other drivers) was developed starting ~4 years ago, built on a newly created set of common code written for next-gen APIs. The common code is used on multiple OSes and for multiple APIs, and the Vulkan driver is used on multiple OSes, so both of those have to be developed and maintained irrespective of what we do for Linux Vulkan.

We had to get the first PAL implementation written, tested and shipping (as closed source) on a tight schedule in order to meet API launch dates (Vulkan was not the first API using it), and so were not able to make the common code as modular and open-able as we wanted at the start. Finishing that work and integrating the changes back into shared code was time-consuming... mostly the integration part because the shared code was already shipping and supporting a number of different OS/API combinations.

You already have to add support into Mesa in order to get the GL driver working. Unless you're planning to abandon RadeonSI support for new hardware in favor of some new driver based on this new framework your Vulkan driver is built on top of? I don't get that impression at all, which is why this is so confusing.

Nicolai and Marek did investigate re-implementing radeonsi over PAL rather than Gallium3D and it did initially look promising, but there are enough differences in the APIs that PAL in its current form does not work out as an efficient base for OpenGL. It might still be able to evolve into something which can efficiently support OpenGL but not sure yet.

It seems like you are doubling up work, not reducing it, unless you throw away Mesa entirely. And we have pretty decent proof in the form of radv that sharing Mesa code makes for a pretty easy driver to create and maintain. It's difficult to see why that would change. Unless maybe there's going to be a radically different architecture coming up that requires completely redoing everything the way that r600->radeonsi broke everything and that's where the benefit will come from?

I think you are conflating "possible" with "zero effort" and drawing the wrong conclusions as a result. There isn't that much difference between time spent on radv and time spent on radeonsi over the last 18 months - just that most of the radeonsi work was done by AMD devs while the radv work was done by community devs.

Or the idea is to make Mesa a 2nd-class driver that doesn't have initial support for new hardware and will just slowly fill that in through non-AMD employees post-launch? That doesn't sound like anything I've heard is happening either.

This is getting pretty troll-like. Mesa is not a driver, it is a framework that a whole lot of different drivers and APIs live in. No plans to reduce support for radeonsi, no plans to support radv. I don't know how you would even start turning those two into a single statement about "plans to support Mesa".

And the idea that this new framework code is free because you had to have it from the start seems false on it's face. First, you didn't need it for the last 2 years, because it clearly didn't exist yet until now. And you can't say that it's all just cross-platform and free from now on - it's already been explained that certain parts of the code are linux-specific, which is why Vega support isn't fully working.

I don't see how you can possibly say "we didn't need it for the last 2 years" when we have been shipping it for almost 3 years as part of Vulkan and other closed source drivers.

Re: there being some OS-specific bits, think DC - the finicky & difficult-to-get-right parts are shared across OSes and APIs, but there are some (generally less finicky) parts which have to be OS-specific if only because the kernel drivers and wrappers (libdrm for Linux) are different.

So that code is very clearly not at all shared with the Windows driver, and completely separate - meaning all the maintenance work is still going to be there, just as if you had been working on it in Mesa.

You're usually less troll-like than this, which is bothering me. You just jumped from "some of it is Linux-specific" (of course) to "not at all shared with the Windows driver and completely separate" (totally different statement and not at all true).

Is it all about not wanting to share vulkan front-end code with Intel, so that you can do AMD specific extensions they don't want in Mesa, debugging stuff, etc. that matches the Windows AMD driver behavior instead of the Intel code? That's currently what makes the most sense to my mind, and personally it doesn't seem like a very good reason for AMD users. I can see why AMD management would like it, though.

Are you saying that we should have waited until Vulkan launch (and availability of the Intel driver source) before even starting to work on our own Vulkan driver, or that just as we were ready to launch we should have ripped the front end off and re-written it based on Intel code ?

The corresponding code in our driver was written 12-18 months before the Intel code was made public.

You seem to be deliberately ignoring the fact that the open Vulkan driver is nothing more than a sanitized version of the closed source driver, with the sanitizing efforts going back into the mainline code along the way. The main reason that sanitizing took a long time was that (a) it involved some fairly significant refactoring in some areas, (b) those efforts had to be done slowly & carefully to avoid breaking any of the other APIs or OSes supported by the shared code, and (c) in some cases (eg shader compiler) we moved to a different code base for the open version to align with code that was already being used in the open source world (eg LLVM ISA back end).

I don't know - obviously no one on this forum knows the driver code and the workload AMD is doing nearly as well as anyone inside AMD, so on one level I'm fairly certain you have solid points that you're making. On the other hand, a lot of it just doesn't seem to make very much sense, and you're asking me to just trust you. I'm not 100% sold that's reasonable when dealing with a for-profit company. Even one that's trying to do their best can sometimes just be wrong, even if they think they're right, and changing positions that have been set in stone for years can sometimes be difficult even when changing circumstances mean they should be.

Until the driver source code was actually out the door all of this discussion was pretty much academic. We had made commitments to open source the Vulkan driver, both publicly and privately, and we did just that.

In the end, none of that really matters. Reality is what it is - 2 drivers exist, and it seems clear they will both continue existing for at least a while. I'm content to just use whichever turns out to work the best.

Two drivers existed from the time that radv started to become useful, which is fine.

I just don't understand why you keep posting as if the open source Vulkan driver was some new thing we just created rather than being a sanitized version of the PAL code we have been shipping since 2015 and the Vulkan code we have been shipping since early 2016, integrated with a version of the open source shader compiler code that Tom started working on in 2011.

[smitty3268]

I'm having trouble knowing how to respond - almost everything you say as "fact" is incorrect, and your outrage is clearly based on those "facts"... yet when I try to tell you the actual history and code sharing structure you come back with a fresh set of "not-facts" and renewed outrage. Feels like a troll but I think I know you well enough to be fairly sure that's not the case...

I honestly wasn't outraged, just genuinely confused. I didn't think my post sounded outraged, either... I don't really appreciate being tagged a troll though.

I'll just add some quick thoughts below and then probably let this die.

The Vulkan driver (along with a few other drivers) was developed starting ~4 years ago, built on a newly created set of common code written for next-gen APIs. The common code is used on multiple OSes and for multiple APIs, and the Vulkan driver is used on multiple OSes, so both of those have to be developed and maintained irrespective of what we do for Linux Vulkan.

We had to get the first implementation written, tested and shipping (as closed source) on a tight schedule in order to meet API launch dates (Vulkan was not the first API using), and so were not able to make the common code as modular and open-able as we wanted at the start.

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

Nicolai and Marek did look at re-implementing radeonsi over PAL rather than Gallium3D and it did initially look promising, but there are enough differences in the APIs that PAL in its current form does not work out as an efficient base for OpenGL. Might still be able to evolve into something which can but not sure yet.

Interesting, and this is the kind of thing that would really make using PAL sensible, so you could share it with all your drivers. I really had no clue about this, I was just throwing around rampant speculation (some of which you seemed to take personally below) to try and make sense of things.

Same idea as DC - the finicky & difficult-to-get-right parts are shared across OSes and APIs, but there are some (generally less finicky) parts which have to be OS-specific if only because the kernel drivers and wrappers (libdrm for Linux) are different.

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?

You're usually less troll-like than this, which is bothering me. You just jumped from "some of it is Linux-specific" (of course) to "not at all shared with the Windows driver and completely separate" (totally different statement and not at all true).

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?

Are you saying that we should have waited until Vulkan launch (and availability of the Intel driver source) before even starting to work on our own Vulkan driver ? The corresponding code in our driver was written maybe 18 months before that.

Uh, no. I have no idea how you got that from the text you quoted. 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.

You seem to be deliberately ignoring the fact that the open Vulkan driver is nothing more than a sanitized version of the closed source driver, with the sanitizing efforts going back into the mainline code along the way. The main reason that sanitizing took a long time was that (a) it involved some fairly significant refactoring in some areas, (b) those efforts had to be done slowly & carefully to avoid breaking any of the other APIs or OSes supported by the shared code, and (c) in some cases (eg shader compiler) we moved to a different code base for the open version to align with code that was already being used in the open source world (eg LLVM ISA back end).

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.

Until the driver source code was actually out the door all of this discussion was pretty much academic. We had made commitments to open source the Vulkan driver, both publicly and privately, and we did just that.

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.

Two drivers existed from the time that radv started to become useful, which is fine.

I just don't understand why you keep posting as if the open source Vulkan driver was some new thing we just created rather than being a sanitized version of the PAL code we have been shipping since 2015 and the Vulkan code we have been shipping since early 2016, integrated with a version of the open source shader compiler code that Tom started working on in 2011.

What happens behind closed doors is irrelevant to users. The open source driver didn't exist until it was released. 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.