Comparative consideration of DirectX 12 in games *spawn

That's very sad to read. I was expecting for more advancements since the introduction of DX12
The point of the example was it's a pretty clear case where IHVs defaulted to "this is not the way to do it, just do the simple thing the hardware is designed for" and missed the forest for the trees.
For the most part various shades of "just use bigger triangles", as with the other past examples.
You kinda can't blame the IHVs really, Microsoft outlined a specific path for the geometry problem in DX12 and DX12U, which ultimately resulted in the creation of Mesh Shaders, which arguably comes close to the results of Nanite without the crippling Ray Tracing performance of Nanite and the limitations of supporting dynamic meshes. Maybe the IHVs thought Meshlets are the more successful future than Nanite?
 
You kinda can't blame the IHVs really, Microsoft outlined a specific path for the geometry problem in DX12 and DX12U, which ultimately resulted in the creation of Mesh Shaders, which arguably comes close to the results of Nanite without the crippling Ray Tracing performance of Nanite and the limitations of supporting dynamic meshes. Maybe the IHVs thought Meshlets are the more successful future than Nanite?

Nanite isn't an API like mesh shaders. It's an implementation of a rasterizer, a streaming lod system and geometry compression that uses mesh shaders and can output primitives directly or fallback to the hardware rasterizers when it would perform better (large triangles). Meshlets are also not comparable to Nanite. They're just a standardize piece of a mesh.
 
... which ultimately resulted in the creation of Mesh Shaders, which arguably comes close to the results of Nanite without the crippling Ray Tracing performance of Nanite and the limitations of supporting dynamic meshes. Maybe the IHVs thought Meshlets are the more successful future than Nanite?
I've mentioned this before, but they are not really solving the same problems. Mesh shaders are really inspired by earlier GPU culling stuff like https://ubm-twvideo01.s3.amazonaws....ons/Wihlidal_Graham_OptimizingTheGraphics.pdf. You may recognize some of the names there... these are not disjoint efforts. Nanite goes further.

Mesh shaders do nothing for raytracing; they have the same issues as Nanite on that front. Those issues are not caused by mesh shaders or Nanite, but rather stem from the fact that current RT APIs do not have good mechanisms for streaming high poly meshes with LOD. Raytracing simply needs to evolve on the acceleration structure construction/update front before it can efficiently handle the large, high detail environments that mesh shaders/Nanite enable.
 
Last edited:
I've mentioned this before, but they are not really solving the same problems. Mesh shaders are really inspired by earlier GPU culling stuff like https://ubm-twvideo01.s3.amazonaws....ons/Wihlidal_Graham_OptimizingTheGraphics.pdf. You may recognize some of the names there... these are not disjoint efforts. Nanite goes further.

Mesh shaders do nothing for raytracing; they have the same issues as Nanite on that front. Those issues are not caused by mesh shaders or Nanite, but rather stem from the fact that current RT APIs do not have good mechanisms for streaming high poly meshes with LOD. Raytracing simply needs to evolve on the acceleration structure construction/update front before it can efficiently handle the large, high detail environments that mesh shaders/Nanite enable.
How effective is Nvidia’s DMM in practice? Is current hardware ready for an API that allows complex mesh streaming or do we need changes there too?
 
Mesh shaders do nothing for raytracing; they have the same issues as Nanite on that front. Those issues are not caused by mesh shaders or Nanite, but rather stem from the fact that current RT APIs do not have good mechanisms for streaming high poly meshes with LOD. Raytracing simply needs to evolve on the acceleration structure construction/update front before it can efficiently handle the large, high detail environments that mesh shaders/Nanite enable.
Didnt hold Remedy back to implement a fully hardware raytracing pipeline.
 
Raytracing simply needs to evolve on the acceleration structure construction/update front before it can efficiently handle the large, high detail environments that mesh shaders/Nanite enable.
That evolution seems to have gone something like - "We need ray tracing but GPUs are too slow. Okay, let's speed it up with hardware intersect tests. Yay, fast raytracing. Let's build a BVH for our scene. Oh, that's really slow. Now what..."

Was the cost of the BVH aspect underestimated? Or did they go ahead with ray intersects as Step One knowing it wouldn't be 'good enough' but thinking they had to start somewhere?
 
This is not a problem. BVH building is fast on nVidia hardware. UE5 with software raytracing runs with less than 400W on a 4090. Alan Wake 2 with hardware Raytracing needs over 500W. Obviously what Epic is doing is less efficient and unoptimized for modern GPUs.
 
That evolution seems to have gone something like - "We need ray tracing but GPUs are too slow. Okay, let's speed it up with hardware intersect tests. Yay, fast raytracing. Let's build a BVH for our scene. Oh, that's really slow. Now what..."

Was the cost of the BVH aspect underestimated? Or did they go ahead with ray intersects as Step One knowing it wouldn't be 'good enough' but thinking they had to start somewhere?

Is it slow though? BVH builds seem to run async to other graphics work (depth pass, gbuffer fill etc) in several games.

It’s probably just a function of this being RT 1.0. The first iteration of anything isn’t going to be feature complete and you’ve got to start somewhere. The fact that we have RT in games at all is a small miracle.
 
Didnt hold Remedy back to implement a fully hardware raytracing pipeline.

He didn't say it would hold ray tracing back.

