Digital Foundry Article Technical Discussion [2023]
- Thread starter BRiT
- Start date
- Status
I'm surprised, or more likely not aware enough of how things work, that AMD and NVIDIA dont have a dedicated team of engineers, always optimizing the latest version of Unity and Unreal. I know there is a Nv branch of Unreal, but i thought that was more about features than performance.
Surely it would pay significant dividends for MS to have a branch of Unreal that is optimized for XSS/XSX ?
Or is each different game engine just too different for global engine optimizations to matter?
I'd love for a Gfx game dev, to provide some more info around the whole optimization process
Surely it would pay significant dividends for MS to have a branch of Unreal that is optimized for XSS/XSX ?
Or is each different game engine just too different for global engine optimizations to matter?
I'd love for a Gfx game dev, to provide some more info around the whole optimization process
Maybe they have those changes already merged to Main for Unreal?
SRP is a friendly way to write multiplatform rendering code, and solves a lot of existing problems with unity, but the nature of the problems are such that you need to be an expert in your content and in the subject to really maximize performance regardless of what unity does or doesn’t provide
Microsoft has an optimized UE4 branch. The Gears games use it. Multiplatform games launching on PS will of course not use it.
I would not expect a Multiplatform game to use the MS branch of Unreal on PlayStation, but I would expect them to use the MS optimized branch for the MS platforms,
Well to be more specific I would expect them to use a Xbox Series optimized version of the engine. As Windows is an entirely different beast, even if they basically present as the same target.
However having said that, the unified memory vs split memory pools of the consoles vs windows systems, might mean there is a branch of unreal optimized for unified memory platforms, and another for split memory pools, and then within the unified memory branch, separate backends/Impls for the 2 main consoles.
Targeting multiple platforms is tricky, but thats also why we have automated build systems and automated test systems.
I suppose I'm glossing over just how complex the actual optimization work is.
Especially from a GPU standpoint, targeting 2 or 3, different APIs and 2-4 different hardware SKU's with a single codebase.
Even more so if you start your work in GNM (is that what the Sony tools are called here? ) and then later target DX12.
My own software optimization experience is primarily in CPU land, so I'm an outsider when it comes to the GPU side of things.
It still surprises me though, that MS have not been able to provide tools that can easily leverage the wider nature of the GPU in the XSX.
(yes I know its not all about shaders, yes I know the PS5 has some areas of superior performance, but still with that much extra compute,
it seems like XSX games are doing a poor job of leveraging it. )
At least for the Matrix Demo, and fortnite season 4 it looks like some serious effort went into optimizing for both the lead consoles.
Maybe UE5, will be better for customers than UE4?
Because some fixes aren’t the product of just a week’s worth of work. Devs will go gold hoping the time between gold and launch will be enough to handle issues with a day one patch. Some fixes take longer and must be handled by subsequent patches.
Should probably hold the game off from release then if those patches are already in the works and known issues, right?
Publishers don’t operate on a “release when perfect” time schedule especially when on PC where there exists no outside party that approves releases.
Nobody is asking for it to be perfect.
It's very clear publishers operate on a release first fix later time schedule... hence the problem I have.. and hence why gamers and developers alike are flooding my timelines pissed off about the newest PC port which performs like trash.
Yep. But unless the problem shows up readily affecting the pubs’ bottom line they don’t really care. Outrage in and of itself has no value if you don’t back it up by keeping your wallet in your pocket.
If sales were more closely correlated with the state of a game than its release date, we wouldn’t have these issues. But gamers have a hard time practicing patience.
I would guess using a different branch for Xbox would increase the development complexity in a non trivial way.
It will if things keep going the way they're going.
Are we sure this problem is actually "new"? I know DX12 isn't helping things in some cases, but in the past the PC got far fewer cross platform titles, and when it did, they were usually released after the consoles versions rather than day and date. This could have gone a long way towards mitigating the issue.
We also have the likes of Digital Foundry these days who highlight issues in exceptional detail (with other sites slowly starting to pick up on it too). Honestly, I do feel that the outrage is starting to run away with itself a bit too. I get it in the case of Sack Boy and Calisto for example (both of which were fixed within days), but Wo Long for me runs pretty fine. I can see frame time spikes on a graph, but in gameplay they are occasional and barely noticeable. It's not perfect, but it's also far from unplayable, or 'a mess' from what I've experienced of the demo at least.
Other aspects of the port are quite poor though, e.g. lack of useful graphics settings and poor key/mouse support (not that that bothers me in the slightest in a game designed for a control pad).
We also have the likes of Digital Foundry these days who highlight issues in exceptional detail (with other sites slowly starting to pick up on it too). Honestly, I do feel that the outrage is starting to run away with itself a bit too. I get it in the case of Sack Boy and Calisto for example (both of which were fixed within days), but Wo Long for me runs pretty fine. I can see frame time spikes on a graph, but in gameplay they are occasional and barely noticeable. It's not perfect, but it's also far from unplayable, or 'a mess' from what I've experienced of the demo at least.
Other aspects of the port are quite poor though, e.g. lack of useful graphics settings and poor key/mouse support (not that that bothers me in the slightest in a game designed for a control pad).
Good first point. Which also leans into what I've been constantly saying about QA for PC games being the big issue. Publishers seem to think PC games releasing with issues is acceptable, as it is easier to explain away for them. If publishers aren't giving a game the proper time to be done correctly, then we have a problem. There's nothing wrong with having differing levels of priority and focusing on certain things over the other.. but at the end of the day they are making the choice to release them simultaneously.. so when the PC version is released with terrible stuttering issues or what have you.. we should expect that the game performs reasonably as all versions should. It's not acceptable to release a game that is broken and wait for it to be patched.. and PC gamers also shouldn't have to wait for potential patches to fix basic functionality of games. They should release when ready.
It also doesn't make any sense for publishers to release games with these issues when they're often fixed so quickly after a big fuss has been made. They need to avoid these unnecessary cases of negative press as best they can.
Developers were pushing for low level APIs for PCs, and often "getting what you wish for" comes with unforeseen consequences.. The added complexity on the PC side turned out to be more than a lot of developers could handle.. These new APIs were designed with perfectly good, logical intentions at the time, but things don't often go the way they're intended in life.
I still think that the DX12 and Vulkan models were ultimately the right way to go, but it was a hop, skip, and a jump too far all at once. I think what they should have also done was build an even easier high level API which made it as easy as possible for developers to get good performance/quality for as little effort as possible... overhead be damned.
Apparently MS is getting ready to move on to Windows 12. That would be the perfect time to get a new update to DirectX out there as well as new tools for developers to ensure the easiest possible development environment for the future.
It does seem that way. Constant stutter is extremely annoying of course but if I’m honest it really wouldn’t bother me that much if a game stuttered for the first few mins but was fine after. I would just get on with my life and enjoy the game.
Pop-in is the thing that drives me bonkers. Hopefully there’s widespread outrage about that soon
I get emails from Khronos every few moths, including a survey often focused on how to make things easier. There is some progress, e.g. Render Passes became optional recently.
If we're lucky, in some years VK may be as easy to use as DX12. <: )
Many people say Metal looks like a proper middle ground between low level and ease of use. Can't tell myself. Coding with XCode felt like trying to play guitar with iTunes to me.
My personal impression so far (focus just on easy compute, but little exp. on complex gfx) is low level APIs are acceptable, but not perfect. A replacement will likely happen at some time.
Some important things were left out at the start. OpenCL and Cuda already had options to generate work on GPU directly, but neither DX12 nor VK can do this yet. Mantle was way better in this regard.
VK missed to opportunity to adress this. They added conditional draws, but conditions can't include barriers. So the feature can't be used to implement coarse control flow on indirect dispatches.
That was the point where i thought VK will fail just like OpenGL did before. New features add bloat but not enough options. DX12 does not really move on either, afaict.
Regarding optimization problems with current games, there are some arguments rarely discussed, e.g.:
'We already pay to use certain U engine. So why should we optimize their engine on top? It's their job, not ours anymore.'
'Current state of the art requires to author thousands of shaders, done with some node graph GUIs and automated code generation. It's content now, like other assets. We no longer have the option to do hand made assembly optimizations on that stuff, nor have we enough control about compilation issues.'
'You expect huge open world games without loading screens? Get used to some stutters then.'
That's valid points i think. The issue may not be just lazy devs, but the gaming eco system as a whole, including end users.
The path to resolve the issues seems clear: Once each every game has those same issues, nobody will complain anymore.
Optimizing UE and Unity for (or even worse, by) any platform holder or GPU vendor will mike it worse, not better.
Because spending efforts on that means less effort on general improvements, e.g. better APIs, better drivers, optimizing OS for realtime applications.
It also means an unfair advantage for big engines, so the necessary competition would vanish even earlier.
And this seems to be consensus
All Blog Entries (asawicki.info)
"The new graphics APIs (Direct3D 12, Vulkan, Metal) are not only a clean start, so they abandon all the legacy garbage going back to ‘90s (like glVertex), but they also take graphics programming to a new level. It is a lower level – they are more explicit, closer to the hardware, and better match how modern GPUs work. At least that’s the idea. It means simpler, more efficient, and less error-prone drivers. But they don’t make the game or engine programming simpler. Quite the opposite – more responsibilities are now moved to engine developers (e.g. memory management/allocation). Overall, it is commonly considered a good thing though, because the engine has higher-level knowledge of its use cases (e.g. which textures are critically important and which can be unloaded when GPU memory is full), so it can get better performance by doing it properly. All this is hidden in the engines anyway, so developers making their games don’t notice the difference."
So DX11.3, basically?
That really seemed like the sweetspot for ease of use, good multithread capabilities, and high fidelity/high performance graphics. And it's still available for any developer who wants to use it. Problem is - developers have all moved on, because there's 'next gen' features to take advantage of with DX12, but it's really not been a great tradeoff in quite a lot of cases.
It's unclear(at least to me, perhaps some low level graphics/engine programmers here might know better) exactly how much these next gen features are really necessarily limited to DX12/Vulkan or just artificially limited in order to advance adoption of new standards. I usually wouldn't complain about such a situation, except that yea, it's not working out very ideally as time goes on.
EDIT: I've also seen nothing to suggest Microsoft is moving to Windows 12. I'm guessing you're talking about some errant article briefly mentioning it, which could have been a typo, misunderstanding or some other mistake most likely. It is not a substantiated rumor, much less any kind of real information to begin with.
Last edited:
That's sort of what D3D11.3 was intended to be which was some D3D12 features backported to D3D11...
A lot of D3D12's CPU-sided optimizations are inherent to the API changes. More explicit memory management is necessary if you want to do persistent mapping or get more accessible CPU-visible GPU memory. Exposing a bindless API would violently clash with D3D11's implicit barrier model. More featured indirect draw/dispatch APIs like ExecuteIndirect aren't compatible with D3D11 slot-based resource binding model thus gating advances in GPU-driven rendering. Despite the criticism surrounding PSOs, you can see quite a bit of CPU performance improvements by batching draw calls according to state changes ...
Much of the CPU-side benefits aren't possible without the more explicit nature of D3D12. API perf/overhead is fundamentally a function of strong coupling with it's design ...
- Status
Similar threads
