RADV Gets A Big Performance Boost Thanks To DCC

[username4890]

@dubby229 I don't think you understand anything about software development. The amd driver has to exist for other oses and api's anyway, so the work has to be done regardless. If they went the route you suggested, you're asking them to implement everything twice. Every perf patch and fix has to be done twice. It's literally twice the amount of work. In the long run what they did costs less. As for radv, nice as it is I don't want it to stick around. You're telling me you'd rather have 2 people who have no obligation to do so to support your hardware instead of the people whose best interest is to do so and is in fact in the best position to do so as well? And I don't believe on the whole open source equals the best software be. It's the developers that make software good. This is the best thing for Linux. Any improvements from other oses and api's benefits Linux. dx12 patches now also helps Linux. Idk about you but I'm a lot more interested in performance software than being an open source community jerk wad. It has its place but you have to recognize its not to the solution to every problem. In this case radv is fragmenting Linux and is harming it as a gaming platform. There is more reason for amdvlk to stick around than radv does,period.

[duby229]

@dubby229 I don't think you understand anything about software development. The amd driver has to exist for other oses and api's anyway, so the work has to be done regardless. If they went the route you suggested, you're asking them to implement everything twice. Every perf patch and fix has to be done twice. It's literally twice the amount of work. In the long run what they did costs less. As for radv, nice as it is I don't want it to stick around. You're telling me you'd rather have 2 people who have no obligation to do so to support your hardware instead of the people whose best interest is to do so and is in fact in the best position to do so as well? And I don't believe on the whole open source equals the best software be. It's the developers that make software good. This is the best thing for Linux. Any improvements from other oses and api's benefits Linux. dx12 patches now also helps Linux. Idk about you but I'm a lot more interested in performance software than being an open source community jerk wad. It has its place but you have to recognize its not to the solution to every problem. In this case radv is fragmenting Linux and is harming it as a gaming platform. There is more reason for amdvlk to stick around than radv does,period.

Except that radv already exists and already proved that it cost much less. It's already done, history already happened! In fact the only reason radv even exists at all is because AMD -didn't- do it first! If AMD had implemented an open source drive like radv first then every valid issue you just voiced wouldn't even exist, they -only- exist because AMD is not the ones who implemented radv!

[agd5f]

Except that radv already exists and already proved that it cost much less.

I still don't understand what you mean by this. Costs less in what way? Compared to what? Costs to AMD? Costs to the universe overall? If you are referring to costs to AMD, we've already explained that multiple times.

[smitty3268]

Couple last thoughts.

One of the reasons it's hard to say that the amdvlk driver already existed is that it's incomplete (in terms of Vega support) whereas that's not the case for the proprietary version AFAIK. So it's difficult to accept when you say it's all the same code and pre-existing. Or maybe I'm misunderstanding again.

I also think you brought this upon yourselves by being so secretive about it all. If you had publicized an actual release date a year ago for when you were going to have this out, I think radv honestly may not have ever happened. That has it's own risks, obviously, and I get that you've decided that you just won't share anything until it's done. But recognize that plan has it's own pitfalls, please, and that you play a part in them.

Finally, I'm a software developer myself and saying that it took 2 years of hard work that was all just refactoring is not reasonable. Not for a modern codebase. A legacy codebase that no one currently working on fully understands and is full of ancient hacks for various proprietary software (like fglrx) sure - not a clean and modern codebase that was written 4 years ago based around a modern API with minimal time to have hacks added in. That's precisely why I assumed there must be more going on behind the scenes. If in fact it is nothing more than a refactoring, then I have an entirely different set of concerns, and it's a set that's far less flattering towards AMD developers. That set of concerns has me deeply worried about the future of AMD linux drivers in general.