Metal 4 backend?

[AmelieHeinrich]

Nice work on the 5.6 release!

Currently Jolt uses Metal 3. I was wondering if Jorrit (and the community using Jolt) would be interested in a Metal 4 backend? Main benefits would be that it's now the prioritized API by Apple, sync model maps better to D3D12/Vulkan, so it would be easier to extend in the future.
I can draft up a PR in a few days if interested.

[jrouwe]

Hello, thanks for the offer!

I think Metal 4 is still fairly new and from what I read only supported on macOS/iOS 26 or higher (2025). I think it's a bit too recent to stop supporting Metal 3.

Do you think there will be any benefit in terms of performance? Do you see any problems with the current implementation that could be 'fixed' with this?

[AmelieHeinrich]

This wouldn't be a replacement for Metal 3, it would be a new backend for those on OS 26+. Of course Metal 3 for now is a lot more stable and supports more devices but I reckon it would be nice to have early so that when Intel based machines do die and 26+ starts becoming standard, at least the code will be there.

Performance wise you probably would not notice a difference, it is more of a future-proof thing, things like a better sync model, better shader tools with MTL4Compiler, and also the fact that feature wise, Metal 4 is now the priority for Apple.

Figured it's nice to have regardless, up to you if you are interested.

[jrouwe]

Ok, the compute backend is still really early day at the moment and it is already tricky enough to get things working across DX12, Vulkan, Metal and a C++ fallback path. I still have to add support for e.g. sampling a texture across these platforms. Having an extra backend makes refactors more complicated, so I think that for now it is best for me to stick to Metal 3. I'll let you know when I'm ready for Metal 4!

[AmelieHeinrich]

Fair enough!
Is there a public roadmap for the compute backend? I'd be glad to contribute to any backends or help out with any API related stuff if needed. Regardless, happy to see GPU coming to Jolt.

[jrouwe]

There have been asks for WebGPU which would be nice to add. I think a problem there is that mapping/unmapping a buffer is async and I have troubles seeing how that could work (this may work well in JavaScript, but in a linear C++ program I don't see how you can make that work). Another problem was to cross compile a HLSL shader.

The other thing that comes to mind is an API to work with 2D/3D textures. The hair currently does a trilinear blend in code to get the average velocity of the hair at a hair vertex:

JoltPhysics/Jolt/Shaders/HairIntegrate.h

Lines 21 to 35 in d8f2c99

	// Get average velocity at the vertex position (trilinear sample)
	float3 velocity;
	uint3 stride = cGridStride;
	uint adr_000 = GridIndexToBufferIndex(index);
	uint adr_100 = adr_000 + 1;
	uint adr_010 = adr_000 + stride.y;
	uint adr_110 = adr_010 + 1;
	velocity = gVelocityAndDensity[adr_000].xyz * ( a.x * a.y * a.z);
	velocity += gVelocityAndDensity[adr_100].xyz * (ma.x * a.y * a.z);
	velocity += gVelocityAndDensity[adr_010].xyz * ( a.x * ma.y * a.z);
	velocity += gVelocityAndDensity[adr_110].xyz * (ma.x * ma.y * a.z);
	velocity += gVelocityAndDensity[adr_000 + stride.z].xyz * ( a.x * a.y * ma.z);
	velocity += gVelocityAndDensity[adr_100 + stride.z].xyz * (ma.x * a.y * ma.z);
	velocity += gVelocityAndDensity[adr_010 + stride.z].xyz * ( a.x * ma.y * ma.z);
	velocity += gVelocityAndDensity[adr_110 + stride.z].xyz * (ma.x * ma.y * ma.z);

which could by done by a sampler instead. Another use case for it would be to paint hair simulation properties in a 2D texture and add UVs to the hair mesh for better control over the simulation.

We'd need an API to create a texture buffer of type float1 .. float4 (more types later). The ability to optionally initialize data on CPU for constant data. Ability to bind the buffers to the compute queue. Macros to work with the samplers in the shaders that compile to the correct construct on all platforms with the ability to read/write data.