Good afternoon!
My problem is that at ultra-wide resolutions, players have extremely low frame rates, while the GPU load becomes 100%:
even with the lowest graphics settings, vsync off etc, I get 6 to 8 fps. I’ve tried the different graphics APIs, fullscreen/windowed mode, and the only thing that makes a difference is not running it in ultra widescreen. 5120 x 1440 = 8 fps, 100% GPU 2560 x 1440 = 110 fps, 37% GPU
OS: Windows 11 Pro 64 Build 22631 CPU: i9-14900K RAM: 64 GB GPU: RTX 4090 Game Ready Driver 572.83 Desktop Resolution: 5120x1440@240Hz SDR Windows “Game Mode” Enabled Resizable BAR: Enabled
No noticeable change with G-Sync off, using Dx11 or Vulkan except Vulkan went up from 8 fps to 18 fps, and 400 fps @ 80% GPU when I drop the 3D resolution back to <80%
The project is based on Unreal Engine 4.27, without modifications
Does anyone have any ideas?
What upscaler or AA method are you using? TSR, TAA, FXAA or MSAA? Since you said you’re using 3d resolution setting, I’m guessing either TSR or TAA.
Are you setting the screen resolution at runtime? You pretty much have to do it if you’re using widescreen, otherwise it’ll just use 100% screen percentage.
I don’t have that wide a widescreen. Mine is 3440x1440 and while I don’t get that much slowdown, I did dive into the render resolution a while back and it’s quite bad for widescreens. It uses the FULL dimensions of the screen (but at a certain aspect ratio, so if it’s wider, it’ll increase the height calculations) as input to the algorithm they have to calculate the default render resolution regardless if you’re in windowed mode or fullscreen. It gets worse the wider the screen. So on widescreens, you can end up near 100% screen percentage (or even above).
I have two monitors, so I can move the editor from one monitor to the other and see what the default render resolution is on the 3D resolution screen in the scalability menu. It updates when I switch monitor. My 4k monitor has WAY more pixels, yet its default screen resolution is 60%, but on my widescreen, it’s 80%. I’d be willing to bet that this is the main issue. Can you post a screenshot of the 3D resolution screen while you’re playing the game in the editor?
Also note that with a wider screen, you’re rendering a LOT more of the level. Don’t underestimate how much this can affect performance. Many things like foliage and lighting will hurt performance in an exponential manner. You could use Insight to see where the CPU and GPU is spending its time.
Also, in the past there used to be issues when using too large a render target. You have a 4090 so probably not an issue going above 4096 pixel render target, but easy to check.
Last thing is cloud shadows. I think it’s in the SkyLight “Cloud Ambient Occlusion” checkbox. Turn that crap off if you’re doing performance testing.
Good afternoon!
I use TAA.
The problem is observed both immediately after startup and when manually changing the screen mode.
With a resolution of 3840x2160, there are no performance problems (although this screen is larger than an ultra-wide screen in terms of area)
screenshot: https://bfly.blue/solargene/Solargene%20early%20access%20%2026_03_2025%2019_23_58.png
You can see that the scene is very simple (no grass or clouds).
Also, the performance drop occurs very abruptly just when the scale of the render is changed.
Unfortunately, the problem can only be reproduced by players, and I don’t have a monitor to reproduce it for myself.
So, since you are rending 2 screens on an engine that can barely handle 1080p without some rather major effort put into performance optimizations, I’d say it’s your fault (or whomever picked the engine on the project) for not using a better engine .
On the other hand, the fact your gfx is bottlenecking probably means one of the following:
(Though you wrote 4.27, this is worth putting out there for the google people) Nanite isn’t capable of doing math and is sending way more stuff out to the gfx without any type of error checking to load balance.
There’s just too many instance (twice more?) Than expected on screen and the GFX is clogged up by drawcalls.
Something else - specific to your scene - is acting up because of the resolution increase.
Could be anything. You have to expressly drill down the stats to figure out what it is.
And that last bit is actually the same when considering the engine’s rendering code. Except it won’t point you to anything specific but it’ll get you an idea of what part of the various render passes are hanging.
You can almost always guarantee that anytjing to donwith render targets is at fault when dealing with random low performance changinging on just one variable. So maybe check the stats on that carefully too.
Ps - windowed mode should allow you to manually type in the resolution from the .ini so you don’t need the screen. You won’t see the game but the engine is still rendering it at the window resolution which is all you care about to pull stats.
I don’t understand why you wrote that there are 2 screens. There is only one screen and it is widescreen.
On a larger screen, the project works without problems and the GPU is not overloaded.
The scene is very simple, I have given a screenshot above, the problem is clearly not in the scene. Even if there were twice as many objects in the scene due to the wide screen, performance would not drop dramatically by 10 times with minimal graphics settings.
The original message also states that when the resolution of the render is reduced to 80%, there is no problem, but when the resolution of the render is increased to more than 80%, the problem occurs. That is, there is a sharp edge on which the problem consistently manifests itself with the same number of the same objects on the screen.
Because Obviously you do not realize that Double the Resolution is the same as 2 screens each rendering simultaneously.
Regarldess. What’s 80% of 2 screens (at the res you shared)?
Still way more than your avarage user’s rendering.
Sure, the engine is broken, ain’t nothing new about that. The 80% is probably just The specific resolution above which it breaks. Which is higher than 4k, so epic won’t care.
If it were up to them, youd be rendering at 400x200 still.
I have a 3440 x 1440 screen, when I had the project in 4.27, even the main menu, which was just an image, had a very very very low framerate. I never got around to investigating why this was because I moved to 5.3 and it stopped happening. I can’t help you, but I can confirm that in 4.27, with that resolution, something very strange happens.
Unless you have a plugin in 4.27, and you’re not part of one of those trendy sects that hate Unreal 5, I would recommend moving to 5.4 or 5.5.
Unfortunately, I do not have the technical ability to upgrade to unreal engine 5..
I have no performance problems on my screen with a resolution of 3840x2160, perhaps there is a problem, as the first commenter wrote, with a resolution transition of more than 4096, which looks like the truth, but how to fix it?
If you don’t have access to a machine where you can reproduce it, you’re gonna have a tough time finding out what’s causing it. Could be anything. Is TAA limited to 4k render targets in UE 4.27? Dunno. Is it a frustum issue? Probably not but you never know at such resolutions.
You have screen percentage as a config option. That’s good. If you don’t have a machine of your own to reproduce this, your best bet is to provide a patch where you check for ultra widescreens and rescale your screen percentage dial from 0 to 75%, but still display it as 0 to 100%. Basically multiply the value by .75 when the user slides the slider if it’s ultra widescreen. When setting the slider value, divide it by .75 and clamp it to 0 to 100. If it’s not ultra widescreen, set the scale factor to 1. This also needs to be checked at startup and clamp to 75% when setting screen percentage on startup if it’s ultra widescreen.
There are callbacks for changing fullscreen status as well as changing the viewport size. So if they drag to another monitor you can use that to recheck if screen percentage needs to be clamped to 75%. There’s FViewport::ViewportResizedEvent and there’s GEngine->GameViewport->OnToggleFullscreen().
I’ve been checking the framerates across different Steam branches and noticed some significant differences, all of them in 3440 x 1440 resolution.
Other of my Game in UE 4.24: Runs at 60 FPS on the main menu.
Game in UE 4.27: Runs at 3 FPS.
New version in UE 5.4: Runs at 120 FPS.
I think that going from 3 to 120 frames is clearly due to a bug. I’m not entirely sure if the issue was related to the engine version or if it was fixed when I rebuilt the main menu widget.
Since this scene only contains a widget, it seems likely that the problem is coming from the elements inside it.
One possible cause could be the 4K background scaling, which might be affecting performance. I remember switching from Canvas to Overlay and adjusting the background differently.
You could try removing the background to see if it improves performance. I’m pretty sure the issue is somewhere around there.
I’m pretty sure the 3 FPS version had a different way of scaling the background image.
And as a double check, you know that Unreal 5.x has everything that was in 4.x, Lumen Nanite, etc. It is optional and that the version change is minimal if you don’t use C++.
I don’t think you need fancy stuff to reproduce this.
The engine doesn’t care what screen or hardware you have - it’ll output what you set it to output.
Just like you can fuss with DLSS and render 800x600 at 4k you can do the opposite, render 8k down into a 4k screen.
As I said. Widget up a script to go windowed mode at whatever res you wish. So what if you cant see it all? The engine still thinks you can.
Also, it must be some plug in you guys have enabled or something - last time I checked though you get around 19fps 4.27 worked Ok stretched across 3 4k screens.
Ok. Well, 19 fps on a highy optimized scene or just a black screen
Btw you can try and report a bug - link them this thread. I doubt they care one iota.
I think I was able to reproduce this for myself - I connected a second monitor (though with a different resolution), switched to windowed mode and stretched the window over 2 monitors. The behavior is similar - there is an edge on the second monitor in the width of the window, exceeding which the fps drops sharply to almost 0.
I’ll try to reproduce this on an empty project.
I removed all the widgets, leaving only the TextBlock in the upper-left corner to display fps, in a situation where I was able to reproduce a similar behavior, it did not help.
My entire project is written in C++, so switching to UE5 is a difficult task.
I found a problem - it manifests itself when PostProcessVolume is enabled method=Convolution
I have an empty project on which the error is reproduced - how can I transfer it to the Unreal Engine developers?
For bug report?
I’d say zip it and include it with the report.
If they can reproduce it easily you increase the chances they’ll check it and do something from 1 in a billion to around 1 in a half a billion…
If the form has no upload, usually, at least back in the days when they gave a s*it and got back to you they’d email out and you could reply attaching the zip…
https://www.unrealengine.com/en-US/support/report-a-bug
I guess this is it.
But since it’s not the latest version, 5.5, I don’t think they’ll fix it. You’ll have to talk to someone who knows C++ to fix it for your version, or find another option. If the bug is from using convoution, can’t you use other? Im use Standar, btw the convoution in the tooltip say not to be used in gameplay
.
