Note for the release CARLA 0.10.0
We’ve conducted several profiling sessions on different PCs in the Package. As of today, the CPU seems to be the main bottleneck; the better the CPU, the better the results. The best we’ve achieved so far is 24/25 FPS (on Ubuntu 22) by adding the -RenderOffScreen flag to the server, essentially turning off the spectator camera.
As of now, we have no idea how to optimize further to reach 30 FPS. While it’s true that the other sensors can reach 30 FPS, the issue lies with the RGB Camera. The section highlighted in red shows the block where the camera sensor is being rendered, and the section in yellow corresponds to the spectator.
Yes, GPU parallelism is enabled
and you can see that the two command lists are being executed in parallel.
In Image 3,
there are several idle periods we don’t fully understand. In the first block, corresponding to the SceneCaptureComponent2D of the camera, you can see some gaps. We don’t know why they’re so large or what causes them. These gaps don’t occur in the second block, which also corresponds to the camera.
There are some long waits that we believe are due to the RenderThread waiting for the GPU (Image 4).
Here’s what we’ve tried so far:
Lowering the spectator quality without affecting the client (this hasn’t worked, and even if it did, the performance gain wouldn’t be sufficient as we’ve tested with spectator rendering completely disabled).
Using SceneCaptureComponent flags to speed up performance (this also didn’t work).
According to Epic Users performance of 5.5 is worse than 5.3 but we need 5.5 as the raytracing in vulkan is supported in this version.
So we are open to suggestions and any contributions community can make.
Note for the release CARLA 0.10.0
We’ve conducted several profiling sessions on different PCs in the Package. As of today, the CPU seems to be the main bottleneck; the better the CPU, the better the results. The best we’ve achieved so far is 24/25 FPS (on Ubuntu 22) by adding the -RenderOffScreen flag to the server, essentially turning off the spectator camera.
As of now, we have no idea how to optimize further to reach 30 FPS. While it’s true that the other sensors can reach 30 FPS, the issue lies with the RGB Camera. The section highlighted in red shows the block where the camera sensor is being rendered, and the section in yellow corresponds to the spectator.
Yes, GPU parallelism is enabled
and you can see that the two command lists are being executed in parallel.
In Image 3,
there are several idle periods we don’t fully understand. In the first block, corresponding to the SceneCaptureComponent2D of the camera, you can see some gaps. We don’t know why they’re so large or what causes them. These gaps don’t occur in the second block, which also corresponds to the camera.
There are some long waits that we believe are due to the RenderThread waiting for the GPU (Image 4).
Here’s what we’ve tried so far:
Lowering the spectator quality without affecting the client (this hasn’t worked, and even if it did, the performance gain wouldn’t be sufficient as we’ve tested with spectator rendering completely disabled).
Using SceneCaptureComponent flags to speed up performance (this also didn’t work).
According to Epic Users performance of 5.5 is worse than 5.3 but we need 5.5 as the raytracing in vulkan is supported in this version.
So we are open to suggestions and any contributions community can make.