--in-process-gpu: yes or no for chromium on iMX8M-Plus?

Technical Support
, ,
1

The topic has been already discussed several times in the past, but I don’t know what is the official answer now (October 2026).

In the torizon containers I see it’s used torizon-containers/support-files/chromium/start-chromium.sh at d21f5032d19a0fa5434d2dd2c8d181d583bc5220 · torizon/torizon-containers · GitHub so I think it should be used (but, shouldn’t a process isolation be better?).

An answer on this forum says that removing this flag makes everything more stable on iMX8M-Plus.

Has this flag impact on CPU usage? I would like using everything at the best and iMX8M-Plus doesn’t have resources to be wasted…

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.

Based on the available documentation, I can confirm that GPU acceleration on Chromium for iMX8M Plus modules requires the --in-process-gpu flag.

According to the documentation, hardware acceleration increases performance by moving graphics and text rendering from the CPU to the GPU. To enable GPU acceleration on Chromium, you must use the --in-process-gpu switch(1).

The documentation shows this example for enabling GPU acceleration:

# chromium --no-sandbox --in-process-gpu

(1)

Regarding CPU Usage and Performance:

Using the --in-process-gpu flag should reduce CPU usage, not increase it, because it offloads graphics rendering tasks from the CPU to the GPU. The iMX8M Plus features the Vivante GC7000UL GPU with eight Vega shader cores(2)(3), which is specifically designed to handle graphics acceleration efficiently.

Important Consideration:

The documentation notes that you should verify GPU acceleration is working by checking chrome://gpu in your browser. You should see the Graphics Feature Status list confirming hardware acceleration is enabled(1).

However, I don’t have specific information in the available sources about stability issues when using or removing the --in-process-gpu flag on iMX8M Plus, or official guidance on whether to use it or not for your specific use case. For the most current recommendations and any known stability considerations, I’d suggest checking the Toradex Community or GitHub for recent discussions on this topic.

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

One of the main reasons for my request is that I’ve just discovered one thing that I can’t believe.

If I add a small animation to my UI (50 x 50 pixels), the CPU load of chromium jumps from almost 0% to 70% :distorted_face:
Is seems that the compositor redraws the whole frame on every animation frame, not just the animated area!!

In this condition the browser is overloaded when real necessary job comes.

This is not acceptable and I hope that this comes form a wrong setting from my side.

Can someone from toradex confirm that partial updates are available on the platform?

If @ToradexAI can help, try, but give valuable info

4

I don’t have specific information in the available sources about Chromium’s compositor behavior regarding partial updates versus full-frame redraws on the iMX8M Plus platform, or about configuration settings that would control this behavior.

The high CPU usage you’re experiencing with a small animation (jumping from 0% to 70%) suggests that hardware acceleration may not be working as expected, or that the compositor is indeed redrawing more than necessary. However, I cannot confirm from the available documentation whether partial updates are supported or how to enable them.

To get a definitive answer about:

  • Whether partial updates are available on the platform
  • Compositor configuration options for Chromium on iMX8M Plus
  • Recommended settings to optimize rendering performance
  • Whether this behavior is expected or indicates a configuration issue

I recommend visiting the Toradex Community or GitHub where you can get specific technical guidance from Toradex engineers who can address your performance concerns with authoritative information.

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.

5

This is the output from chrome://gpu

Graphics Feature Status
- Canvas: Hardware accelerated
- Canvas out-of-process rasterization: Disabled
- Direct Rendering Display Compositor: Disabled
- Compositing: Hardware accelerated
- Multiple Raster Threads: Enabled
- OpenGL: Enabled
- Rasterization: Hardware accelerated on all pages
- Raw Draw: Disabled
- Skia Graphite: Disabled
- Video Decode: Hardware accelerated
- Video Encode: Software only. Hardware acceleration disabled
- Vulkan: Disabled
- WebGL: Hardware accelerated
- WebGL2: Hardware accelerated
- WebGPU: Disabled

Driver Bug Workarounds
- clear_uniforms_before_first_program_use
- enable_webgl_timer_query_extensions
- exit_on_context_lost
- msaa_is_slow
- disabled_extension_GL_KHR_blend_equation_advanced
- disabled_extension_GL_KHR_blend_equation_advanced_coherent

Problems Detected
- WebGPU has been disabled via blocklist or the command line.
  Disabled Features: webgpu
- Accelerated video encode has been disabled, either via blocklist, about:flags or the command line.
  Disabled Features: video_encode
- Clear uniforms before first program use on all platforms: 124764, 349137
  Applied Workarounds: clear_uniforms_before_first_program_use
- Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
  Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
