AMD Developers Looking At GNU C Library Platform Optimizations For Zen

[TemplarGR]

I really don't get the "spoiled" mentality. Contributions are welcome, but it doesn't mean that's what you exclusively rely on. It is not only in the interest of amd but also in the interest of the product's developers that it runs optimally across all hardware.

I have several friends working in AAA game studios, and that's basically their rationale for not optimizing for radeon - "nvidia does our job for us and gives us trinkets, and gives us nothing"...

Yeah, that is why it is best to pirate every single Nvidia sponsored game. I find it fair and just, Nvidia has already paid for the product, why should i?

[Space Heater]

They have done tremendously worse, deliberately I might add, and got away with it more or less unscathed, that wouldn't be outrageous against their track record, it would be banal and overly expected.

Please give concrete examples of this happening in Linux or glibc. Intel has certainly done anti-competitive things, but to my knowledge that has primarily been in software that they control, for example with their proprietary compiler icc. However I haven't seen them attempt this in major open source projects, much less get away with it.

[ddriver]

just imagine the outrage if Intel added some optimizations for AVX2 that caused a *regression* on AMD systems.

They have done tremendously worse, deliberately I might add, and got away with it more or less unscathed, that wouldn't be outrageous against their track record, it would be banal and overly expected.

[ddriver]

is this because Zen 1 can only do AVX2 back packing together two 128bit operations to achieve a 256bit AVX2 calc?

i.e. flipping this on by default for AMD architectures willgreatly benefit Zen2, but might actually slow down Zen1.

It will benefit both, but more so zen 2 obviously. Even at half the theoretical simd throughput, zen 1 can still hide most of the extra latency by buffering and saturating the pipeline. Intel's slight advantage came mostly from the better versatility of their simd units than their 256bit width. There are many variables and arbitrariness tho, depending on how many cores crunch numbers, how much memory bandwidth you have at your disposal and the overall memory access to processing ratio, and in intel's case - how much the cpu needs to throttle down to avoid burning out during heavy vector processing.

[Space Heater]

2. When AMD wanted to get DC, which is now known as DAL, mainlined, they were held up for months because their working implementation was not generic enough. The maintainers correctly pointed out that their code was highly specific to their drivers with many abstractions which might hold back a wider adoption by other drivers and was in sharp contrast to the general coding style.

You are comparing Linux kernel policies that forbid drivers from having a hardware abstraction layer (in the case of AMD's DC) and the policies of glibc maintainers regarding CPU optimizations. They really aren't directly comparable.

Interestingly, this was no issue for Intel in this instance.

Can you show where Intel's Linux graphics team is implementing a HAL upstream, and the maintainers are turning a blind eye to it? Glibc and the kernel are clearly separate projects, so I don't know why you are acting as if Intel is getting special treatment.

Any maintainer could've asked them to implement a generic CPU capability detection. That obviously didn't happen.

My understanding is that the glibc maintainers expect that whoever implements a given set of optimizations also tests and supports them long term. It wouldn't be reasonable to expect Intel to verify that all of their optimizations for their processors also work 100% perfectly for AMD, just imagine the outrage if Intel added some optimizations for AVX2 that caused a *regression* on AMD systems. Similarly, it wouldn't be fair to expect AMD to test and support optimizations intended for Zen on Intel processors. I don't see this as a double-standard or an underhanded move at all, it's pretty normal.

[Jedibeeftrix]

AVX2 is 256bit. The size of the actual physical registers is irrelevant and completely transparent from the perspective of a software developer. It is not a concern how the underlying uarch handles the issued instructions, even zen 1 supports avx2 perfectly fine, even if the instructions take more cycles to complete.

is this because Zen 1 can only do AVX2 back packing together two 128bit operations to achieve a 256bit AVX2 calc?

i.e. flipping this on by default for AMD architectures willgreatly benefit Zen2, but might actually slow down Zen1.

[agd5f]

I would argue that Intel is more of the exception than the rule. It's nice that they have the resources to spend on all of these areas, but they are more of an exception due to their sheer size. Consider all of the other hw companies contributing to various open source projects. It should be noted that AMD or AMD funded work is already in the top contributions to many of these projects.

[Volta]

jabl
Furthermore, it would be great marketing with such results from the start.

[jabl]

Good to see AMD improving core libraries for their hw. Seems strange they haven't bothered before considering they're spending several hundreds of $millions to develop their next generation microarchitecture, giving a performance boost of, what, 10-20% (?) compared to the previous generation, but they can't afford to keep a few engineers on staff to make sure critical core infrastructure like Linux kernel, glibc, gcc, clang, openblas etc. work optimally on their HW which would give a similar performance boost for many applications.

[Volta]

More like AMD finally has a fucking dollar to spend. What a stupid reply.

They were on the verge of bankruptcy and you want them to improve software? Your guidance would have killed them 2 years ago.

If mesa drivers are more profitable than optimizing their CPUs then you're right. But guess what? No, you're not.