Mesa's LLVMpipe Driver Begins Experimenting With AVX-512 Optimizations Ahead Of Zen 4

[phoronix]

Phoronix: Mesa's LLVMpipe Driver Begins Experimenting With AVX-512 Optimizations Ahead Of Zen 4

An independent contributor to the open-source Mesa 3D graphics project has begun eyeing AVX-512 support by the LLVMpipe software rasterizer due to AVX-512 being present with the new AMD Ryzen 7000 series "Zen 4" processors...

https://www.phoronix.com/news/Mesa-AVX-512-LLVMpipe-Start

[schmidtbag]

I agree it's a little odd that Zen 4 became the motivator, but I guess the thinking was that AVX 512 is now common enough to warrant the effort. Back when it was only available to a single vendor and effectively only server CPUs, it didn't make sense. But with 2 vendors and desktop CPU support, I can see how it becomes a little more worthwhile.

It's also not clear how much faster AVX-512 will be for LLVMpipe on AMD Zen 4 processors. For Zen 4, AVX-512 is implemented still using a 256-bit data path rather than 512-bit, but we'll see how well their AVX-512 implementation plays out soon enough.

I wouldn't be surprised if AMD's approach performs worse but still yields better performance than not having it at all. Since AVX-512 isn't [yet] commonly used, I think it was a good idea for AMD to minimize how much die space was dedicated to a feature that most people otherwise might not care about. Since this allows the chips to be produced cheaper, anyone who cares about AVX-512 can just compensate for the lower performance by having more cores. I figure a 64 core Epyc would yield similar performance to a 56 core Xeon in AVX-512 workloads.

[klokik]

AFAIR, Intel cores were significantly dropping frequency even below the base frequency, with considerable recovery latency, if AVX-512 instructions were used. Thus if Zen 4 can maintain a somewhat decent clock rate, it has a chance to surpass Intel in Instructions Per Second terms.

[Dukenukemx]

Yuzu and RPCS3 developers have expressed positivity when using AVX-512 to boost their emulators performance, so there's certainly something good to look forward to there.

[Developer12]

The article is right to point out that this makes no sense. These AMD chips already all have full GPUs integrated on the I/O die. This LLVMpipe implementation will *never* be useful on those chips.

That leaves only intel, who are in fact reducing support for AVX512. There's even less justification for AVX512 support than there was before.

[brucethemoose]

The article is right to point out that this makes no sense. These AMD chips already all have full GPUs integrated on the I/O die. This LLVMpipe implementation will *never* be useful on those chips.

That leaves only intel, who are in fact reducing support for AVX512. There's even less justification for AVX512 support than there was before.

Better performance is always good, but writing AVX512 intrinsics does seem like a lot of effort for a fallback gpu driver.

[andrei_me]

Not sure if LLVMpipe already contains optimization for newer ARM instructions, so it can run even smoother in Asahi for example

[brucethemoose]

Not sure if LLVMpipe already contains optimization for newer ARM instructions, so it can run even smoother in Asahi for example

ARMv9 seems like a particularly sensible target. There are going to be lots of ARM machine with broken drivers in the near future.

Maybe they don't have any available devs who do ARM assembly.

[arQon]

The article is right to point out that this makes no sense.

Yeah, I had to read it again to make sure I hadn't missed something.

"Since these CPUs *all* ship with an iGPU, add a bunch of redundant codepaths to the software renderer". wibble?

Next up: writing fast 16.16 fixed-point math for armv6 via SVE instructions... :P

[Raka555]

Phoronix will probably have an article about the "code rot" in LLVMpipe in a couple of years from now ...