- Expose WebGL's disjoint_timer_query extensions on platforms with site isolation: 808744, 870491
  Applied Workarounds: enable_webgl_timer_query_extensions
- Some drivers can't recover after OUT_OF_MEM and context lost: 893177
  Applied Workarounds: exit_on_context_lost
- On Vivante GPUs MSAA performance is not acceptable for GPU rasterization
  Applied Workarounds: msaa_is_slow

Version Information
Data exported              2026-10-16T16:14:24.892Z
Chrome version             Chrome/117.0.5938.132
Operating system           Linux 6.6.119-7.5.0-ge5c5595adb06

@ToradexAI is this what toraex expects?

6

Based on your chrome://gpu output, I can see that hardware acceleration is enabled for the key graphics features:

  • Canvas: Hardware accelerated ✓
  • Compositing: Hardware accelerated ✓
  • Rasterization: Hardware accelerated on all pages ✓
  • WebGL/WebGL2: Hardware accelerated ✓
  • Video Decode: Hardware accelerated ✓

However, I notice some features that are disabled or showing workarounds specific to Vivante GPUs:

Key Observations:

  1. “msaa_is_slow” workaround - The output shows: “On Vivante GPUs MSAA performance is not acceptable for GPU rasterization”. This is a known limitation for the Vivante GPU used in iMX8M Plus(1)(2).

  2. Canvas out-of-process rasterization: Disabled - This could impact rendering performance.

  3. Direct Rendering Display Compositor: Disabled - This might be relevant to your compositor redraw issue.

Regarding Your Performance Issue:

Unfortunately, I don’t have specific documentation from Toradex that addresses:

  • Expected compositor behavior for partial updates vs. full-frame redraws
  • Whether the 70% CPU usage for a small animation is normal
  • Configuration options to optimize compositor performance for your use case

The available sources confirm that Chromium on iMX8M Plus supports GPU acceleration(3) and that the iMX8M Plus features the GC7000 UltraLite GPU(1)(2), but they don’t provide detailed guidance on compositor optimization or partial update capabilities.

Recommendation:

To get authoritative answers about whether this compositor behavior is expected and how to optimize it, I recommend visiting the Toradex Community or GitHub where Toradex engineers can provide specific technical guidance on Chromium compositor configuration for your platform.

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.

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.

7

Hi @vix,

Note: Claude (an AI assistant) wrote this answer for me, from our own test notes. All the results come from our tests on a Verdin iMX8M Plus with Torizon OS 7 and torizon/chromium-imx8:4 (Chrome 117, the same version as yours), on a full-HD screen.

--in-process-gpu

In our tests, we needed it for a smooth frame rate. Without it, we got about 20 fps, and the GPU was almost idle. The flag does not move work to the GPU. It runs the GPU process inside the browser process, so each frame does not have to go between two processes.

But use it together with --disable-gpu-rasterization and --disable-gpu-memory-buffer-video-frames. With --in-process-gpu alone, our performance got worse, and SVG drawings had glitches. The GPU flags we run today:

--ozone-platform=wayland --use-gl=egl --no-sandbox --in-process-gpu --disable-gpu-rasterization --disable-gpu-memory-buffer-video-frames --disable-gpu-vsync

--disable-gpu-vsync made our animations smoother: frames are no longer held back to wait for the screen refresh. We also play video with this set, and it is more fluid than before.

The start-chromium.sh you linked uses --in-process-gpu without --disable-gpu-rasterization. That is the combination that was worse for us. Your chrome://gpu matches it: “Rasterization: Hardware accelerated on all pages”. The script passes any extra -- flag to Chromium, so you can add the flags above as container arguments.

On this GPU, GPU rasterization was our main problem. --ignore-gpu-blocklist with --enable-gpu-rasterization froze the GPU, and only a reboot fixed it. --enable-zero-copy gave visual glitches, and --gpu-no-context-lost hung the process in the GPU driver.

The “remove this flag” advice in the other thread came from the AI bot, for a video lock-up.

Partial updates

We saw the same thing. The Vivante EGL driver does not do partial swaps. So for each animation frame, Chromium composes the full screen again, even when only a small area changes. contain: paint and will-change did not change that. With --in-process-gpu, this work runs in the browser process, which can explain your CPU load.

What helped us:

  • --disable-gpu-vsync (above). Before it, we limited the frame rate of our animations with CSS steps(), to leave the GPU some free time.
  • Animate only transform and opacity. Do not animate SVG geometry (SMIL <animate> on d, cx or r, stroke-dashoffset, <filter>), or box properties like border, border-radius or padding: Chromium then rasterizes again on the CPU for each frame.

It would be good to have Toradex confirm the partial-swap part.

Best regards,
M