I have a Slint application running in a docker container, which is performing really badly. There is a lot of lag, and a camera stream is maybe averaging 5 fps…
When running my application with perf, I can see that the openGL driver is using the CPU instead of the GPU for quite some time… (gcoSURF_BlitCPU)
Has anyone seen something similar? Is this an iMX8 problem?
As reference, i’m on a Verdin i.MX8MP on the dev board using the onboard HDMI, TorizonOS 6.8.1. As for the container, I’m using the Slint Rust template, with the Skia renderer.
tdx-info:
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 5.15.148-6.8.1-devel+git.52a93ab38b43 #1-TorizonCore SMP PREEMPT Wed Nov 13 06:12:19 UTC 2024
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.0/torizon/1da3ef340da2da8d8771febeca29705d224f6a72938079a6829201085daa0e53/0 clk-imx8mp.mcore_booted=1 quiet loglevel=0
Distro name: NAME="TorizonCore"
Distro version: VERSION_ID=6.8.1-devel-20241215-build.722
Distro variant: VARIANT="Docker"
Hostname: verdin-imx8mp-15337625
------------------------------------------------------------
Hardware info
------------------------------------------------------------
HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version: 0064 V1.1A
Serial number: 15337625
Processor arch: aarch64
------------------------------------------------------------
I’m not quite sure where the issue lies here. Is this a bug in Skia? Or the OpenGL driver?
Any inputs would be helpful!
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Tim,
I’m sorry to hear about the performance issues you’re experiencing with your Slint application on the Verdin i.MX8MP. It sounds like the application isn’t utilizing the GPU as expected, which can indeed lead to high CPU usage and lag.
Here are some steps you can take to troubleshoot and potentially resolve this issue:
Verify GPU Driver Installation: Ensure that the GPU drivers are correctly installed and configured on your TorizonCore system. The i.MX8MP should support GPU acceleration, so it’s important to confirm that these drivers are active and properly set up.
Container Configuration: Check that your Docker container is configured to allow GPU access. This typically involves ensuring that the container has the necessary permissions to access GPU devices. You can do this by using the --device flag in your docker run command to map the GPU device, such as /dev/galcore, into the container.
OpenGL and Skia Configuration: Since you’re using the Skia renderer, make sure it is configured to use hardware acceleration. Sometimes, additional configuration or environment variables are needed to enable GPU acceleration in graphics libraries.
Review Application Code: Ensure that your application is designed to leverage GPU acceleration. This might involve reviewing the code to ensure that OpenGL calls are optimized for GPU execution.
By following these steps, you should be able to identify whether the issue lies with the driver, the container setup, or the application itself. If the problem persists, further investigation into the specific OpenGL calls and their execution paths might be necessary to ensure they are being offloaded to the GPU as expected.
I hope this helps you improve the performance of your application.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
The Slint templates themselves come from our partners rather than from Toradex directly. By posting this issue on the Github repo we can more easily bring in the Slint maintainers themselves and have them take a look with their expertise on the matter.
Just to clarify: We’ve diagnosed this issue a little together, and we’ve had another customer of ours run into the same issue:
Skia’s anti-aliased path renderer triggers a code path in the Vivante OpenGL driver that appears to cause a CPU fallback of sorts. As you can see in the perf report, 60%+ of CPU time is spent in a GPU driver that’s supposed to offload to the GPU, but instead it ends up doing work on the CPU (gcoSURF_BlitCPU).
I’m fairly convinced that this is not a bug in Slint, but Skia somehow triggers what to me strongly looks like a bug in the OpenGL driver.
@jeremias.tx We’ve also tried the FemtoVG renderer, but there the render quality of text was quite lacking, which is a no-go for our use case. We already have an application with Skia running on an i.MX7, where is is actually quite smooth, so the upgrade to the i.MX8 is not yet really looking like an upgrade right now…
We obviously hope that this bug can somehow be avoided or fixed. In the meantime we’re still trying different workarounds, also using Vulkan instead of OpenGL, but this is still in progress.
We obviously hope that this bug can somehow be avoided or fixed. In the meantime we’re still trying different workarounds, also using Vulkan instead of OpenGL, but this is still in progress.
To be honest with you the Vivante OpenGL driver is out of Toradex’s maintainer-ship. So, if the issue really is with this driver then it would need to be raised with the proper maintainers and it would be up to their discretion to address it. What further complicates this is that the Vivante graphics stack is largely proprietary and under the chip vendor (NXP), so we don’t have much visibility here.
With regards to Vulkan, this is relatively untested. At least it’s not something I see others use very often even in NXP in general.
I guess with what you said though, you are fairly set on using something Skia-based for your graphical application?
Yes, if possible. What is working fairly well for now is the Software-renderer, a bit ironic since we now have a GPU available… But maybe this will be the workaround for now, it is a bit depending on how our application evolves, the main worry here is the camera stream we have. But in our demo app it looks stable and is not eating away too many CPU resources.
I see, well that is good to hear at least. If you have any further issues or hit a bottleneck then do let us know. We could at least try to escalate this to the responsible parties like NXP. That said this issue is largely out of our control so it would be hard to guarantee to you any kind of timeline or priority since it wouldn’t be Toradex working on this.
