David Airlie Tries DOOM On CPU-Based Lavapipe Vulkan

[phoronix]

Phoronix: David Airlie Tries DOOM On CPU-Based Lavapipe Vulkan

Red Hat graphics driver developer David Airlie has tried running the DOOM (2016) game on the CPU-based Lavapipe Vulkan driver... It works, but isn't fast and currently requires some hacks...

https://www.phoronix.com/scan.php?page=news_item&px=Lavapipe-DOOM-Running

[coder]

It's interesting to hear how this is progressing.

much of the overhead is due to BPTC texture loading that Airlie hasn't yet optimized for Lavapipe

I wonder if there's a good, generic way to profile JIT code. operf certainly hasn't done me much good, but then I haven't really looked into it, either.

those dreaming of real and legitimate gaming with Lavapipe on the CPU with modern CPUs are still living on a fantasy island.

An order of magnitude less than real GPU performance probably isn't unreasonable to hope for, though it probably depends somewhat on how much the app leans on HW features vs. generic shader code.

[torsionbar28]

64-core EPYC is the solution.

[commodore256]

If we can get graphene CPUs and they you could go 1,000x times faster, (like they say) that's 166fps.

[Etherman]

Cool, up to 10 fpm of pure performane.

[coder]

64-core EPYC is the solution.

Last time Michael tried this on a high-core-count machine, I think he found that performance maxed out at like 16 cores.

airlied 's blog entry doesn't specify what CPU this latest test used. I didn't check to see if his earlier entries mentioned what HW platform he's using.

[Laughing1]

If we can get graphene CPUs and they you could go 1,000x times faster, (like they say) that's 166fps.

How about graphene GPUs?

[airlied]

It's interesting to hear how this is progressing.


I wonder if there's a good, generic way to profile JIT code. operf certainly hasn't done me much good, but then I haven't really looked into it, either.


An order of magnitude less than real GPU performance probably isn't unreasonable to hope for, though it probably depends somewhat on how much the app leans on HW features vs. generic shader code.

Our BPTC decompression isn't JIT yet, it is also very naive and done at runtime, I'm considering up front decompression, but it's a large memory usage + bw increase vs a large CPU usage, it might be possible to JIT the BPTC decompressor and get things a bit better that way.

As for profiling, llvm has perf integration now, I can at least see in perf report what assembly is eating up CPU, though mapping that back to fragment shader source is always tricky.

Dave.

[airlied]

Last time Michael tried this on a high-core-count machine, I think he found that performance maxed out at like 16 cores.

airlied 's blog entry doesn't specify what CPU this latest test used. I didn't check to see if his earlier entries mentioned what HW platform he's using.

Ryzen 7 1800x

Dave.

[tildearrow]

Hey, at least it runs. I've heard that normally a software implementation of a graphics API would crash on a very intensive game...

8266752-core Fugaku is the solution.

Fixed...

Cool, up to 10 fpm of pure performane.

I remember Xonotic has an "spf" (seconds per frame) metric if your frame rate goes beyond 1 FPS...