Close to the start after the bridge. Much better trace there on the 4080. The L2 cache is putting in good work which makes sense. 64MB vs 6MB on the 3090.
Unreal Engine 5, [UE5 Developer Availability 2022-04-05]
- Thread starter mpg1
- Start date
Close to the start after the bridge. Much better trace there on the 4080. The L2 cache is putting in good work which makes sense. 64MB vs 6MB on the 3090.
Before we got *too* into the weeds - it's great to see folks getting some actual data but for people not familiar with low level GPU optimization, please try and avoid your initial reactions to things. It might seem crazy to see something like "this pass only uses 20% of the theoretical ALU throughput" but that's actually completely normal, and always has been for GPUs. Each pass will tend to hit different parts of the GPU harder, and there will always be a bottleneck somewhere.
Moreover bottlenecks are not as simple as "memory" vs "ALU". Even in cases where things are stuck waiting on memory, it's usually not as simple as adding more memory bandwidth. As GPU rendering becomes more complex there are more and more cases where performance is a complex function of cache hierarchies, latency hiding mechanisms, register file sizes and banking and so on. There's a reason why huge parts of these chips are devoted to register files and increasingly caches rather than just laying down more raw compute to pump those marketing numbers
So yes, it's all well and good to look at some profiles but unless you are experienced in looking at these things frequently please avoid generalizing what you're seeing to any statements about what constitutes "normal" or "efficient" use of a GPU for a given task.
Moreover bottlenecks are not as simple as "memory" vs "ALU". Even in cases where things are stuck waiting on memory, it's usually not as simple as adding more memory bandwidth. As GPU rendering becomes more complex there are more and more cases where performance is a complex function of cache hierarchies, latency hiding mechanisms, register file sizes and banking and so on. There's a reason why huge parts of these chips are devoted to register files and increasingly caches rather than just laying down more raw compute to pump those marketing numbers
So yes, it's all well and good to look at some profiles but unless you are experienced in looking at these things frequently please avoid generalizing what you're seeing to any statements about what constitutes "normal" or "efficient" use of a GPU for a given task.
You're going to hate this but... "it depends" a lot. There are a lot of factors that affect VSM performance from how much cache invalidation there is to how much non-nanite there is and so on. There's quite a lot of console variables and tools to adjust how they function for a given game, some amount of which does help you target specific budgets. The "constant time" thing is not really feasible to do in a strict sense since 1) it's not possible to perfectly predict how long something will take to render beforehand, especially for non-nanite geometry and 2) the pops you note can be pretty significant if it is not handled carefully. There are hysteresis tools though that can adjust resolution smoothly as you approach the page pool allocation size and similar. More importantly though, as VSMs try and match their resolution to the sampling resolution of the screen, they actually scale better with the primary dynamic res adjustments, unlike conventional shadow maps. Again, non-Nanite geometry is a bit of a wildcard as it's impossible to control the cost of it on the backend, but that's yet more reason to make everything Nanite.
Frenetic Pony
Veteran
The difference between "On" and "Off" is almost imperceptible beyond the glass reflections. That none of these games use hardware RT otherwise feels like a deliberate choice from Nvidia to try and juice how much "better" they are.
I appreciate that this program let Blackmyth get a bunch of PR, by all accounts it's a good game that deserves its success. But the actual "RTX On" results always seem to be underhanded yet feel desperate at the same time.
I must admit it's also becoming increasingly unclear to me what the so-called "RTX" path is doing that is different - if anything at all - than the Lumen HWRT path in some of these cases. For instance, NVIDIA's document seems to imply that the reflections are mostly just stock Lumen HWRT, with a few SER hints added and some ReSTIR stuff (which would probably not be relevant in this kind of scene): https://dlss.download.nvidia.com/uebinarypackages/Documentation/UE5+Raytracing+Guideline+v5.4.pdf
It's not entirely clear to me why someone couldn't get the same result by enabling hit lighting and high quality translucency reflections, both of which are stock Lumen options, and mentioned in the NVIDIA docs. Maybe there's some further special sauce in there, but they are kind of vague about it.
It's not entirely clear to me why someone couldn't get the same result by enabling hit lighting and high quality translucency reflections, both of which are stock Lumen options, and mentioned in the NVIDIA docs. Maybe there's some further special sauce in there, but they are kind of vague about it.
Last edited:
I must admit it's also becoming increasingly unclear to me what the so-called "RTX" path is doing that is different - if anything at all - than the Lumen HWRT path in some of these cases. For instance, NVIDIA's document seems to imply that the reflections are mostly just stock Lumen HWRT, with a few SER hints added and some ReSTIR stuff (which would probably not be relevant in this kind of scene): https://dlss.download.nvidia.com/uebinarypackages/Documentation/UE5+Raytracing+Guideline+v5.4.pdf
It's not entirely clear to me why someone couldn't get the same result by enabling hit lighting and high quality translucency reflections, both of which are stock Lumen options, and mentioned in the NVIDIA docs. Maybe there's some further special sauce in there, but they are kind of vague about it.
Hasn't Nvidia often conflated "RTX On'" with general hardware ray tracing options that are available on other platforms? Perhaps here "RTX On" does simply mean HWRT on.
DegustatoR
Legend
RTX is RT+DLSS (to be more precise any form of ML usage which Turing+ allows), always has been.
Except when it's not. Didn't bother digging deeper but Quake II RTX is RT only and advertised with RTX on/off by NVIDIA
DavidGraham
Veteran
The shiny floor, walls and water puddles show a massive difference as well.
They probably do use HW Lumen, as in the case of Avowed. Black State could be using it too.
Black Myth is using UE5.0, was translucent reflections even available in UE5.0? is ray traced caustics part of standard UE5? or ray traced particles in reflections? I am asking because it seems there is more to these games than just the standard UE5 stock stuff.
Yep, NVIDIA uses RTX interchangeably to mean Ray Tracing, DLSS, DLAA, Frame Generation, Ray Reconstruction, Reflex, RTX IO or any combination of the previous tech. It's a broad marketing term.
DegustatoR
Legend
Because it's either/or or both. A game which only use DLSS is an "RTX" game in Nvidia's marketing.
For sure. Also, neither RTXDI nor Restir GI is present in the default UE5. Additionally, both NRD denoisers and DLSS 3.5 are unlikely to be compatible with the default blurry (super low-frequency) screen-space probe sampling of Lumen for GI.
The "+" made it look like you said "RTX is both RT & DLSS"
I'm not sure it actually is UE5.0. Do we have any evidence for that besides the binary metadata? There's various plausible scenarios in which that metadata just didn't get updated/overlooked. We can possibly dig in the INIs or if the Unreal unlocker can do a cvar dump or something that would be a more reliable way to ballpark it.
That said I think Black Myth does have a few things like caustics that are modifications for sure, but I was speaking specifically to the Black State trailer.
Sure, I'm just noting that I think the bit that gets a bit silly is when they use it to advertise a feature that is just... in the game/engine and has nothing specifically to do with them. Obviously marketing will be marketing but it's crossing a bit of a line if you are implicitly taking ownership of someone else's work.
Last edited:
D
Deleted member 2197
Guest
In what context is it taking ownership of someone else's work (implicitly Epic) in this instance?
It's just the ongoing blurring of the lines between NVIDIA posting marketing that might just be equivalent to a game running on any other platform, vs cases where they have actually been involved and done more specific work and so on. To be even more stark, imagine a hypothetical case where AMD did a raytracing implementation in a game... do you not agree it would be misleading for NVIDIA to then post that on their site as RTX On/Off? The implication is that there's something special you get when running on an RTX GPU, when in reality there may be nothing.
We folks here have effectively come to the conclusion that the marketing doesn't really mean anything at this point but judging from discussions with friends I don't think that's at all the case for the general public, and I think that's very intentional.
Anyways I'll leave it as "marketing will be marketing", but I'm generally unimpressed with any company on that front. Not a huge deal, but I do wish they were a bit more clear on exactly what they have done in various games, if anything.
Last edited:
Similar threads
- Locked
