Lavapipe CPU-Based Vulkan Driver Implements Ray-Tracing Pipelines

[phoronix]

Phoronix: Lavapipe CPU-Based Vulkan Driver Implements Ray-Tracing Pipelines

Mesa's Lavapipe driver as a software (CPU-based) implementation of the Vulkan API has now implemented support for ray-tracing pipelines...

https://www.phoronix.com/news/Lavapipe-RT-Pipelines-Mesa-24.1

[Mitch]

My question is totally academic and beyond the use-case of the CPU solution, but I can't help wonder how many CPU cores and/or what clockspeed they'd have to run to get GPU-levels of performance using this solution. I imagine it might be in the hundreds or thousands of cores

[rabcor]

This is totally academic and beyond the used case of the CPU solution, but I can't help wonder how many CPU cores and/or what clockspeed they'd have to run to get GPU-levels of performance using this solution. I imagine it might be in the hundreds or thousands of cores

we say that now, but we don't know what the future holds for cpus.

Also how do I try this? I wanna see if i can even run vkcube on lavapipe lol

Edit:
The answer to my previous question is installung vulkan-swrast and using this setting:

VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json:/usr/share/vulkan/icd.d/lvp_icd.i686.json  ​

So

VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json mangohud vkcube

And it works, although for some reason mangohud thinks it's llvmpipe (which is weird, cuz llvmpipe is for opengl, not vulkan)
image.png

Now for the big questions, but can it run Crysis?!:
swrast cries.jpg
Yes.

I absolutely cannot believe I am actually saying this...

But yes, the software renderer can run crysis, even if it's at lowest settings, 800x500, and at a shitty 10-20fps, it is almost playable, it would be if every few seconds it didn't lock up for seconds to minutes at a time (maybe compiling vulkan shaders?). But also take a look at my cpu utilization! It's so low!

It's too bad it didn't play mpv (missing codec support no doubt).

I don't really know what software renderers even exist for since pcs all come with gpus now but damn this is impressive. (VM's maybe? this could be a powerful tool in something like qemu, and maybe rendering videos in qubesos which disable hwaccel for it's vms wouldn't suck if we could just use this. Yeah i see a use for this then after all)

I decided to try some other games. Getting d8vk to work was a pain to figure out for morrowind (proton-ge shipping with it out of the box is a bald faced lie! I mean I can see it in their source, but that PROTON_USE_D8VK option did jack shit.)

Oxygen Not Included, OpenMW, Postal 2: Failed to launch, because Zink doesn't seem to work with lavapipe (sadness)
Morrowind: Perfectly playable 30fps in exteriors and 40-60 in interiors at 1024x768. Water shader looked funky tho.
Dark Souls Prepare To Die Edition: 30fps in menus, refused to play because framerate was too low for online play (1fps) on 1440p; tried 800x450, didn't work out that much better. Had same lockup/freeze problems as crysis on the menu to load saves.
VTMB: 60fps in menus but then it crashes. If I was really fast pressing that new game button, it froze instead on the loading screen.

I am on a ryzen 6900HX, it's a laptop cpu

[uid313]

This is totally academic and beyond the use-case of the CPU solution, but I can't help wonder how many CPU cores and/or what clockspeed they'd have to run to get GPU-levels of performance using this solution. I imagine it might be in the hundreds or thousands of cores

Nvidia GeForce GTX 40 series have from 2560 CUDA cores up to 16384 CUDA cores.
So I don't know, it might need more than just a few hundreds cores.

Intel have made a Xeon with lots of E-cores and no P-cores, so that one has many cores, but its meant for servers, but it would be interesting if they added even more E-cores to it. It would also be interesting if Intel made something like Larrabee again. I remember there was a company called Rapport who designed a Kilocore CPU manufactured by IBM that had 1024 cores.

[byteabit]

I did not test any games because I did not have time to wait for a frame to render.

This statement is so funny.

My guess is that with advanced CPUs in the future this can help debugging code, to make sure some defined work has the same output as the GPU. Or maybe it can help the GPU in some case, when the CPU is not fully utilized and have room, but is not meant to run full RayTracing on its own in production. I assume with optimizations, including modern SIMD like AVX-512, this will become something usable.

[aviallon]

This statement is so funny.

My guess is that with advanced CPUs in the future this can help debugging code, to make sure some defined work has the same output as the GPU. Or maybe it can help the GPU in some case, when the CPU is not fully utilized and have room, but is not meant to run full RayTracing on its own in production. I assume with optimizations, including modern SIMD like AVX-512, this will become something usable.

I'm pretty sure that on a dual socket AMD Epyc board, with 256 cores and 512 hardware threads, this might work.
You could probably build mesa with some specific compiler flags (and perhaps PGO) and tune the kernel a bit, just to get a few more FPS.
LTT actually did play Doom Eternal on a Threadripper some time ago, and it was **playable**.

[byteabit]

this might work.

For games, it does not need to calculate RayTracing on its own, just support the GPU when it has some time left. So this is an excellent use case for when its GPU bottlenecked, so that the CPU has to wait for the GPU. Or when the game does not utilize all CPU cores otherwise. I mean I am talking about CPUs in most end users PCs.

For Nvidia this is probably less interesting, but for AMD this can be a good buff, even from Intel CPUs. Maybe a new driver functionality that boosts performance if you have a certain AMD CPU and GPU combination? Not sure if there is some hidden potential.

[Daktyl198]

I did not test any games because I did not have time to wait for a frame to render.

This is somehow the funniest thing I have seen all week. 10/10 project, super interesting even if it's useless. And thanks for the laugh.

[kpedersen]

10/10 project, super interesting even if it's useless.

It may be useful to test rendering issues against a "reference implementation" to eliminate potential quirky hardware. I do this a fair amount for OpenGL / LLVMpipe.

However in this case, certainly a frame draw skip might be useful or it would be a chore just to get to the point of interest within the program!

[dragon321]

This is totally academic and beyond the use-case of the CPU solution, but I can't help wonder how many CPU cores and/or what clockspeed they'd have to run to get GPU-levels of performance using this solution. I imagine it might be in the hundreds or thousands of cores

Nope, think about continuous integration where you often don't have runners with GPU and no way to automatically test your Vulkan code, unless you have some software implementation which is exactly what lavapipe does. It's also helps in development because having another Vulkan driver to check if bugs are not caused by some bugs in your primary GPU drivers is pretty helpful.