Unity Linux embedded HMI, GPU usage at 100%

Unity Engine
1

In our Unity Linux embedded project (running on 3 displays simultaneously), we noticed through profiling the integrated GPU on the Qualcomm 8155 chip using Snapdragon Profiler that the HMI process consumes almost 100% of the resources.
The tests we conducted included changes to the Quality and Player settings, modifications to the scriptable object of the URP settings, as well as AntiAliasing and PostProcess settings on the cameras themselves, all of which yielded poor results. The final test involved building the HMI demo project provided by Unity on the Asset Store (multiscreen setup with default settings), which produced the same result.
Attached are two images:

  1. The percentage of GPU usage and the clocks of the HMI process from the latest Unity HMI demo build. The moments where usage flatlines correspond to Linux freezing due to a SIGINT (is there a setting in Unity that could help avoid this?).
  2. The change in system-wide GPU usage after forcibly terminating the HMI process.

Any assistance in resolving this extreme GPU usage would be greatly appreciated.

2

There are no images attached.

Generally, if vSync is disabled, Unity will consume as much GPU resources as possible to render as many frames as possible. (unless your application is CPU limited)

If you would like to limit that, you can use Application.TargetFramerate.

Once you are limiting the frame rate, the time it takes to render the frames will still dependent on what you’re rendering. Without knowing your project, I can’t tell if it’s appropriate for the hardware and what the optimization possibilities are beyond that.

This means that if the time it takes the GPU to render content for your 3 displays is 16.6 ms and you’re limiting the frame rate to 60 fps, Unity will still use 99% CPU.

So if limiting the frame rate didn’t reduce CPU usage, I recommend using the rendering debugger to understand what your application is doing and reducing draw calls, simplifying shaders, reducing overdraw etc.

3

Strange… I do see them. I’ll attach them again here

Screenshot 2025-02-06 144417
Screenshot 2025-02-06 1444171214×429 183 KB

Can you see them now?

I did some other tests where I added a script that does the following:

private void Awake()
{
    Application.targetFrameRate = 30;
    Application.runInBackground = true; // just in case
    QualitySettings.vSyncCount = 1;
}

with poor results… From the profiler it looks like the framerate is at 60 regardless…

Another test I did is set the Render Scale to 0.5 wich dropped the GPU usage to 30% but as expected, it looks terrible and doesn’t represent the desired result.

These tests were made on the HMI Demo provided by Unity from the Asset Store (wich produced similar results to the original project). Just imported it with it’s settings and fixed the bug that prevents the HVAC scene to load on the correct Display.

4

It looks like you’ve already tested the obvious knobs, so the fact that even the Unity HMI demo behaves the same points to a platform + multi-display issue rather than just project settings.

A few key things to check:

  • Frame limiting: Unity will max out the GPU unless capped. Set Application.targetFrameRate (30/60) and verify VSync actually works across all 3 displays.
  • Multi-display cost: Each display may be triggering a full render, effectively tripling GPU load. Try testing with 1 display to confirm scaling.
  • URP settings: Even “disabled” features can cost. Make sure render scale < 1.0, shadows off, HDR off, and no extra lights.
  • SIGINT freezes: Likely not Unity itself—could be thermal throttling, driver instability, or compositor issues on Linux. Check system logs (dmesg) for GPU faults.

Also, on embedded systems like this (similar to automotive HMI or HVAC interfaces), hitting 100% GPU isn’t unusual if uncapped—the goal should be stable frame timing, not max utilization.