Slow GUI with imx8m-plus

Technical Support
, , ,
1

Hi,

I’ve been using Uno for GUI development on a imx8m mini and it was working so far. However, we decided to move to a imx8m Plus this week and I was surprised to see the GUI running incredibly slow.
I’m going to try to break down what we have:

  • imx8m Plus
  • CSI display
  • OS based on Torizon 6.6.1 with added drivers
  • weston container based on torizon/weston-vivante:2 image (enabling usage of csi display in weston config file)
  • Uno container based on torizon/dotnet-uno-debug:3.1.0-8.0.2 image

I understand that Toradex decided to move away from Uno but I don’t think this is related to Uno itself, I’m trying to understand if GPU for example is being used on the Plus, because everything was fine with the Mini.

I had a look around (here and here) and it seems like the torizon/weston-imx8:4 is used. I tried to run it (again, enabling the usage of CSI), and I’m getting failed to initialize g2d renderer before the container closes. Is this only for Torizon 7? Here’s the entire output:

Attaching to weston-weston-imx8-1
weston-weston-imx8-1  | Switching VT tty1 to text mode if currently in graphics mode
weston-weston-imx8-1  | Switching to VT 7
weston-weston-imx8-1  | SoC is: 'i.MX8MP'
weston-weston-imx8-1  | SoC has GPU: true
weston-weston-imx8-1  | SoC has DPU: false
weston-weston-imx8-1  | g2d implementation: viv
weston-weston-imx8-1  | Removing previously created '.X*-lock' entries under /tmp before starting Weston. Pass 'IGNORE_X_LOCKS=1' environment variable to Weston container to disable this behavior.
weston-weston-imx8-1  | dos2unix: converting file /etc/xdg/weston/weston.ini to Unix format...
weston-weston-imx8-1  | dos2unix: converting file /etc/xdg/weston-dev/weston.ini to Unix format...
weston-weston-imx8-1  | 00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound seat seat0
weston-weston-imx8-1  | 00:00:00.000 [INFO] [seatd/seatd.c:194] seatd started
weston-weston-imx8-1  | Date: 2025-06-27 UTC
weston-weston-imx8-1  | [12:04:04.971] weston 12.0.4
weston-weston-imx8-1  |                https://wayland.freedesktop.org
weston-weston-imx8-1  |                Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
weston-weston-imx8-1  |                Build: 12.0.4
weston-weston-imx8-1  | [12:04:04.972] Command line: weston -Bdrm-backend.so -Swayland-0 --use-g2d
weston-weston-imx8-1  | [12:04:04.972] OS: Linux, 5.15.148-6.6.1-devel+git.23a8e831749d, #1-TorizonCore SMP PREEMPT Tue Apr 25 12:27:41 UTC 2023, aarch64
weston-weston-imx8-1  | [12:04:04.972] Flight recorder: enabled
weston-weston-imx8-1  | [12:04:04.972] Using config file '/etc/xdg/weston-dev/weston.ini'
weston-weston-imx8-1  | [12:04:04.972] Output repaint window is 7 ms maximum.
weston-weston-imx8-1  | [12:04:04.973] Loading module '/usr/lib/aarch64-linux-gnu/libweston-12/drm-backend.so'
weston-weston-imx8-1  | [12:04:04.980] initializing drm backend
weston-weston-imx8-1  | [12:04:04.980] Trying libseat launcher...
weston-weston-imx8-1  | 00:00:00.020 [INFO] [seatd/server.c:145] New client connected (pid: 29, uid: 1000, gid: 1000)
weston-weston-imx8-1  | 00:00:00.020 [INFO] [seatd/seat.c:170] Added client 7 to seat0
weston-weston-imx8-1  | 00:00:00.020 [INFO] [seatd/seat.c:480] Opened client 7 on seat0
weston-weston-imx8-1  | [12:04:04.981] [libseat/libseat.c:73] Seat opened with backend 'seatd'
weston-weston-imx8-1  | [12:04:04.981] [libseat/backend/seatd.c:212] Enabling seat
weston-weston-imx8-1  | [12:04:04.981] libseat: session control granted
weston-weston-imx8-1  | [12:04:04.986] using /dev/dri/card0
weston-weston-imx8-1  | [12:04:04.986] DRM: supports atomic modesetting
weston-weston-imx8-1  | [12:04:04.986] DRM: does not support GBM modifiers
weston-weston-imx8-1  | [12:04:04.986] DRM: does not support async page flipping
weston-weston-imx8-1  | [12:04:04.986] DRM: supports picture aspect ratio
weston-weston-imx8-1  | [12:04:04.987] Loading module '/usr/lib/aarch64-linux-gnu/libweston-12/g2d-renderer.so'
weston-weston-imx8-1  | g2d_open: fail with status -7
weston-weston-imx8-1  | [12:04:04.998] g2d_open fail.
weston-weston-imx8-1  | [12:04:04.998] g2d_renderer_create faile.
weston-weston-imx8-1  | [12:04:04.998] failed to initialize g2d renderer
weston-weston-imx8-1  | 00:00:00.038 [INFO] [seatd/seat.c:418] No clients on seat0 to activate
weston-weston-imx8-1  | 00:00:00.039 [INFO] [seatd/seat.c:524] Closed client 7 on seat0
weston-weston-imx8-1  | 00:00:00.039 [INFO] [seatd/seat.c:192] Removed client 7 from seat0
weston-weston-imx8-1  | 00:00:00.040 [INFO] [seatd/client.c:471] Client disconnected
weston-weston-imx8-1  | 00:00:00.097 [INFO] [seatd/seatd.c:218] seatd stopped
weston-weston-imx8-1  | Switching back to vt 1
weston-weston-imx8-1 exited with code 139

