Digital Foundry Article Technical Discussion [2022]

Status
Not open for further replies.
Buying i7,i9,R7,R9 cpus is very expensive.

However, it's still quite significantly cheaper than GPUs ... well except for the 12900KS. :p

And I still do like that we're seeing more of the CPU being used even at higher render resolutions. But man, I never knew about that massive hit to CPU perf with hardware GPU accelerated RT. Basically, I've never really seen that mentioned in reviews. Of course, I also don't sit here and read reviews all day either. :p

Regards,
SB
 
That is still quite ... disappointing for a new engine to be that single-core limited. So the bad performance on the current-gen consoles is mostly a CPU related problem. Maybe for that city build on the consoles a bit worse for xbox because it the playstation api was always better with CPU resources than those from the xbox. But once this is ironed out it should at least be equal in the cpu department. Also as the engine is heavily single-core bound that might still give the PS5 the full power for the GPU as the other cores are more or less idling around.
And they must definitely work on that shader caching. But that is already a problem with the last version of the engine.
What? It doesn't seem to be single-core limited at all using a modest 2700X. Seems the demo is OK with multithreading here actually, at least on a CPU with similar performance than consoles so your whole theory is completely wrong (and you forgot that XSX CPU runs actually about 10% faster).

h7Cg1ih.png


eJBMFDn.png


 
Last edited by a moderator:
What? It doesn't seem to be single-core limited at all using a modest 2700X. Seems the demo is OK with multithreading here actually, at least on a CPU with similar performance than consoles so your whole theory is completely wrong (and you forgot that XSX CPU runs actually about 10% faster).

h7Cg1ih.png


eJBMFDn.png


As far as I remember, the Xbox performance was generally a bit worse on stress situations (e.g. heavy traffic).

Also, watch or read the DF article. The engine is absolutely CPU bound in that 720p test. The rtx 3090 has almost nothing to do while a the cpu completely limits.

About nxg tests, I really don't want to write anymore about his tests. It is just not worth the time.
 
Last edited:
As far as I remember, the Xbox performance was generally a bit worse on stress situations (e.g. heavy traffic).

Also, watch or read the DF article. The engine is absolutely CPU bound in that 720p test. The rtx 3090 has almost nothing to do while a the cpu completely limits.

About nxg tests, I really don't want to write anymore about his tests. It is just worth the time.
He is using the framerate to conclude it's CPU bound without showing any CPU utilization % ! That's wrong.

At some point (like above 2700x) it's clear it's not mainly limited by the CPU, but by something else. Probably it's more what NXgamer said, memory, asset management and obviously shader compilation on PC. Overall the engine can be said to be I/O limited (not CPU, not SSD, just everything is between, API, assets setup etc).

This is on exactly those kind of bottlenecks that Cerny talked about 2 years ago in his PS5 talk.
 
Can you keep NXG trash out of the Digital Foundry topic? He is basically saying the opposite of what DF's conclusions and their interactions with Epic themselfs. Its embarrasing because Alex already addressed NXG video in another topic on b3d. These 'bottlenecks' only exist in NXG's mind. Its obvious that the console versions run poorly, dipping way below 20fps at a sub 1080p resolution with lower graphics settings. Things dont look better over there at all, worse if you consider you cant brute force anything since its low/mid range hardware. UE5 better be optimized else its the next crysis-situation.
 
Last edited:
He is using the framerate to conclude it's CPU bound without showing any CPU utilization % ! That's wrong.

At some point (like above 2700x) it's clear it's not mainly limited by the CPU, but by something else. Probably it's more what NXgamer said, memory, asset management and obviously shader compilation on PC. Overall the engine can be said to be I/O limited (not CPU, not SSD, just everything is between, API, assets setup etc).

This is on exactly those kind of bottlenecks that Cerny talked about 2 years ago in his PS5 talk.

Dude, we have literally had one of the guys who works at EPIC telling us it's currently CPU limited.
 
He is using the framerate to conclude it's CPU bound without showing any CPU utilization % ! That's wrong.
NXGamer showed almost a 100% CPU utilization on a weak ass 2700X and a significant GPU underutilization. Which is the definition of a CPU bottlneck.

Also single threaded CPU bottlneck doesn't nexessarily show up on CPU utilization, the CPU is basically setting idle while hammering down one or two threads, leaving the GPU underutilized. We've seen this dozens of times already, Crysis Remastered is the latest recent example of this.

GPU underutilization alone is a big giveaway of a significant CPU bottlneck.
 
UE5's CPU scaling is odd - running the 10900K at half speed gives a 40% performance hit. However, running the same CPU with half the available cores/threads only sees performance drop by four percent. This suggests that UE5 performance is more reliant on single-core speed as opposed to exploiting the many cores and threads in a modern PC processor.

I hope this is temporary. Given the expected widespread use of UE5 it would be a shame if it can’t take advantage of 6 cores far less the 12 and 16 of today’s CPUs. Given BVH construction can be accelerated on GPUs there should be enough parallelism to occupy a few CPU threads.
 
