CMD Rendering method can use Insights? I donot known, show Foreground.
Workstation-B Foreground :
<br/>
<br/>
[Image Removed]
8GPU Server Foreground :
[Image Removed]
<br/>
[Attachment Removed]
重现步骤
Hello, I am a technician from Laputta. We are currently producing a sci-fi movie with Unreal Engine 5 as our main production pipeline. However, we have encountered some rendering issues during the actual production process and would appreciate professional technical assistance.
In practical rendering work, it was found that for some shots, the rendering efficiency was higher when the UE5 project was opened in the foreground on the artist’s local workstation than when it was rendered in the background on the Deadline farm. Based on this observation, some simple tests were conducted, and the following is a comparison of the renderings:
[Image Removed]
Efficiency Comparison
Based on Workstation-B
Foreground vs. CMD
- Workstation-B: Foreground is 37% more efficient than CMD
- 8GPU Server: Foreground is 28% less efficient than CMD
Workstation-B vs. 8GPU Server
- Both in Foreground mode: Workstation-B is 520% more efficient than the 8GPU Server
- Both in CMD mode: Workstation-B is 221% more efficient than the 8GPU Server
In both modes, Workstation-B significantly outperforms the 8GPU Server, with a much larger advantage in Foreground mode (520% vs. 221%).
Workstation-A achieves foreground rendering speeds of up to 121 frames/minute.
UE5 Rendering Performance Differences and Multi-GPU Rendering — Technical Questions
Workstation-A achieves foreground rendering speeds of up to 121 frames per minute.
Q1: Foreground vs. UnrealEditor-Cmd Rendering
Testing has revealed a significant performance gap between UE5’s foreground and background rendering. What is the fundamental difference between UE5’s foreground rendering pipeline and the rendering pipeline used by UnrealEditor-Cmd? What causes such a large difference in efficiency?
Q2: GPU Requirements and Non-GPU Rendering Factors
What are UE5’s GPU requirements for rendering, and which parts of the rendering process involve more than just the GPU? Please provide relevant technical explanations and references for parameter testing.
Q3: Multi-GPU Rendering in UE5 Film Projects
We are currently using GraphicsAdapter to assign different GPU indices to different shots for background rendering on an 8-GPU machine. We have deployed an 8-GPU rendering machine for the project, but it does not appear to be reaching its maximum performance. Could you provide professional technical explanations regarding the usage methods and limitations of multi-GPU rendering for UE5 film projects?
[Attachment Removed]
Hello! I am making some assumptions here, so please correct me if I am mistaken.
Headless vs Full UI on the renderfarm
(I am assuming this is what you mean by FG/BG, correct?)
It is generally recommended to launch the full editor when rendering MRQ on a render farm. There are some systems in the engine that require the full app to ensure everything is loaded into memory in time for your MRQ render to start. I am unsure exactly why one is more efficient than the other. Are you able to share your full trace and logs from both renders?
GPUvsCPU
All of the “rendering” happens on the GPU, with a decent amount of frame prep on the CPU. For example, physics, collisions, AI, logic, and visibility (spawning, culling, etc.) all happen on the CPU, which then passes the frame to the GPU to render lighting, reflections, shaders, post-processing, etc.
mGPU
(You mention multi-GPU rendering. I am assuming you don’t mean mGPU for pathtracer, where multiple GPUs render one frame, since you talk about picking the GPU to render on from an 8GPU machine, correct?)
There could be a number of things that could throttle this setup. The render times you mention are very fast (2 frames a second) so it would not be surprising that the bottleneck is things loading into RAM, the CPU prepping the next frame, or even waiting on IO.
How are you measuring this and what is the content like? If the machine has 512Gb of RAM and 8 GPUs, thats only 64Gb of RAM per UE session which could fill up fast. I see you are disabling texture streaming in the command line so that could fill up your VRam very fast as well depending on how you are authoring your textures. Are you limiting what processes on what CPUs in deadline? Each instance of UE might be trying to use all the CPUs all at the same time.
[Attachment Removed]
Yes, I mean FG/BG
- FG is rendered by opening the Editor and using the Render (Local) function of the Movie Render Queue during regular production.
- BG refers to submitting a deadline and using the CommandLine rendering mode (UnrealEditor-Cmd)
You mentioned that UnrealEditor-Cmd is not the full version of the Editor. I also conducted a rendering test using UnrealEditor.exe as the rendering command for Deadline, but there isn’t much difference in efficiency between the two commands.
Before that, let me explain why we use UnrealEditor-Cmd.exe for background rendering: our project needs to be submitted to the Deadline farm for background rendering. I checked the UE help documentation at “https://dev.epicgames.com/documentation/unreal\-engine/using\-command\-line\-rendering\-with\-move\-render\-queue\-in\-unreal\-engine” for background rendering testing. The rendering results showed that the effect was correct, so we used it. However, in the early stages, we didn’t pay attention to the efficiency of CommandLine rendering.
I can currently provide you with the rendering logs for using both UnrealEditor-Cmd.exe and UnrealEditor.exe (both for rendering in Deadline). Please see the attachment.
Additionally, let me explain multi-GPU rendering. Our original intention in using 8 GPUs was to assign a specific GPU index (using the GraphicsAdapter parameter) to each Unreal task for simultaneous rendering. Of course, I will continue to monitor memory usage moving forward.
The footage I tested has over 20,000 frames, which is of course special for our project. During the deadline rendering (on an 8-GPU machine), it failed at around 15,000 frames and 18,000 frames. Currently, the log shows that the memory usage is: Memory Usage: 164.3 GB / 511.6 GB (32%)
The following is the end part of the deadline log (on an 8GPU machine):
Details
=======================================================
Date: 09/19/2026 06:27:29
Frames: 0
Elapsed Time: 00:13:22:39
Job Submit Date: 09/18/2026 17:04:49
Job User: huangs
Average RAM Usage: 120937201664 (23%)
Peak RAM Usage: 202275250176 (37%)
Average CPU Usage: 3778508%
Peak CPU Usage: 3981700%
Used CPU Clocks (x10^6 cycles): 244539465924608
Total CPU Clocks (x10^6 cycles): 6471852562
=======================================================
Worker Information
=======================================================
Worker Name: render01-gpu3
Version: v10.3.2.1 Release (1a66fe40f)
Operating System: Windows 11
Running As Service: No
Machine User: render
IP Address: 192.168.1.200
MAC Address: 50:79:73:05:3C:C2
CPU Architecture: x64
CPUs: 64
CPU Usage: 3%
Memory Usage: 164.3 GB / 511.6 GB (32%)
My core concern is why the rendering efficiency of FG is so high, whereas the rendering efficiency of BG is much lower, whether on an 8GPU machine or on our own work machine.
The rendering efficiency of the 8-GPU machine is surprisingly the lowest. We are also investigating the reasons and hope you can give us some suggestions. Is our way of using 8 GPUs in line with the rendering logic of Unreal Engine.
[Attachment Removed]
Thank you for the logs, they are helpful. This is a bit challenging to untangle. There are two problems here. Let’s separate the two for now, unless I am not understanding properly.
- On the workstation the cmdline render was slower than full app rendering.
- On the GPU server the cmd line was faster than full app but renders are slower overall.
What your logs and traces showed:
Both your logs are from different machines with different CPUs, RAM amounts, OS flavors, and driver versions. They were also both headless renders as far as I can tell. Do you happen to have two logs that are on the same machine? They still show some things to look at but you should consider getting the machines you want to render with all on the same driver and OS flavor if possible.
8-GPU server:
From what I can tell, the servers are not GPU-limited. The Lumen, lighting, shadow, and nanite passes all took about the same time or less on the RTXPro6000 as on the 4090. The gap seems to sit in PostProcessing/TSR, about 165ms between them. TSR should have very little cost. This points to the GPU waiting on the CPU/RHI. The server’s frame times are spiky, while the workstations are very flat. This also points to CPU side stalling, which fits a Xeon with lower single-thread clocks, up to eight UE instances sharing one CPU (each spawning 64 shader-compile workers), and the processes running inside an RDP session. I would try and cap shader compilation to a certain amount of threads and see if things even out. In both logs we see “Using 64 local workers”. So if you have multiple jobs running at the same time thats bad news. Between all your machines, times will vary due to the differences in CPUs alone. I would try and get everything on the same driver at least though. I think you can try and cap this at your command line submission:
-ini:Engine:[DevOptions.Shaders]:NumUnusedShaderCompilingThreads=whateverNumber,[DevOptions.Shaders]:NumUnusedShaderCompilingThreadsDuringGame=whateverNumberI think you can try -corelimit=whateverNumber as well to scale everything down in the CPU if the issue is more than just shader compile. But you should verify that. Or see if Deadline can pin each worker to a CPU. If you can set up a shared DDC, this is another way to somewhat mitigate the issue. The 2m 34s BlockOnAllShaderMapCompletion stall in the trace goes away entirely if the shaders are already in the cache, regardless of worker count.
Commandline vs Full App:
I think the differences come down to CPU as well, where the full app already has loaded the map, compiled all the shaders, and served everything up to MRQ when it’s reporting render statistics, but the command line has not. It has to pay that cost again. In your traces, that’s roughly 4–5 minutes before the first frame renders. If frames per minute is measured on total job time, that window accounts for most of the 37% on Workstation-B. And my guess is that on the server, the frontend is slower because the editor UI is being drawn through an RDP session; headless skips that. You should try to measure frames per minute only once the startup cost is paid. A shared DDC and PSO cache for the render nodes should shrink this cost, though.
GPU crash:
Both jobs ended in a GPU hang rather than finishing. RENDER02 hit a DXGI_ERROR_DEVICE_RESET after about 10 hours and RENDER01a DXGI_ERROR_DEVICE_HUNG after about 13 hours, in both cases mid-frame during ordinary Lumen/base-pass work with plenty of VRAM free. RENDER01 had logged a dozen “GPU timeout … not completed after 5 seconds” warnings through the day before it finally went. These are Windows TDR events, meaning a single GPU submission stalled past the OS watchdog, which is consistent with the CPU/GPU contention described above, rather than a separate bug. I suspect they would go away once the instances per box and shader workers are reined in and the drivers are aligned; if they don’t, let me know, and please send over the crash logs and full dmp files. You can also try raising the TdrDelay in the graphics driver registry so that long submissions don’t crash the render.
As an aside, you are getting a warning per frame about too many temporal samples with a 0 shutter, which should not hurt anything. Is there a reason you are not using Spatial Samples if you do not want motion blur? You are getting thousands of warnings per run for the translucent glass not being supported for nanite, which will indeed slow things down a bit.
[Attachment Removed]