HWRT is in there. It can always be used by a dev that thinks its worth it.
Unreal Engine 5, [UE5 Developer Availability 2022-04-05]
- Thread starter mpg1
- Start date
HWRT is in there. It can always be used by a dev that thinks its worth it.
That's not my point.
The point is that the software RT path is going to be the path optimized for 60 FPS on consoles and lower end RTX GPUs (high scalability setting). So if you prefer 60 fps over 30 fps with better graphics (which is almost everyone in this day and age), then your RT cores / Ray accelerators are basically idling and wasting die space which is not something such a modern engine should do. And again, Metro Exodus Enhanced Edition proves that superb RTGI using HW-RT is possible on a tight 16.6ms budget even on consoles.
I really don't know why they chose to do this. High scalability already runs quite well with HW-RT enabled, so IDK why they are getting rid of HW-RT in that mode instead of tweaking it further.
Subtlesnake
Regular
Just because the RT accelerators are not being used doesn't mean that performance will be worse overall, since the RT units only accelerate part of the pipeline. Software developers should care about optimising the ms needed to perform a given algorithm, not optimising "die space".
Subtlesnake
Regular
Epic do make use of hardware ray tracing in the 30 FPS mode. And Epic's own Matrix demo relied heavily on it.
His point isn't about performance suffering but part of the hardware going unused where it could be applied for better graphics.
Huh? Dampf is making a point about Epic's choices, not MS/Sony's. There's no complaint about the inclusion of HWRT. Quite the converse, if the hardware is in there, does it not make sense to maximise the available hardware? If it's not being used, it's idle silicon.
The only logical counterargument to Dampf is an explanation how the HWRT capabilities of the consoles will still be used in UE5 games running RT in software mode. If the hardware sits idle in games, his point is valid.
I ment that if EPIC's/stuidos choice is to go the 60fps way thats not the hardware/console/IHV etc fault. I sure hope the RT hw isnt going to sit idle in so many games. Studios should adapt to the hardware thats there i think. Which they probably end up doing anyway.
Subtlesnake
Regular
Well, he said in his original post that: "console gamers will have their RT cores and Ray accelerators idling instead of contributing to performance like they should".
Does Lumen's GI solution look noticeably worse than the GI solution used in Metro Exodus? I feel that this needs to be demonstrated rather than assumed. And again, I don't see how die space is relevant. What matters is performance vs. quality. The fact a particular algorithm leaves a given GPU resource idling shouldn't be a relevant factor in and of itself. And as I understand it, GPU resources are left idling all the time and part of the difficulty in optimising ray tracing is precisely making sure that work is scheduled efficiently so the GPU is kept occupied.
Last edited:
Okay, so that we are all on the same page, I will enlighten you about my little outrage yesterday!
First, Epic is currently working to get Lumen running at 60 FPS on the consoles.
This high scalability mode will be certainly the mode that is chosed most by players and RTX/RDNA2 PC players with console level performance (2070 Super and below) as I'm sure many of you know 60 fps is the prefered way to play.
Previously, I thought that mode would be using Hardware Raytracing as well, specifically optimized for a tighter frame budget. This makes sense, if you're running UE5 and turn scalability to high, it will still make use of Hardware Raytracing.
However, now Epic released this Siggraph presentation about Lumen: http://advances.realtimerendering.com/s2022/SIGGRAPH2022-Advances-Lumen-Wright et al.pdf
On Page 133 they actually state which path they are going to use for that high scalability mode in the future:
As you can see, they are planning to use Software Raytracing for that high scalability mode, which renders HW-RT useless for the vast majority of gamers, as I've stated above, most gamers will prefer 60 fps over 30.
Of course the 30 fps "Epic" mode is still going to use HW-RT as demonstrated by the Matrix Demo, but lets be frank that is not the mode players are going to use if a 60 FPS mode is available. That is why the RT hardware in many upcoming games (if not most, as so many developers switched to UE5 and got rid of their own engines because of Lumen and Nanite) will be idling and not only on consoles, PCs too as many people only have RTX/RDNA2 GPUs with below 2070 Super level of performance so they are going to use high scalability which disables HW-RT.
Why is this a problem? Because it leaves super powerful hardware unused. The goal of an engine should be to squeeze every piece of silicon out of a GPU, that is why Nintendo games on older hardware still look great. Avatar: Frontiers of Pandora will actually do this, they are using a Software approach for older hardware and then use HW-RT faster performance (yes, this means their SW-RT solution will be triangle based so I am curious how this will run without HW-RT). Metro Exodus Enhanced Edition makes full usw of Hardware Raytracing, their incredible RTGI solution runs at 60 fps on consoles. Why can't Epic? Going back to UE4, they were always the ones destroying RT performance bad for little benefits, especially compared to other solutions like in Control, Metro, Marvel and many more.
If you really read behind the lines, Epic is really not that keen about HW-Raytracing in general. They handle it as way for better lighting and reflections, specifically for Archiv projects, but it's clear they want you to use the software path for actual games. The Matrix Demo is the only demo making use of HW-RT, while there's two already for Software RT "Lumen in the Land of Nanite + Valley of the Ancients". And HW-RT is disabled by default EVEN on compatible hardware. It seems like their HW-RT solution is bottlenecked hard as soon as scenes have a ton of overlapping meshes (which is basically any video game with rocks, foliage etc)
To be honest, I wouldn't be bothered so much by this if Epic didn't have such a monopoly right now. But nearly every game developers switches to UE5 (even CDPR) so that's the way it's going to be for future games.
First, Epic is currently working to get Lumen running at 60 FPS on the consoles.
This high scalability mode will be certainly the mode that is chosed most by players and RTX/RDNA2 PC players with console level performance (2070 Super and below) as I'm sure many of you know 60 fps is the prefered way to play.
Previously, I thought that mode would be using Hardware Raytracing as well, specifically optimized for a tighter frame budget. This makes sense, if you're running UE5 and turn scalability to high, it will still make use of Hardware Raytracing.
However, now Epic released this Siggraph presentation about Lumen: http://advances.realtimerendering.com/s2022/SIGGRAPH2022-Advances-Lumen-Wright et al.pdf
On Page 133 they actually state which path they are going to use for that high scalability mode in the future:
As you can see, they are planning to use Software Raytracing for that high scalability mode, which renders HW-RT useless for the vast majority of gamers, as I've stated above, most gamers will prefer 60 fps over 30.
Of course the 30 fps "Epic" mode is still going to use HW-RT as demonstrated by the Matrix Demo, but lets be frank that is not the mode players are going to use if a 60 FPS mode is available. That is why the RT hardware in many upcoming games (if not most, as so many developers switched to UE5 and got rid of their own engines because of Lumen and Nanite) will be idling and not only on consoles, PCs too as many people only have RTX/RDNA2 GPUs with below 2070 Super level of performance so they are going to use high scalability which disables HW-RT.
Why is this a problem? Because it leaves super powerful hardware unused. The goal of an engine should be to squeeze every piece of silicon out of a GPU, that is why Nintendo games on older hardware still look great. Avatar: Frontiers of Pandora will actually do this, they are using a Software approach for older hardware and then use HW-RT faster performance (yes, this means their SW-RT solution will be triangle based so I am curious how this will run without HW-RT). Metro Exodus Enhanced Edition makes full usw of Hardware Raytracing, their incredible RTGI solution runs at 60 fps on consoles. Why can't Epic? Going back to UE4, they were always the ones destroying RT performance bad for little benefits, especially compared to other solutions like in Control, Metro, Marvel and many more.
If you really read behind the lines, Epic is really not that keen about HW-Raytracing in general. They handle it as way for better lighting and reflections, specifically for Archiv projects, but it's clear they want you to use the software path for actual games. The Matrix Demo is the only demo making use of HW-RT, while there's two already for Software RT "Lumen in the Land of Nanite + Valley of the Ancients". And HW-RT is disabled by default EVEN on compatible hardware. It seems like their HW-RT solution is bottlenecked hard as soon as scenes have a ton of overlapping meshes (which is basically any video game with rocks, foliage etc)
To be honest, I wouldn't be bothered so much by this if Epic didn't have such a monopoly right now. But nearly every game developers switches to UE5 (even CDPR) so that's the way it's going to be for future games.
They probably can, or should be able to with their expertise and resources. As to why, no idea as there is not much reason to avoid practically all hardware available since atleast 2020.
I think the big question is why software RT is faster than hardware RT. That's extremely counterintuitive and defeats the purpose of implementing acceleration in hardware!
They aren’t like, tracing against triangles in bvh trees (the thing the hardware accelerates) using software. The “software rt” path is marching against sdf representations.
I think in this case it is because they are not doing the same thing and because console HWRT is "weak". Software RT is not tracing into the same complexity (or with the same precision) as the HWRT path. If they were equal for quality, I think we can imagine that HWRT would be perhaps the winning performance thing there.
On console the things actually accelerated are only a small part of total frame , so HWRT with its greater complexity is not seeing as awesome speed ups as it otherwise might on other hardware (Intel/NV).
That's exactly what I think too. High scalability mode with similar(!) quality settings to Software Raytracing, but hardware accelerated could achieve that sweet 60 fps target on consoles and low end GPUs.
But that's not what they are planning to do, instead they plan to get rid of HW-RT in lower scalability settings below Epic and replace it with SW-RT to reach 60 fps on lower end RTX/RDNA2 GPUs and consoles. And that is the issue I am seeing here.
Last edited:
The one area that HW will have trouble with regardless of scalability settings are massive overlapping assets close to the camera... traversing all of the various overlapped geometry instances will run poorly in HWRT in comparison to the lower accuracy SWRT solution. I am not sure if that means they need some sort of merging to occur for that to work better with HWRT or something, but it is a thing to also consider.
I am not exactly sure how common that type of level generation will end up being though. Just overlapping dozens of meshes in a kitbash way is interesting for a demo, for sure, but would a game world really be made that way? Especially for terrain? (Instead of some sort of procedural, heighmap, etc etc thing) I am not exactly sure...
I suspect nonexistent — if nothing else, it’s just not very hard to post process all your scenes and remove overlaps (if a reader works at an aaa studio that doesn’t know how, feel free to dm me a job offer.) however, dense overlaps aren’t the only thing that scales badly for bvh traces — basically anything dense and close together (from the perspective of the ray) does. (I don’t think that’s the reason they prefer sdfs for the low end though.)
Last edited:
Are you mad that they aren't using HW rasterization for nanite either? Or that the tessellation units have sit idle in 90% of ps4/one generation games?
No engine keeps all HW parts occupied at all times. In fact, its probably not even possible to do that without hitting some other bottleneck.
If HWRT could help accelerate lumen at the 60fps quality settings, they sure as hell would be using it. If they are recomending against it, is because the overhead is actually slowing the render down rather than speeding it up.
In fact, I suppose on HW such as PS5, where the clock is variable, not using every single part of the sillicon might help keep the clock at its max speed, thus allowing the actually useful parts to run as fast as possible.
No engine keeps all HW parts occupied at all times. In fact, its probably not even possible to do that without hitting some other bottleneck.
If HWRT could help accelerate lumen at the 60fps quality settings, they sure as hell would be using it. If they are recomending against it, is because the overhead is actually slowing the render down rather than speeding it up.
In fact, I suppose on HW such as PS5, where the clock is variable, not using every single part of the sillicon might help keep the clock at its max speed, thus allowing the actually useful parts to run as fast as possible.
Last edited:
DavidGraham
Veteran
I think PC games will implement both options: software RT for standard quality for low/medium end hardware to reach 60fps, and hardware RT and maximum quality for powerful hardware to render using their fullest of potential, the 4090 can easily push past 90fps even in hardware mode. In many UE5 demos available online, the hardware RT actually delivers far better image quality than the software mode, at the same fps or even faster fps.
Consoles too will probably have games with the two modes: 30fps max quality and 60fps standard quality.
Similar threads
- Locked
