DF: Unreal Engine 5 - The Cost of Next-Gen Rendering

[crispy4000]

 

[Mr.Vic20]

Synopsis:

 

Its all very pretty, but its a shame that UE5, to date, does not sufficiently leverage multicore CPUs to prevent CPU bottle necking. 

[Zaku3]

1 minute ago, Mr.Vic20 said:

Synopsis:

 

Its all very pretty, but its a shame that UE5, to date, does not sufficiently leverage multicore CPUs to prevent CPU bottle necking. 

 

Ridicoulously powerful 4090 and 7900XT have entered the chat.

[stepee]

Just now, Mr.Vic20 said:

Synopsis:

 

Its all very pretty, but its a shame that UE5, to date, does not sufficiently leverage multicore CPUs to prevent CPU bottle necking. 

 

So now that we are in the year 2022, on our third generation of multi core consoles, four cores long past being standard on pc, and even on mobile, what’s the deal exactly?

 

I used to think it was just developing for older tech or just taking time to catch on, but my goodness why is everything not designed for efficient multi-core usage still? Is it just incredibly hard to program that way?

[Xbob42]

1 minute ago, Zaku3 said:

 

Ridicoulously powerful 4090 and 7900XT have entered the chat.

Kinda seems like you could have infinite GPU power and this would run almost the same because of CPU performance being largely based off single-threaded performance. Which is a dang shame! CPUs are not getting massively faster anytime soon but we've been getting more threads for years.

I'm guessing there's plenty that just can't be threaded, but honestly it can't be THAT little! Otherwise we could just do away with all these extra threads for gaming CPUs already because they ain't doing shit!

[Mr.Vic20]

1 minute ago, stepee said:

 

So now that we are in the year 2022, on our third generation of multi core consoles, four cores long past being standard on pc, and even on mobile, what’s the deal exactly?

 

I used to think it was just developing for older tech or just taking time to catch on, but my goodness why is everything not designed for efficient multi-core usage still? Is it just incredibly hard to program that way?

The problem is that despite a lot of good work in this department, It takes a lot of time and money to leverage extra cores and still maintain a really smooth experience. This is likely to happen when a well funded studio like an MS or Sony first party develops a matured understanding of a static piece of hardware, but far less likely for PCs where its always an afterthought. 

[Keyser_Soze]

Bad news for current gen consoles?

[stepee]

2 minutes ago, Mr.Vic20 said:

The problem is that despite a lot of good work in this department, It takes a lot of time and money to leverage extra cores and still maintain a really smooth experience. This is likely to happen when a well funded studio like an MS or Sony first party develops a matured understanding of a static piece of hardware, but far less likely for PCs where its always an afterthought. 

 

Yeah that makes sense, still just seems wild to me that epic hasn’t been able to figure SOMETHING out to not be this locked to single thread.

[Mr.Vic20]

1 minute ago, stepee said:

 

Yeah that makes sense, still just seems wild to me that epic hasn’t been able to figure SOMETHING out to not be this locked to single thread.

Yeah, it amazes me too that we don't dedicate some of these threads just to having an advance load balancing hardware call scheduler. I'm not a coder so maybe that waaay easier said then done. While this all seems worrying now, its seems pretty far fetched that the wizards that make these engines don't have a series of target they aim to hit when they develop their design documents, so I would guess the engine will mature in this respect and find ways to cut overhead. Also, now that "Little + Big" CPUs exist on the market their respective schedulers need to mature as well. 

[Keyser_Soze]

8 minutes ago, stepee said:

Yeah that makes sense, still just seems wild to me that epic hasn’t been able to figure SOMETHING out to not be this locked to single thread.

 

It took them 5 years to add a shopping cart to EGS. I'm not surprised they can't figure out multi-threaded CPUs.

[stepee]

10 minutes ago, Mr.Vic20 said:

Yeah, it amazes me too that we don't dedicate some of these threads just to having an advance load balancing hardware call scheduler. I'm not a coder so maybe that waaay easier said then done. While this all seems worrying now, its seems pretty far fetched that the wizards that make these engines don't have a series of target they aim to hit when they develop their design documents, so I would guess the engine will mature in this respect and find ways to cut overhead. Also, now that "Little + Big" CPUs exist on the market their respective schedulers need to mature as well. 

 