So, does anyone have any idea why a GUI would be very slow after moving to a Plus?
Resource usage looks fine by the way.

Regards,
Joao

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello Joao,

Thank you for your detailed description and logs.

Background

Your analysis is spot on: the g2d_open: fail with status -7 and related Weston’s failed to initialize g2d renderer messages indicate that the GPU acceleration is not being properly leveraged by the Weston compositor. This can lead to extremely slow GUI performance, as rendering will fall back to software rather than utilizing the hardware GPU effectively.

This issue commonly arises from either:

  • Using the wrong Weston container/image for your i.MX8M Plus,
  • Missing access to the required device nodes inside the container,
  • Or not accepting the NXP EULA via the required environment variable.

Recommendations

1. Use the Correct Weston Container

For i.MX8M Plus, you should use the Vivante-specific Weston container (torizon/weston-vivante:<tag>), not torizon/weston-imx8 unless specifically targeting Toradex TorizonCore 6.7.0 or later with its new unified image design. Since you’re on Torizon 6.6.1, stick with torizon/weston-vivante.

Details:

2. Docker Compose: Device Access Rules and EULA

Make sure your docker-compose configuration for Weston (torizon/weston-vivante) grants access to all required GPU and video device nodes, and the NXP EULA is accepted. Here is a recommended compose snippet for your weston service:

services:
  weston:
    image: torizon/weston-vivante:2
    environment:
      - ACCEPT_FSL_EULA=1
    network_mode: host
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /run/udev
        target: /run/udev
    cap_add:
      - CAP_SYS_TTY_CONFIG
    device_cgroup_rules:
      - 'c 4:0 rmw'
      - 'c 4:1 rmw'
      - 'c 4:7 rmw'
      - 'c 13:* rmw'
      - 'c 226:* rmw'
      - 'c 199:0 rmw'
      - 'c 253:* rmw'

Reference:

3. Verifying GPU Node and Permissions

Check if these device nodes exist on your i.MX8M Plus and are accessible within the container:

  • /dev/dri/card0 (GPU)
  • /dev/video* (for video devices)
  • /dev/galcore, /dev/mxc_g2d (for Vivante)

You can verify inside the container with:

ls -l /dev/dri/card0
ls -l /dev/galcore
lsmod | grep galcore

Additional Notes

  • If you use a custom Weston configuration file, ensure it includes the necessary backend and renderer adjustments for Vivante GPU.
  • Test with a minimal GUI application to ensure baseline performance.

Summary

  • Use torizon/weston-vivante:2 on Torizon 6.6.1.
  • Make sure your docker-compose grants all device access and sets ACCEPT_FSL_EULA=1.
  • Double-check device nodes and permissions.
  • Avoid torizon/weston-imx8 on Torizon 6.6.1; it’s intended for later versions.

Let me know if updating your Weston setup as above solves the performance issue. If not, please share your current docker-compose file and weston.ini.

Best regards,
Toradex AI Assistant.

3

Hello John,

Thanks for providing all the relevant information. It looks like you are using an older version of weston-vivante image. Could you please try using torizon/weston-vivante:3 with your Torizon OS 6 image? Also, I noticed that you are working on an older Torizon OS version as well. Could you please try with Torizon OS 6.8.y?

And, yes torizon/weston-imx image is built for Torizon OS 7. It might be problematic for you to switch to Torizon OS 7 since the Uno template is unavailable for this version.

Lastly, you can view the GPU usage on the i.MX8MP, I recommend that you use the gputop package. The software is provided by NXP but we have packaged it in a way that makes it easy to setup when using containers.

When you want to check the usage of the different units in the GPU, you can just run a container and install the gputop package:

docker run -it -e ACCEPT_FSL_EULA=1 --rm --privileged torizon/weston-vivante:3

Once within the container:

apt update && apt install -y gputop

gputop

Let me know how these tests go.

4

Hi Rudhi,

I confirm that moving to torizon/weston-vivante:3 worked, no more lag in the GUI.

I couldn’t however launch gputop from within the container, but I guess that’s a separate issue:

Failed to mount debugfs. Make sure you are root!
Failed to mount debugfs!
Failed to init debugfs
Segmentation fault

Regards,
Joao

5

Hello @jvieira,

Glad to hear that it worked.

I couldn’t however launch gputop from within the container, but I guess that’s a separate issue

That’s because you are running the container without --privileged tag (which is not recommended for production by the way). With this tag, it should work.

1 Like