Move UI from GPU -> CPU

[adeebshihadeh]

In order to run larger models, we need to make the GPU exclusive for the driving model. This means we need to offload several processes that currently use the GPU onto the CPU. A good start will be moving the UI to the CPU, which is probably a significant portion of the GPU usage

• [ ] optimize maprenderer which currently runs on the CPU for mapsd
• [ ] move cameraview to CPU and make optimizations
• [ ] move rest of the UI

[jnewb1]

@deanlee We are working on larger driving models, but we need to move the UI and a few other components to the CPU for that to be feasible on device. A good start would be analyzing and optimizing the maprenderer. We moved mapsd to the CPU as an experiment for CPU rendering, and it takes about 10x the time to render on the CPU (about 30ms, rendering a 256x256 grayscale map at 2hz), so we'd likely need quite a few speedups to render the stylized UI map on device. We have a nice test for this in CI that can also run standalone on device. Would you be interested in looking into optimizing that?

[deanlee]

@jnewb1 will there be any improvement if enable threading?

[jnewb1]

@jnewb1 will there be any improvement if enable threading?

The latency would most likely be better with threads (you can try it with LP_NUM_THREADS), however the goal would be trying to fit the whole UI on the cpu without bogging down the system, which would mean we would need to significantly optimize overall, not just use more threads. We also don't really care that much about the latency as long as it's reasonable (mapsd is fine with 30ms delay)

[deanlee]

Think it's difficult to optimize the performance based on the current available map API (there is also a lack of other header files from mapbox, only qmapbox.hpp in mapbox-gl-native-qt/include). I've tried using static rending, but always get an error:

render error! "Map is currently rendering an image"

I looked at the source code of the qmapbox, but still can't figure out what's causing the issue. Maybe we can do this optimization later, after switching the map API to MapLibre? https://github.com/commaai/openpilot/issues/26739

[adeebshihadeh]

Sure, @deanlee wanna try to do the MapLibre move?

[jnewb1]

GPU render time breakdown

Onroad Total 4-6ms

• CameraView: 0.5-1.2ms
• Dmoji: 0.2-0.8ms
• Model viz (path, lead indicator, lane lines): 0.7-2.5ms
• HUD: 1.3-2.5ms
• Sidebar (only updates when something changes, like wifi bars or panda state): 1-2ms

Map (when enabled): 1.2-2.5ms ( depending on scene complexity )

[andiradulescu]

@adeebshihadeh do you prefer this to be done in openpilot, so that we control each process that runs on CPU?

or we want an AGNOS approach, where everything qt and/or EGL runs on CPU without any changes in openpilot?

if you prefer in AGNOS, I will create a separate issue explaining the two possible variants (with weston or without).

[adeebshihadeh]

There's a tradeoff. More control with openpilot, but then it's a little harder to run arbitrary stuff. I think it'll end up being the cleanest to cut out Weston and do almost everything in openpilot.