He's saying that current hardware/API doesn't have the ability to construct a BVH with mesh shader/nanite levels of geometry and with an automatic LOD.

So the ray tracing doesn't benefit from the huge increase in geometry or LOD system that Nanite/Mesh shaders provide.
 
Last edited:
I understood that. But Epic has been done nearly nothing to support hardware Raytracing. Remedy has implemented it in a way that the drawbacks of the hardware and API are not a problem at all.
And yet UE5 has still the same problems. Cant use proper geometry and lod for the representation.
 
I understood that. But Epic has been done nearly nothing to support hardware Raytracing. Remedy has implemented it in a way that the drawbacks of the hardware and API are not a problem at all.
And yet UE5 has still the same problems. Cant use proper geometry and lod for the representation.

Is this the same EPIC that fully supports hardware acceleration for RT and even offers higher quality when hardware acceleration is used?
 
Epic stated they are doing extensive work right now to make Hardware Lumen work at 60fps on consoles, which means they are going to expand the acceleration of Lumen even further, this should benefit high end GPUs and make them run Hardware Lumen even faster.
 
Epic stated they are doing extensive work right now to make Hardware Lumen work at 60fps on consoles, which means they are going to expand the acceleration of Lumen even further, this should benefit high end GPUs and make them run Hardware Lumen even faster.

If they can get hardware lumen to work at 60 fps on consoles that's probably the best chance we'll see good real-time ray-traced GI on the current generation of consoles.
 
Was the cost of the BVH aspect underestimated? Or did they go ahead with ray intersects as Step One knowing it wouldn't be 'good enough' but thinking they had to start somewhere?
It was pretty well understood from the start. Since it's generally just compute it was prototyped and could run on GPUs before RT hardware even arrived, so the performance was a known quantity. The main things that have shifted over time are the complexity of the scenes that people want to make, particularly now that stuff like Nanite enables much higher complexity than was possible before. Similarly people want tons of dynamic elements now too (windy foliage, crowds, physics deformations, etc) which are very expensive to support with raytracing.

IMO in this case it wasn't something that was a big miscalculation or something, but rather the assumption that some amount of games with simpler, more static geometry could still benefit from raytracing in the mean time (and I think this has borne out). But I think pretty much everyone expected the API to need improvements on the acceleration structure side as stuff like the lack of efficient LOD mechanisms was well known from the start. There has been quite a bit of research along these lines following DXR 1.0 already, but a particularly relevant one to this thread that folks may or may not have seen:

How effective is Nvidia’s DMM in practice?
I haven't tested it personally, but it's more comparable to the new Nanite tessellation stuff than to the regular streaming and LOD things. Brian discussed a fair bit about why we can't just switch everything to tessellated/displaced meshes and we still need LOD below the level of the control mesh (which always ends up being relatively high poly itself, even in these cases) in his Nanite talk:

So yeah my hot take is that sort of tech is likely useful in the future, but it doesn't really address or negate the need for better LOD/streaming acceleration structure stuff.

Is current hardware ready for an API that allows complex mesh streaming or do we need changes there too?
Both I imagine? There's almost certainly more we can do with current hardware since so much of the BVH construction stuff is in "software" (drivers) anyways. But presumably we'll probably want more flexibility on the traversal side at some point as well which will likely require some hardware changes. I expect all this will continue to evolve over time.
 
Last edited:
Hardware ray tracing is starting to sound more like an endless pit of hardware complexity cost as time passes. Function calls/spilling, hardware assisted acceleration structure rebuild/updates, and fast/flexible traversal ?
 
Epic stated they are doing extensive work right now to make Hardware Lumen work at 60fps on consoles, which means they are going to expand the acceleration of Lumen even further, this should benefit high end GPUs and make them run Hardware Lumen even faster.
Doesnt work like that. Metro Exodus EE gets 60 FPS on consoles with proper hardware Raytracing. This is different to UE5 which barely uses hardware Raytracing. Epic will just reduce the workload. Should have been done already if this would be so easy. 4A Games only needed two years...

Going from Remedy's GI system to Pathtracing GI in Alan Wake 2 costs only ~20% performance on a Lovelace GPU while providing much better image quality. Like i said: DXR software and hardware has not held Remedy back to implement a proper hardware Raytracing pipeline while updating their engine with Mesh-Shading support. The same is true for DX12 which is not holding nVidia GPUs back. It is and was always the higher software stack which dont get optimized for modern GPUs because these consoles are so far behind.
 
Doesnt work like that. Metro Exodus EE gets 60 FPS on consoles with proper hardware Raytracing. This is different to UE5 which barely uses hardware Raytracing. Epic will just reduce the workload. Should have been done already if this would be so easy. 4A Games only needed two years...

Going from Remedy's GI system to Pathtracing GI in Alan Wake 2 costs only ~20% performance on a Lovelace GPU while providing much better image quality. Like i said: DXR software and hardware has not held Remedy back to implement a proper hardware Raytracing pipeline while updating their engine with Mesh-Shading support. The same is true for DX12 which is not holding nVidia GPUs back. It is and was always the higher software stack which dont get optimized for modern GPUs because these consoles are so far behind.
60 FPS presumably means with ray traced reflections + VSM + Nanite. On consoles, Metro Exodus EE has none of these things. (At least, I can't find any references to ray traced shadows).
 
Back
Top