Verdin AM62 - OpenGLES Hardware acceleration not working on newest version

Technical Support
, ,
1

Hello,

I recently encountered that my application works slower than usual (in my case it’s an Avalonia DRM app template). After some investigation I found out some weird results when running the eglinfo and kmscube -D /dev/dri/card0 commands. I’ve sent the logs in the files attached.

eglinfo_HWacc.log (33.5 KB)
eglinfo_no_HWacc.log (48.9 KB)
kmscube_HWacc.log (4.4 KB)
kmscube_no_HWacc.log (5.5 KB)

The temporary solution that works for me seems to be downgrading the ti-img-rogue-umlibs-am62 lib to version 24.2.6643903+git20250227.1ed9ee1-1 but I would rather not do that. Is there anything else I could do to avoid manually downgrading the library?

tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.106-7.4.0-g650792253644 #1-Torizon SMP PREEMPT Thu Sep 18 20:27:33 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/d0838a71184a4ce5ad80766190ae02885679714841d06ba0e0dbf180d4510eb6/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.4.0-build.28
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-am62-15380640
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin AM62 on Mallow Board
Toradex version:          0076 V1.1C
Serial number:            15380640
Processor arch:           aarch64
------------------------------------------------------------
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I see you’re experiencing performance issues with your Avalonia DRM application on the Verdin AM62 and have identified that downgrading the ti-img-rogue-umlibs-am62 library resolves the problem. Based on your setup details, you’re running Torizon OS 7.4.0-build.28 on a Verdin AM62 with Mallow Board.

Understanding Your Hardware Platform

Your Verdin AM62 features the TI AM62x SoC with PowerVR Rogue AXE-1-16M GPU that supports OpenGL ES 3.1 and Vulkan 1.2, providing up to 16 GFLOPs of graphics performance (1). The AM62x family is designed for cost-effective 64-bit performance while maintaining hardware-accelerated graphics capabilities (2).

Graphics Acceleration Context

The Verdin AM62 uses TI’s PowerVR-based GPU for hardware acceleration (1). When graphics libraries like ti-img-rogue-umlibs-am62 have compatibility issues, applications can fall back to software rendering, which significantly impacts performance - similar to what you’re experiencing.

Recommended Troubleshooting Steps

1. Container Configuration

Ensure your Avalonia DRM application container has proper GPU access and device mappings. For AM62-based applications, the container needs access to the appropriate DRI devices and GPU libraries.

2. Library Compatibility Investigation

Since downgrading the PowerVR userspace libraries resolves your issue, this suggests a regression or compatibility problem with the newer library version. Check if there are any known issues or updates available for the ti-img-rogue-umlibs-am62 package.

3. Alternative Solutions

  • Verify your container is using the correct GPU-enabled base images for AM62
  • Check if there are intermediate library versions available between your working downgraded version and the problematic current version
  • Review your application’s OpenGL/graphics API usage for any compatibility requirements

Community Resources

For similar graphics-related issues on Toradex platforms, you can check the community forums where other users have discussed GPU acceleration problems and solutions.

The fact that downgrading resolves your issue indicates this is likely a library regression rather than a fundamental hardware or configuration problem. I’d recommend reporting this as a potential bug with the specific library version details you’ve identified.

Best regards, Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hello @daniel.l !

In order to narrow this down more efficiently, could you please help us validate a few initial points:

  • In regards to where the application is running and what changed, could you please confirm whether the Avalonia application is running directly on the host OS or inside a Docker container? Additionally, did the performance degradation start after a Torizon OS update or after updating/rebuilding the container image? It would also be useful to know whether the slowdown happens immediately after boot or only after the system has been running for some time.

  • In regards to confirming whether GPU acceleration is actually active, please run the following command in the same environment where the application shows degraded performance and share the output: eglinfo -B

  • Lastly, about the containerized setups, if the application is running inside a container, please share how the container is being started (docker run or docker-compose). As a quick validation step, you can try running:

docker run --rm -it \
  --device /dev/dri:/dev/dri \
  --group-add video --group-add render \
  <your-image> \
  eglinfo -B

This helps verify whether the container has proper access to the DRM/GPU devices. If this changes the behavior, it would indicate that the issue is related to device access or permissions rather than the graphics library itself.

4

Hi João,

