As the title says: Does Vulkan require symmetric multiprocessing and a multithreaded kernel to be practical?

A theoretically interesting question! But I doubt anyone has investigated this.

But you could try yourself:
1. Boot yer Linux with nr_cpus=1 (edit kernel command line parameters in /etc/defaults/grub and run grub-update afterwards)
2. Run some Vulkan benchmarks
3. Adjust nr_cpus= again to 2, 3, 4, etc. and re-run Vulkan benchmarks until you hit nr_cpus=x where x is the max threads your cpu can handle.
4. then you got some nice data points to check if/how much Vulkan performance scales with thread count.

For AMD cards you have Vulkan support starting from GCNv1, for NVIDIA cards Open Source driver Vulkan this is still in Beta (I think) and regarding Intel Cards I don't know whether/to what extent they support Vulkan currently.

No reason it would. But any modern-ish game using it would for sure, since those are written for 6-7 cores these days.

The reason I was asking was that mainstream web browsers have open-source backward compatibility shims for running WebGL on systems whose drivers are low-level and capable of running WebGPU. WebGL is comparable to OpenGL-ES 2 or 3 and WebGPU is comparable to Apple's Metal GPU support but can also work under Vulkan instead.

This leads to the question of whether TinyGL needs to take a back seat to a faster, low-level driver protocol such as LavaPipe (Mesa's Vulkan software renderer) if dependencies can be met.

> regarding Intel Cards I don't know whether/to what extent they
> support Vulkan currently.

According to Wikipedia, Vulkan support on Linux is there for all Intel GPUs released since 2012 (except GMA).

My status of knowledge is that the huge problem with Vulkan is that it uses some sort of binary blobs (the person who explained this to me really knows this 3D HW stuff) and uses them in a way that it is not possible to know if Byteswapping is needed or not.

Exactly he told me that GLES uses buffer descriptors to be able to do Endian Conversion but that Vulkan had no Buffer descriptors in Binary Blobs and assumes that the buffers can be transferred without any conversion. This makes it sound to me like Vulkan is no option either to OS4 or MOS. GLES on the other hand does not have this problem.

His summary was that Vulkan is useless for Big Endian architectures.

Don't know that WebGPU stuff.

Some info about Vulkan's endianness.

Re:WebGL on WebGPU
Chrome's GLES compatibility layer for Vulkan, Metal and DirectX is available at https://chromium.googlesource.com/angle/angle. Mesa also has a backward compatibility layer for LavaPipe but I don't remember what it's called.

Going from a low-level API to high-level is much harder than going the other way. OS 4.1's Warp3D Nova is a thin wrapper around SPIR-V shader API (or so I've heard) and has a GLES 2 layer that comes with it.

Of course Google wouldn't bother hosting a Warp3D Nova implementation of WebGPU but having a low-level API of some sort delivers better results on some configurations.

This thread is starting to converge with the other one about Warp3D Nova so I'll leave this as is.