HW acceleration in Chromium on Torizon 7 running on Verdin iMX8MP

Toradex did a great job in investigating and improving HW acceleration on Verdin iMX8MP (Vivante GPU).
Torizon OS 7.1.0+build.4 + torizon/chromium-imx8:4.4.0 included a lot of improvements.
Now it’s not clear to me what is the hardware limit, and/or there is some space for improvements/bug-fixing from NXP side. I’ve been waiting for an answer from NXP tech support.

I try to share what I saw, and what I did, and maybe @leon.tx (who is the toradex expert) can share his thoughts too.
If I go to chrome://gpu page I see some interesting items:

Graphics Feature Status

  • Canvas out-of-process rasterization: Disabled
  • WebGPU: Disabled

Problems Detected

  • WebGPU has been disabled via blocklist or the command line.
    Disabled Features: webgpu
  • On Vivante GPUs MSAA performance is not acceptable for GPU rasterization
    Applied workarounds: msaa_is slow

It’s not clear to me what is exactly (I understand it’s new and experimental) and which kind of benefits it could bring, but I’ve been able to change WebGPU to Enable adding this command line parameter when launching chromium
--enable-unsafe-webgpu
I don’t know if something changes, but I can see the examples here, so I think that for now it’s better to leave this Disabled.

I’ve been able to enable Canvas out-of-process rasterization adding the following parameters:

--enable-features=CanvasOopRasterization
--enable-gpu-compositing
--enable-gpu-rasterization
--enable-oop-rasterization
--canvas-oop-rasterization

Not sure which kind of improvements this can add, and how to test them.
Any idea?

For the item

On Vivante GPUs MSAA performance is not acceptable for GPU rasterization
Applied workarounds: msaa_is slow

I suspect either some issue from NXP side (because I see it listed under “Problems Detected” section), or a HW limit of the Vivante GC7000UL platform.
@leon.tx do you have an idea on this?

I put here these thoughts because I read that HW acceleration for web application has become a hot topic on this community and it seems that performance on native applications can be high, but on web applications are quite poor on iMX8MP.
And NXP it not so clear defining which is the HW limit and which is the technology (web) limit.

I hope that this can help.

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

You’ve made significant progress in exploring hardware acceleration features in Chromium on the Verdin iMX8MP with Torizon 7.1.0. Let’s address your observations and questions:

  1. WebGPU and Canvas Out-of-Process Rasterization:

    • WebGPU: This is an experimental feature designed to enhance graphics performance in web applications. While enabling it with --enable-unsafe-webgpu allows testing, it may not be stable or fully supported on all hardware, so proceed with caution.
    • Canvas Out-of-Process Rasterization: This feature can improve rendering performance by offloading rasterization tasks to separate processes, potentially enhancing responsiveness and reducing main thread load. The flags you’ve used are correct for enabling this feature.
  2. Testing Improvements:

    • To assess the impact of these changes, utilize performance profiling tools available in Chromium’s developer tools. Monitor rendering times and frame rates to evaluate improvements when these features are enabled.
  3. MSAA Performance on Vivante GPUs:

    • The issue with MSAA (Multisample Anti-Aliasing) performance is a known limitation of the Vivante GC7000UL GPU, likely due to hardware constraints. The workaround (msaa_is_slow) is applied to mitigate performance degradation by disabling MSAA where it’s not beneficial.
  4. Hardware and Software Limitations:

    • The performance limitations you’re experiencing may be inherent to the hardware capabilities of the Vivante GPU. While software optimizations can help, they cannot overcome fundamental hardware constraints. Keep an eye on updates from NXP and Toradex for any software optimizations or patches that could improve performance.

In summary, while enabling these features can potentially improve performance, the extent of improvement is constrained by the hardware. Continue experimenting with these settings to find the best configuration for your application needs.

Best regards,
Toradex AI Assistant.

Please, also check if these links can help you solve your problem:

GPU performance in Chromium container on Torizon OS iMX8M-Plus.

Hey Vix,

that’s a pretty cool investigation, we honestly haven’t really looked much in terms of how different flags affect the performance - it’s even a bit hard to find the flags as they’re completely undocumented ‘officially’.

I suppose the out-of-process rasterization should be mainly for applications where you don’t want the rendering process to kill the main browser process, but not sure of the performance implications of this; I think there might be some overhead associated with having a different process altogether, but it’s not just about performance.

I suspect either some issue from NXP side (because I see it listed under “Problems Detected” section), or a HW limit of the Vivante GC7000UL platform.

This is probably not on NXP’s side but a regular workaround Chromium is applying to the process during bring-up - we would need to check the source code to see if it’s doing some kind of pre-benchmark on start-up or if it’s a simple pattern matching.

performance on native applications can be high, but on web applications are quite poor on iMX8MP

We’ve been doing quite a bit to remedy those discussions. I’ve added a section on the reference docs for Chromium about this in the effort of being more upfront about the potential performance penalty when using a web-browser as well as talking to several customers to properly identify their use-cases and issues when using Chromium. I hope this clarifies things a bit further.

Again, thanks for the investigation, this is really useful stuff :slight_smile:

Hi @leon.tx

yes, this is a mess, but it’s true.
No official documentation on the possible flags.
You have to dig into source code :scream:

Hi @leon.tx
I add something else.
From the last NXP i.MX Linux Release Notes I read (page 10):

Upgraded the kernel to 6.6.52 with consolidated Linux Factory Kernel.

Graphics updates:
– GPU driver upgraded to 6.4.11.p2.10 with Vulkan enablement, bug fixes, and performance optimizations.
– GPU SDK upgraded to 6.2.4.
– Chromium upgraded to 117.0.5938.132

I think this is what Torizon OS 7.1.0+build.4 is based on.
From tdx-info I see

Kernel version:           6.6.54-7.1.0-g3493ccd66900 #1-Torizon SMP PREEMPT Tue Dec 17 21:04:41 UTC 2024

notice kernel 6.6.52 (in NXP) vs 6.6.54 (from tdx-info).

In this topic on NXP community, one of NXP engineers says that Vulkan is enabled on iMX8MP and suggests some flags to enable it.
I’ve just verified that the above flags don’t work (and I reported this in that topic on NXP community).

Soon or later, we’ll come to an end… maybe