True, true it is still early and can evolve. Also developers using it will obviously just tune as needed to get cpu under control, it’s not like everything will play like that demo, it just lowers the ceiling of what can be targeted more so.

[crispy4000]

1 hour ago, Keyser_Soze said:

Bad news for current gen consoles?

UE5 games trying to leverage its notable new features could run at ~30fps, and upscale from 1080p base resolutions, or worse.  Raytracing couldn't easily be mixed in.  Stutters from loading assets will continue to be a problem for UE5 and a challenge for developers to mitigate.

 

I hope Crystal Dynamics, CD Projekt Red, The Coalition and others can help Epic optimize their shit for everyone.

[legend]

12 hours ago, stepee said:

Is it just incredibly hard to program that way?

 

Generally speaking, yes. While I'm not a game dev, games have to do a lot of frequent synchronization and I can absolutely imagine this meaning a massive headache with multi-threading. I suspect it's still a lot easier to silo very different compute jobs to different threads than it is to scale a single task across it and that means limited utilization of multi-threading.

 

Mini-rant: C++, which most big games are written in, isn't great for multi-threading either. I mean, it certainly has all the performance potential, but as a language you can easily shoot yourself in the foot. If games ever started to switch to using Rust that might become a bit easier, but that is a huge ask and not likely to happen any time soon.

[Spawn_of_Apathy]

14 hours ago, legend said:

 

Generally speaking, yes. While I'm not a game dev, games have to do a lot of frequent synchronization and I can absolutely imagine this meaning a massive headache with multi-threading. I suspect it's still a lot easier to silo very different compute jobs to different threads than it is to scale a single task across it and that means limited utilization of multi-threading.

 

Mini-rant: C++, which most big games are written in, isn't great for multi-threading either. I mean, it certainly has all the performance potential, but as a language you can easily shoot yourself in the foot. If games ever started to switch to using Rust that might become a bit easier, but that is a huge ask and not likely to happen any time soon.

if only there was somebody who could develop an engine with developer tools that could make things easier and to automate some of the process of multi-threading to spread tasks out and synchronize them.  

[stepee]

15 hours ago, legend said:

 

Generally speaking, yes. While I'm not a game dev, games have to do a lot of frequent synchronization and I can absolutely imagine this meaning a massive headache with multi-threading. I suspect it's still a lot easier to silo very different compute jobs to different threads than it is to scale a single task across it and that means limited utilization of multi-threading.

 

Mini-rant: C++, which most big games are written in, isn't great for multi-threading either. I mean, it certainly has all the performance potential, but as a language you can easily shoot yourself in the foot. If games ever started to switch to using Rust that might become a bit easier, but that is a huge ask and not likely to happen any time soon.

 

That makes sense. I guess I’m surprised that they can’t silo very different compute jobs across multiple threads and have it significantly  reduce cpu usage by doing so even if not spreading individual jobs across multiple threads. Like I feel like something like this there are certain really heavy parts of it that could be separated like , ai, lumen, physics, sound, etc, each dedicated to separate cores. Even separating a couple thing I would think would massively improve over largely being single threaded. But I’m also not a programmer and have no idea how that works. :P

[legend]

4 hours ago, Spawn_of_Apathy said:

if only there was somebody who could develop an engine with developer tools that could make things easier and to automate some of the process of multi-threading to spread tasks out and synchronize them.  

 

Unfortunately, still not easy! Ultimately, you're going to have to ask the game developer to interface with whatever threading design you make in the engine and it will remain a headache. Multi-threading is filled with gotchas even when you're calling out to a "nice" multi-threaded API.

 

The reason I brought up Rust is because the language's very strict memory ownership model basically prevents you from compiling if your code might have a thread synchronization issue (unless you deliberately mark something as unsafe) and only through that kind of hard guarantee have I found multi-threaded complexity start to  become manageable. Even then, there are still lots of considerations.

 

 

3 hours ago, stepee said:

 

That makes sense. I guess I’m surprised that they can’t silo very different compute jobs across multiple threads and have it significantly  reduce cpu usage by doing so even if not spreading individual jobs across multiple threads. Like I feel like something like this there are certain really heavy parts of it that could be separated like , ai, lumen, physics, sound, etc, each dedicated to separate cores. Even separating a couple thing I would think would massively improve over largely being single threaded. But I’m also not a programmer and have no idea how that works. :P

 