Answering your first question. The application runs in a docker container. A previously built image didn’t have these problems but it was due to the library still being in the older version. But I’ve also updated to Torizon OS 7.4.0 from 7.3.0 recently.

The results of eglinfo -B on the app with degraded performance can be seen in the log files I’ve sent, namely the eglinfo_no_HWacc.log and kmscube_no_HWacc.log

The container starts through docker-compose.yml like this:

  app:
    build:
        context: .
        dockerfile: Dockerfile
    image: ${DOCKER_LOGIN}/myApp:${TAG}
    network_mode: host
    # Required to get udev events from host udevd via netlink
    volumes:
      - type: bind
        source: /tmp
        target: /tmp
      - type: bind
        source: /dev
        target: /dev
      - type: bind
        source: /media
        target: /media
        bind:
          propagation: shared
      - type: bind
        source: /run/udev
        target: /run/udev
      - type: bind
        source: /sys/class/backlight/backlight
        target: /sys/class/backlight/backlight
      - type: bind
        source: /etc/os-release
        target: /etc/os-release-host
      - type: volume
        source: data
        target: /home/torizon/app/Data
      - type: volume
        source: videos
        target: /home/torizon/app/Videos
      - type: volume
        source: versions
        target: /home/torizon/app/Versions
    cap_add:
      - CAP_SYS_TTY_CONFIG
      - CAP_NET_BIND_SERVICE
    # Add device access rights through cgroup...
    device_cgroup_rules:
      # ... for tty
      - "c 4:* rmw"
      # ... for /dev/input devices
      - "c 13:* rmw"
      # ... for /dev/dri devices
      - "c 226:* rmw"
      - "c 199:* rmw"
      # ... for /dev/fb0
      - "c 29:* rmw"
      # ... for /dev/snd
      - "c 116:* rmw"
      # ... for /dev/gpiochip*
      - "c 254:* rmw"
5

Ok, based on the logs and the setup, there are some things we can try:

  • Verify which DRI drivers are available in the container and whether tidss_dri.so is present. If it is missing, Mesa will fall back to software rendering (llvmpipe), which explains the slowdown.
ls -l /usr/lib/aarch64-linux-gnu/dri/ | egrep "tidss|pvr|kms_swrast|swrast" || true
ls -l /usr/lib/dri/ | egrep "tidss|pvr|kms_swrast|swrast" || true
  • Check which DRM and Mesa-related packages are installed and which libraries eglinfo is linking against, to confirm whether the container is using generic Mesa instead of the Torizon/TI stack
dpkg -l | egrep "mesa|libegl|libgbm|libdrm|ti-img|rogue|pvr" || true
ldd $(which eglinfo) | egrep "libEGL|libgbm|libdrm" || true
  • Validate DRM device permissions and group membership. As a quick test, try running kmscube as root inside the container to see if the behavior changes.
id
ls -l /dev/dri
getent group video || true
getent group render || true

These will help us determine if the issue is a missing userspace driver in the container itself or a DRM ownership problem.

7

Actually, a colleague pointed out that what you’re seeing on the Verdin AM62 with Torizon OS 7.4.0 is a known interaction issue between this OS version’s graphics stack and newer TorizonCore container images.

The newer tag:4 container images (like 4.13.x) are built and validated against a newer Torizon OS release (7.5.0), which includes an updated TI graphics driver in the kernel. When these containers are used on Torizon OS 7.4.0, a mismatch happnes between the kernel-side graphics driver and the user-space TI graphics libraries in the container. Because of this, EGL and tools like kmscube typically fall back to software rendering, which is probably why you are getting the performance issues.

Instead of manually downgrading the ti-img-rogue-umlibs-am62 package on the host, the recommended approach on Torizon OS 7.4.0 is to pin your container base image to a container tag that matches this OS version. For example, using a 4.12.x tag (corresponding to the GPU/Weston-based image you are using in your Dockerfile) aligns the user-space graphics stack with the 7.4.0 kernel. After updating the FROM line, rebuilding, and redeploying the container, hardware acceleration should be restored.

If you prefer to keep using the latest tag:4 container images, the solution is to upgrade the module to Torizon OS 7.5.0, where the kernel and container graphics stacks are aligned by design.

8

Hi,

That was it exactly, after pulling the 4.12 version of the container everything works as before. Thank you for the help.

Best Regards
Daniel

9

Glad to be of help! If you have any other issues with your project, let us know!