Whether this is a win is an difficult question. Rend3 recently put in meshlets, and performance got worse for my use case. It's a way to reduce draw work at some cost in GPU memory. But in a metaverse application, where you have user-created content, you have less instancing, and tend to run out of GPU memory before running out of rendering power.
Like mipmapping, trying to do level of detail at the GPU level only results in less rendering load, not less GPU memory consumption.
There's the question of whether you want to do occlusion culling down at that level. Yes, it cuts GPU load way down when you're in a windowless room. Then go outside and the load goes way up. If you have windows in your buildings, the occlusion culling doesn't help as much. This trick improves average GPU load for a scene, but not worst-case GPU load, which is what matters for playability. When I tried this on an older GPU with slow compute shaders, the frame rate got worse by a factor of 3, and the GPU memory consumption increased.
If you want to do occlusion culling, there's an argument of doing it by pre-computing occluded zones for a level. Unreal Engine does that sort of thing. Analyze once at build time, not once per frame.
That's a problem with pushing work down to the GPU level. You have to do it on every frame, which may be a lose.
Like mipmapping, trying to do level of detail at the GPU level only results in less rendering load, not less GPU memory consumption.
Though on Apple’s ARM devices (and consoles) memory is shared between the CPU and GPU. I am unsure if making some asset available to the GPU to render (e.g. a texture) requires making an extra copy in ram just for the GPU, but if it is not required and you can just have one copy, then shouldn’t doing LODs GPU vs CPU require roughly the same amount of memory?
the modern graphics API landscape is a disaster. they killed opengl es, they basically killed opengl. Apple is trying to lock everyone in with metal, khronos group is trying to get everyone to move to vulkan, microsoft is doing the same with d3d12. The only people winning here are the major engines and AAA studios who have the scale to deal with all the platform complexity and benefit from it because it creates a moat from competitors. There's an argument for regulation here because the market is dysfunctional but I don't think we'll ever see the day where politicians understand complex technology issues enough to fix it.
You can use Vulkan via MoltenVk, personally I take Metal over Vulkan any day though (the Metal API is a lot more ergonomic - dare I say 'enjoyable' - than Vulkan).
I don't think a missing Vulkan driver is the big obstacle here, Unreal Engine supports Metal since some time - the Intel laptop graphics hardware was just too slow, thus games only got released on iPhones and iPads. Now that Apple Silicon macs have a reasonably fast GPU, maybe we'll finally see some releases?
Also, a future viable route could be via Asahi Linux and Wine/Proton, but thats a different can of worms.
There are definitely similarities if you zoom out far enough. The object shader (task shader in Vulkan) basically maps to the tess control shader / hull shader, and the mesh shader maps to the tess eval / domain shader.
One big difference is that tessellation is fixed function and doesn't allow you to control the topology / primitive connectivity within each patch.
Another big difference is that the mesh shader runs as a workgroup, which allows things like parallel geometry decompression where all threads of a mesh shader workgroup collaborate in the decompression.
[+] [-] Animats|3 years ago|reply
There's the question of whether you want to do occlusion culling down at that level. Yes, it cuts GPU load way down when you're in a windowless room. Then go outside and the load goes way up. If you have windows in your buildings, the occlusion culling doesn't help as much. This trick improves average GPU load for a scene, but not worst-case GPU load, which is what matters for playability. When I tried this on an older GPU with slow compute shaders, the frame rate got worse by a factor of 3, and the GPU memory consumption increased.
If you want to do occlusion culling, there's an argument of doing it by pre-computing occluded zones for a level. Unreal Engine does that sort of thing. Analyze once at build time, not once per frame.
That's a problem with pushing work down to the GPU level. You have to do it on every frame, which may be a lose.
[+] [-] Pulcinella|3 years ago|reply
Though on Apple’s ARM devices (and consoles) memory is shared between the CPU and GPU. I am unsure if making some asset available to the GPU to render (e.g. a texture) requires making an extra copy in ram just for the GPU, but if it is not required and you can just have one copy, then shouldn’t doing LODs GPU vs CPU require roughly the same amount of memory?
[+] [-] apatheticonion|3 years ago|reply
[+] [-] soup10|3 years ago|reply
[+] [-] flohofwoe|3 years ago|reply
[+] [-] MrBuddyCasino|3 years ago|reply
Also, a future viable route could be via Asahi Linux and Wine/Proton, but thats a different can of worms.
[+] [-] pjmlp|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] watersb|3 years ago|reply
[+] [-] atq2119|3 years ago|reply
One big difference is that tessellation is fixed function and doesn't allow you to control the topology / primitive connectivity within each patch.
Another big difference is that the mesh shader runs as a workgroup, which allows things like parallel geometry decompression where all threads of a mesh shader workgroup collaborate in the decompression.
[+] [-] SG-|3 years ago|reply