To be clear, they can (and I believe do) silo very different compute jobs to different threads. But lets say they do that for 5 different kinds of engine jobs. If that's all you're able to do, then having a 6 core system isn't going to gain you anything because you're only using 5 threads.

 

What you really want is to be able to take a piece of code and have it *arbitrarily* be split among different threads. When you have that kind of task, that's when you'll really see the gains from increasing your core count, because you can make use of it immediately. But doing that is hard, at least for the kinds of things the CPU does. There are plenty of game engine tasks that can easily scale that way, but those tasks are typically handled by the GPU which is designed to be better at them. The tasks you don't want to do on a GPU that benefit from being run on the CPU, tend to have a hard time being able to arbitrarily scale to available cores. Usually, it's just a pre-determined number of jobs that you declare in advance and know don't have to communicate and synchronize with each other in complex ways.

[stepee]

1 minute ago, legend said:

 

Unfortunately, still not easy! Ultimately, you're going to have to ask the game developer to interface with whatever threading design you make in the engine and it will remain a headache. Multi-threading is filled with gotches even when you're calling out to a "nice" multi-threaded API.

 

The reason I brought up Rust is because the language's very strict memory ownership model basically prevents you from compiling if your code might have a thread synchronization issue (unless you deliberately mark something as unsafe) and only through that kind of hard guarantee have I found multi-threaded complexity start to  become manageable. Even then, there are still lots of considerations.

 

 

 

To be clear, they can (and I believe do) silo very different compute jobs to different threads. But lets say they do that for 5 different kinds of engine jobs. If that's all you're able to do, then having a 6 core system isn't going to gain you anything because you're only using 5 threads.

 

What you really want is to be able to take a piece of code and have it *arbitrarily* be split among different threads. When you have that kind of task, that's when you'll really see the gains from increasing your core count, because you can make use of it immediately. But doing that is hard, at least for the kinds of things the CPU does. There are plenty of game engine tasks that can easily scale that way, but those tasks are typically handled by the GPU which is also designed to be better at them. The tasks you don't want to do on a GPU that benefit from being run on the CPU, tend to have a hard time being able to arbitrarily scale to available cores. Usually, it's just a pre-determined number of jobs that you declare in advance and know don't have to communicate and synchronize with each other in complex ways.

 

This is great info thank you!

[legend]

Just now, stepee said:

 

This is great info thank you!

 

Welcome  

[stepee]

I think I have some really dumb question about if it would matter or make sense or anything to target full cores without hyper threading, so target 8 cores vs 8 threads across 4 cores, so that if something was programmed for a standard of 8 core minimum would that help vs programming for 4 core minimum but only if hyper threading wasn’t happening and actually I lost my train of thought but yeah sounds like one of those things that just doesn’t have its solution yet. 

[legend]

4 minutes ago, stepee said:

I think I have some really dumb question about if it would matter or make sense or anything to target full cores without hyper threading, so target 8 cores vs 8 threads across 4 cores, so that if something was programmed for a standard of 8 core minimum would that help vs programming for 4 core minimum but only if hyper threading wasn’t happening and actually I lost my train of thought but yeah sounds like one of those things that just doesn’t have its solution yet. 

 

Most typically you don't really directly say "I want this on a hyperthread" you just say you want a thread and let the OS and CPU figure it out. Certainly, though, you can target only the number of full cores if you want to approximately have dedicated access.

[Dre801]

I have 12 cores and 24 threads.  Please use them.

[TwinIon]

I'm a programmer but I've never worked on anything close to a modern game. Even when I've had workloads that were ideally suited to multi-threading, it was still a freaking pain to get it working right. For most of what I've done, it's almost never been worthwhile, but when I have implemented it, between all the thread management involved and a lack of multi-threading throughout the entire thing, I've never seen the hypothetical improvements I was really hoping for.

 

That said, while I feel I understand better than most the challenges in making something truly multi-threaded, I am surprised we're seeing UE5 get to this point without seemingly more threading built in from the start. It's pretty disappointing to see an i9 10900k be the limiting factor in a demo with almost no actual gameplay happening.

 

While we certainly can't extrapolate the performance of this early demo to a generation of incoming games, I do wonder if we'll see more games be CPU limited in a future dominated by UE5 games.

[Bitgod]

All this talk of lumen makes me want a waffle party.