RADV Gets A Big Performance Boost Thanks To DCC

[agd5f]

Of course, but I don't think you can say you did that work -for- amdvlk. In fact it's -the- reason radv even exists at all. That 's a great part of what makes radv so great and amdvlk such a horrible waste.

Why is it a waste? amdvlk utilizes all of that as well.

[agd5f]

I have to ask why you think code needs to be shared across OSes? Why? Everything you needed already existed and radv is proof beyond a doubt. All you guys did was produce a fatter slower driver in a lot longer time using way more resources.

So we can leverage the all the resources on the AMD vulkan team. The AMD vulkan team still has to produce a vulkan driver for other OSes, so it's not like there is a significant resource savings but not leveraging it for Linux. AMD doesn't have a Linux vulkan team. We just have a vulkan team that supports multiple OSes with the same code base. Supporting radv would cost more resources since we would then have to hire additional developers to work on it and maintain two vulkan development teams.

[duby229]

So we can leverage the all the resources on the AMD vulkan team. The AMD vulkan team still has to produce a vulkan driver for other OSes, so it's not like there is a significant resource savings but not leveraging it for Linux. AMD doesn't have a Linux vulkan team. We just have a vulkan team that supports multiple OSes with the same code base. Supporting radv would cost more resources since we would then have to hire additional developers to work on it and maintain two vulkan development teams.

Which costs a whole lot more. Time itself and radv have already proven that. Amdvlk finally exists well over a year later. It -is- slower. It -is- fatter. It -did- take longer. These are already proven as facts. You can't deny them.

EDIT: I mean really why would you even want to leverage something that has already proven itself to be slower, waaay -the fuck- bigger, almost completely undocumented, well over a year too late, and to top it all off it has less compatibility...... It just sounds stupid as hell to me. Corporate excuse at its finest.

[agd5f]

Which costs a whole lot more. Time itself and radv have already proven that. Amdvlk finally exists well over a year later. It -is- slower. It -is- fatter. It -did- take longer. These are already proven as facts. You can't deny them.

What costs more? Please be specific. I just explained how supporting radv would require AMD to hire additional developers that we don't currently have. We didn't write amdvlk from scratch for Linux. It's the same code base shared with other OSes. The move to llvm was independent of the open source plan, it just happened to also be a requirement for open source. As for performance, it's currently comparable. Additionally, it also supports some features that are not yet supported in radv like transfer queues.

EDIT: I mean really why would you even want to leverage something that has already proven itself to be slower, waaay -the fuck- bigger, almost completely undocumented, well over a year too late, and to top it all off it has less compatibility...... It just sounds stupid as hell to me. Corporate excuse at its finest.

What do you mean by less compatibility? It arguably has more compatibility as it handles more hw corner cases and the shared code is validated across a lot of asics on many OSes on a regular basis. As for documentation, have you looked at the code? It's arguably better documented from both a hw and code perspective. Just about every function and hw requirement is documented with a detailed comment.

[duby229]

I have no power to influence anything you guys do unfortunately, so for now I'm content to let time continue to do its thing. It's plainly obvious to all of us but for the most blind-sighted ones.

EDIT: I'll continue to put my faith in software developed on linux and for linux in the open rather than code developed behind closed doors and then some time later made open source. It's plainly obvious that throwing closed source code over that open source wall isn't going to develop into a good open source development model. Obviously. So like I said I'll continue to be content to let time do its thing.

[duby229]

What costs more? Please be specific. I just explained how supporting radv would require AMD to hire additional developers that we don't currently have. We didn't write amdvlk from scratch for Linux. It's the same code base shared with other OSes. The move to llvm was independent of the open source plan, it just happened to also be a requirement for open source. As for performance, it's currently comparable. Additionally, it also supports some features that are not yet supported in radv like transfer queues.

I just have one nitpick. It surely seems to me like right here you are saying flat out that AMD needs to hire more open source developers. So if that's what you're saying, then why aren't you? Please fulfill the needs you have. I can't possibly be misinterpreting that badly. If you have roles in your development model that need filled then by all means please try to fill them. Open source developers deserve to get paid and AMD has been fantastic in regards to hiring the best talent they recognize. It really is in AMD's best interest to continue that reputation.

[agd5f]

I just have one nitpick. It surely seems to me like right here you are saying flat out that AMD needs to hire more open source developers. So if that's what you're saying, then why aren't you? Please fulfill the needs you have. I can't possibly be misinterpreting that badly. If you have roles in your development model that need filled then by all means please try to fill them. Open source developers deserve to get paid and AMD has been fantastic in regards to hiring the best talent they recognize. It really is in AMD's best interest to continue that reputation.

My point is that amdvlk (which you claim costs more), actually requires fewer developers from AMD to support because we only need one vulkan team rather than two. AMD is a company whose goal is to make money and generate shareholder value. Why should we pay for two development teams when we can get the job done with one? We always try and hire the best talent we can find.

[agd5f]

I have no power to influence anything you guys do unfortunately, so for now I'm content to let time continue to do its thing. It's plainly obvious to all of us but for the most blind-sighted ones.

EDIT: I'll continue to put my faith in software developed on linux and for linux in the open rather than code developed behind closed doors and then some time later made open source. It's plainly obvious that throwing closed source code over that open source wall isn't going to develop into a good open source development model. Obviously. So like I said I'll continue to be content to let time do its thing.

I get the opinion that all things that come from big corporate entities are evil and the only way to develop a "real" driver is something organic from some grassroots hobby developers that turns into something wonderful. But maybe give it a chance? We are trying to get more AMD teams involved in open source here. How is that a bad thing? We have a lot of great developers on the AMD vulkan team and it would be great to get them involved in the open source community. It's not going to be perfect from the start, but things will improve with time. Most of our current open source developers started as internal developers and transitioned to working on open source. Frankly there are not enough spare time contributors with open source experience that we could hire to meet all of our development needs.

[duby229]

I get the opinion that all things that come from big corporate entities are evil and the only way to develop a "real" driver is something organic from some grassroots hobby developers that turns into something wonderful. But maybe give it a chance? We are trying to get more AMD teams involved in open source here. How is that a bad thing? We have a lot of great developers on the AMD vulkan team and it would be great to get them involved in the open source community. It's not going to be perfect from the start, but things will improve with time. Most of our current open source developers started as internal developers and transitioned to working on open source. Frankly there are not enough spare time contributors with open source experience that we could hire to meet all of our development needs.

I'm sorry, I really don't want to sound too argumentative. I do apologize. But while you said all of that radv already exists. And the only reason it exists is because everything AMD needed was there but they hadn't already done it.


EDIT: At that time amdvlk didn't even have a name, it was just an empty promise. That's the whole reason radv exists. You have to admit this closed development tactic bites you in the ass so hard.

[bridgman]

EDIT: I'll continue to put my faith in software developed on linux and for linux in the open rather than code developed behind closed doors and then some time later made open source. It's plainly obvious that throwing closed source code over that open source wall isn't going to develop into a good open source development model. Obviously. So like I said I'll continue to be content to let time do its thing.

The amdgpu driver was developed behind closed doors and then some time later made open source.

Most of the radeonsi code was developed behind closed doors and then some time later made open source.

Seriously, you're complaining about the wrong things