AMD Zen 2 Improvements For LLVM Have Been Held Up For Months By Code Review

[ms178]

Once upon a time, they had an Operating System Research Center in Dresden, Germany which dealt with Kernel, compiler and other pieces in the open source software ecosystem in one central place. With talented engineers who now work elsewhere. AMD let go of that staff in 2012 as they were struggeling and they really should consider re-building such a team to boost their Linux software efforts.

[ThoreauHD]

With Intel and Nvidia doubling down on their software dev, it seems like a really poor time for AMD to be dragging ass when they have the hardware to capture server and desktop market share.

The last 6 months have been pretty poor across the board. Compiler opts are necessary on the server, but temp sensors are required for every chip they sell. And that's ignoring the gpu side, where they don't bother dropping the binary firmware until months after release. And don't even start on mobile. It's a bunch of howling monkeys throwing shit at a wall.

At some point, after hearing that X doesn't work and won't work for the next year- if ever, enterprise and consumers are going to say F that, and buy Intel. It should not be the customers job to have their own coding team to get their hardware to function.

Please wake up, Lisa. You are not selling widgets. You are selling an ecosystem. Handle your business.

[duby229]

I do agree that AMDs internal development strategy is incompatible with OSS ideals. Just look at how they release their vulkan driver or kernel drivers. They are so lucky the linux kernel is so huge, if it was smaller theyd be screwed, mucb like how basically everyone uses radv instead because AMDs vulkan driver has a fuckin terrible development model.

[agd5f]

Why are you getting mad at AMD? Michael is the one complaining. As was stated in the article, AMD provides branches and packages for just about everything so you don't have to wait for everything to get upstream. Upstream is unpredictable. Realistically, it's almost impossible to get everything upstream ahead of launch. In most cases hardware, distros, and components (like llvm, mesa, gcc, etc.) are on different schedules and none of them align. You could try and have everything ready by 6-9 months before launch, but in most cases that's not feasible. Hardware development schedules are not designed that way. You generally don't write support for something and then sit on it for 6-9 months wanting for the part to launch. Generally development goes right up until launch, so even putting out early development code much earlier is not likely to work 100% once production hw launches. You have a bit more time on the CPU side because the schedules are longer, but even those are getting compressed. You work to get a solution out to your customers for launch and you try and align with upstream as much as possible to make sure you get the changes in for the long term.

How is this incompatible with upstream? We work to ultimately get everything upstream, but the fact is very few if any customers actually want upstream. Most customers want support for a 2 year old enterprise distro or their own custom distro or some other slow moving embedded distro depending on the part, at launch. Just about every distro picks their own arbitrary kernel to use; almost no one uses LTS kernels. I suspect most hardware vendors have 1/3 to 1/2 of their engineering staff working on kernel compatibility layers and back-porting and packaging to support customers at launch. RHEL, SLE, Ubuntu LTS, Android, Chrome; they all use old kernels and other components. Even if you were able to get everything upstream 6 months ahead of time, you'd likely not align in most cases anyway. You get a solution out to customers, and you work to get everything upstream for the long term in parallel.

[Space Heater]

the fact is very few if any customers actually want upstream.

If that's the prevailing view, then it all makes sense. Upstream simply isn't given the same priority by AMD management like it is at some other companies.

I really appreciate all of the work you and your team put in to the development of the amdgpu driver, but it's disappointing to read this as someone who has bought AMD hardware and uses upstream Linux.

[wizard69]

That's a false choice. You don't need to delay a product, you start the software development earlier. Other companies manage to do this, and this hurts AMD's adoption in the server space.

Other companies have huge budgets. You need to remember that AMD barely made it to the successful state that they are in now. A huge amount of talent was laid off or left during those dark days.

aMD now has very successful products which should lead to reinvestment in all parts of the company. Hopefully we will see that with an up swing in employment and maybe a bit of reorganization. In any event we need to let AMD know that there is a need to address these basic things like compiler support.

[wizard69]

Once upon a time, they had an Operating System Research Center in Dresden, Germany which dealt with Kernel, compiler and other pieces in the open source software ecosystem in one central place. With talented engineers who now work elsewhere. AMD let go of that staff in 2012 as they were struggeling and they really should consider re-building such a team to boost their Linux software efforts.

This is the key problem, AMD fell into survival mode and lost a great deal of very good people. A good portion of Apples GPU efforts are supported by former AMD engineers. Frankly it has only been about a year or two where AMD has actually had compelling hardware and thus the income to start supporting that hardware better.

speaking of INCOME I’m not too certain that the cellar dwellers in this forum understand the importance of income. Without income AMD can’t hire developers!

[Space Heater]

Im not too certain that the cellar dwellers in this forum understand the importance of income. Without income AMD can’t hire developers!

Convincing insult, but income alone isn't sufficient to explain the behavior. They generally don't prioritize upstream development as much as others, that's independent of cash flow.

[ThoreauHD]

This is the key problem, AMD fell into survival mode and lost a great deal of very good people. A good portion of Apples GPU efforts are supported by former AMD engineers. Frankly it has only been about a year or two where AMD has actually had compelling hardware and thus the income to start supporting that hardware better.

speaking of INCOME I’m not too certain that the cellar dwellers in this forum understand the importance of income. Without income AMD can’t hire developers!

OK. You started out well, but you kinda stepped on your dick at the end. First rule of public speaking is to know your audience. And you really, really don't.

[sheepdestroyer]

very few if any customers actually want upstream. Most customers want support for a 2 year old enterprise distro

I consider myself un enthousiast in the sens that I do not run deprecated as soon as shipped distros. I use and love Fedora especially because they thrive to stay as close to upstream as possible (and I am considering Clear Linux for the same reason, added performance being a plus). Hardware support with full Intel as always been a breeze. I am planning to buy a Threadripper / Navi combo, but I do not like the idea of patching things in order to get good support. Upstreaming asap sure has great advantages compared as doing it after the fact...