I hope this is temporary. Given the expected widespread use of UE5 it would be a shame if it can’t take advantage of 6 cores far less the 12 and 16 of today’s CPUs. Given BVH construction can be accelerated on GPUs there should be enough parallelism to occupy a few CPU threads.

What worry's more if that this engine doesnt even utilize a 6> core CPU and BVH construction not being accelerated on the GPU, what else is there not being so efficient? UE4 was quite the trouble-engine, lets hope UE5 isnt.
 
Still 50% better than not so bad oc rtx2070 2ghz 3.8ghz ryzen 2700 32gb ddr ;)

Ryzen 2700 isnt what i call 'similar specced to consoles'- This tech sample being CPU limited, thats going to play a huge role. Also, where the hell is a 2700 coming from? DF never tested with such CPU, why would they?
So no, not better than a similar specced PC, all things equalized.
 
This whole forum lately is a very frustrating example of what you get when someone learns a few technical terms/buzzwords (and what they mean) but doesn't bother to like, read the slides from any of the presentations on the engine, keep up with current games tech, or learn anything about game development in general. All this information is right out there. Why be a graphics enthusiast if you aren't interested in learning anything?
 
I hope this is temporary. Given the expected widespread use of UE5 it would be a shame if it can’t take advantage of 6 cores far less the 12 and 16 of today’s CPUs. Given BVH construction can be accelerated on GPUs there should be enough parallelism to occupy a few CPU threads.
I mean running the BVH creation on the CPU is pretty clever, as modern games do not utilize CPUs as much as they should. Usually the GPU is fully utilized while the CPU does almost nothing. AFAIK there's also a Vulkan command enabling BVH creation on the CPU.

This way, valueable GPU resources can be be spend doing other stuff and the CPU has some work to do. And we see HW-RT is very light on the GPU which is definately a good thing.

As I see it the only issue with that method is that the BVH creation seems to be heavily single threaded at the moment. When I am using HW-RT and look up core utilization, it's almost always one thread that is much more utilized than the others, causing the bottleneck. This is likely why Alex is seeing much better frequency rather than thread scaling. If you use Software-Lumen, that single thread is back to normal utilization similar to the other threads.
 
I mean running the BVH creation on the CPU is pretty clever, as modern games do not utilize CPUs as much as they should. Usually the GPU is fully utilized while the CPU does almost nothing. AFAIK there's also a Vulkan command enabling BVH creation on the CPU.

This way, valueable GPU resources can be be spend doing other stuff and the CPU has some work to do. And we see HW-RT is very light on the GPU which is definately a good thing.

As I see it the only issue with that method is that the BVH creation seems to be heavily single threaded at the moment. When I am using HW-RT and look up core utilization, it's almost always one thread that is much more utilized than the others, causing the bottleneck. This is likely why Alex is seeing much better frequency rather than thread scaling. If you use Software-Lumen, that single thread is back to normal utilization similar to the other threads.

Single threaded BVH won't be an issue in a few years when GPU's are at level 4/5 for RT implementation.

Then we'll be back to having 20 core CPU's that never get stretched by games.
 
Last edited:
Hardware RT has had an enormous cpu penalty from the beginning. When I got my 3080 I tested out Control and was shocked by how heavy the cpu penalty was.

https://forum.beyond3d.com/threads/dxr-performance-cpu-cost.62177/

I've had a bit of an axe to grind with the major tech review sites by really under-valuing how important cpus still are for gaming on PC. You'll always see these benchmarks that show these low to mid-range cpus are good enough because they're always testing under conditions that flatten results because they hit gpu limits. Then ray tracing, or some other new cpu heavy game comes along, and that "low value" high end cpu suddenly looks a lot better. I'm glad to start seeing more sits testing 720p high/ultra to really show how cpu performance differs, but there's still a big lack of ray tracing inclusion in benchmarks.

For ray tracing to become pervasive we need a much better software stack, or some ground-breaking new ways to store scene information that is more cpu friendly. Consoles have some advantages on the cpu-side as well as the consumer expectation that 60 or even 30 fps (yikes) is good enough. Buying i7,i9,R7,R9 cpus is very expensive.

One improvement could be like on consoles being able to stream BVH from SSD storage for static geometry and the possibility to only modify partially the BVH each frame. I don't think they use it on consoles for the Matrix Awakens demo but this is a possibility.

Exchanging CPU power against precaculate BVH for static geometry during the development of the game and Storage place and bandwidth.
 
Last edited:
@Dictator - Just watched your Crysis Steamdeck video.

Does the fixed_time_step hack to cap the frame rate in the game engine itself work on the Remaster?

I don't own the Remaster to test it.
 
Last edited:
I thoroughly approve of DF's continuing use of a Steamdeck 'window' when showing gameplay. If I watch it on my tablet then its an almost perfect emulation of the Deck's screen size.

(My tablet's screen's miles better than the Deck's though)
 
Status
Not open for further replies.
Back
Top