5.1. Chromium Browser - User Guide

5.1.1. Overview

On TI devices with IMG Rogue class GPUs. The Chromium browser (available from https://chromium.googlesource.com/chromium/src/) is accelerated using OpenGLES.

The version of Chromium that is built can be obtained with this command:

$ chromium --version
Chromium 132.0.6834.83 stable

The version of Chromium shown here is the one that GPU acceleration is verified to work with.

5.1.2. Launching Chromium Browser

Danger

For security reasons it is suggested never to run Chromium as the root user.

To launch the Chromium browser (assuming you are logged in as root):

Switch to the weston user:

$ su weston

Then run the chromium binary:

$ /usr/bin/chromium [url] [options]

e.g.

$ chromium https://www.ti.com

Will open www.ti.com in a windowed browser on the Weston desktop.

$ chromium https://webglsamples.org/aquarium/aquarium.html --start-fullscreen

Will open the aquarium 3d benchmark in a fullscreen window on the Weston desktop.

The --start-fullscreen switch will make the chromium browser consume the entire screen including overwriting the Weston menu bar.

This will start Chromium. With network connectivity, it will connect to an example application that uses WebGL/Javascript and renders fish swimming in a fish bowl using the 3D GPU.

5.1.3. Graphics Feature Status

To see the GPU features that are in use, enter chrome://gpu into the Chromium URL/Navigation bar. A web page will be rendered with this information. The below example shows what is enabled/disabled when GPU acceleration is working correctly.

*   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
*   Raw Draw: Disabled
*   Video Decode: Hardware accelerated
*   Video Encode: Software Only. Hardware acceleration disabled
*   Vulkan: Disabled
*   WebGL: Hardware accelerated
*   WebGL2: Hardware accelerated
*   WebGPU: Disabled

If for some reason you suspect the GPU is rendering something incorrectly, you can run chromium with GPU disabled using the --disable-gpu flag:

$ chromium https://webglsamples.org/aquarium/aquarium.html --start-fullscreen --disable-gpu

To get raw performance numbers from the GPU, you may want to disable frame sync locking in Chromium. This will tell Chromium never to wait for VSYNC and render as fast as the GPU can achieve.

$ chromium https://webglsamples.org/aquarium/aquarium.html --start-fullscreen --disable-gpu-vsync --disable-frame-rate-limit

5.1.4. Running Chromium as the root user

This is absolutely not recommended, as to do so gives a web page too much access to your system. To run in this mode you also have to provide the --no-sandbox switch, which disables all sandboxing of the browser from the base system and could leave you open for a malicious webpage to do something nefarious.

5.1.5. How to build Chromium under Yocto

Pull in the meta-browser and meta-lts-mixins layer into a Scarthgap Yocto build.

meta-browser should be pinned to commit:

commit 27ca52f635a31f5f9762813a8527dd31323549b7
Author: Ariel D'Alessandro <ariel.dalessandro@gmail.com>
Date:   Thu Feb 20 06:59:07 2025 -0300

    chromium: Update to 132.0.6834.83 (#867)

meta-lts-mixins should be pinned to commit:

commit a8046d5ec53b1856169ac795aa87cb0d5db84c04
Author: Khem Raj <raj.khem@gmail.com>
Date:   Wed Apr 30 23:33:39 2025 -0700

    rust: Fix build with GCC-15 on aarch64/musl

With these layers pinned to the correct commit, you need to make sure they are referenced in build/conf/bblayers.conf. This is done automatically if you use the oe-layersetup tool.

$ cd yocto_dir
$ ./oe-layersetup -f config/arago-scarthgap-chromium-config.txt

Once this is done, use bitbake to create the tisdk-default-image. This will detect the meta-browser and meta-lts-mixins layers, automatically building and adding Chromium to the root filesystem image.

Tip

Build times of Chromium can be very long depending on the size of your build machine. It has been found that you need at least 64 GB of RAM, and on a 28 thread Intel Core-I9 with an SSD for the build driver it will still take upwards of 2 hours just to build Chromium. A full Yocto Scarthgap build that includes Chromium can easily take 400GBytes of SSD.

The following will initiate a full tisdk-default-image build that would include Chromium if the meta-browser and meta-lts-mixins layers are present:

$ MACHINE=<machine> bitbake tisdk-default-image

If you want to significantly reduce image size, the IPKs can be built directly using the following:

$ MACHINE=<machine> bitbake core-image-weston
$ MACHINE=<machine> bitbake chromium-ozone-wayland

Where <machine> is defined in the Build Options section of “Building the SDK with Yocto”

tisdk-default-image is the only image that chromium will get built into by default. If you want to build it into another image, then you would need to modify the .bb recipe for the image. Or alternatively add the line:

IMAGE_INSTALL:append = " chromium-ozone-wayland"

Somewhere into your build/conf/local.conf file.

5.1.6. Limitations

Hardware acceleration of video encode is not supported.

5.1.7. Performance

Performance of WebGL Aquarium

Standard WebGL benchmarks available at these URLs: https://webglsamples.org/aquarium/aquarium.html

Run as the weston user with the command line chromium https://webglsamples.org/aquarium/aquarium.html --start-fullscreen

Platform	Performance FPS
J722S	33 @ 1080p60

Performance of MotionMarkv1.3

Standard Javascript benchmarks available at these URLs: https://browserbench.org/MotionMark/

Run as the weston user with the command line chromium https://browserbench.org/MotionMark/ --start-fullscreen use the mouse to click the “Run Benchmark” button.

Platform	MotionMark v1.3
J722S	37.56 @ 1080p60

5.1.8. Video Streaming

Streaming platforms and demuxed videos support hardware acceleration for video playback. This is achieved using the V4L2 stateful decoder API that interfaces with the Wave5 hardware decoder present on J722S. Hardware acceleration has been successfully verified with the W3C WebCodecs VideoDecoder Interface, which serves as the backend technology for streaming platforms such as YouTube and Vimeo.

Tested streaming sources include HTML5, YouTube, and Vimeo video playback.

HTML5 Video Playback

An HTML5 video is a standard video element embedded directly into a webpage by using the <video> tag. Unlike platforms such as YouTube or Vimeo, which run within complex web applications containing ads, thumbnails, and JavaScript-heavy interfaces, HTML5 video playback delivers the raw video stream directly to the browser’s player.

This makes it ideal for testing hardware decoding performance, as it avoids additional CPU load from webpage rendering and scripting.

$ chromium http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4

Vimeo Streaming

Vimeo commonly uses the H.264 codec for playback.

Vimeo is supported by hardware acceleration through the V4L2 decoder. Unlike YouTube, Vimeo does not dynamically switch codecs based on system capability and generally delivers consistent H.264 streams across devices, making it more predictable for hardware decoding tests.

$ chromium https://player.vimeo.com/video/640499893

YouTube Streaming

YouTube commonly uses VP9 or AV1 codecs for playback, which are not hardware accelerated on this platform. Chromium falls back to software decoding when using those codecs, resulting in high CPU usage, especially at higher resolutions.

To enable hardware acceleration, Chromium requires an extension that forces YouTube to use the H.264 codec. With this extension installed, YouTube streams are hardware decoded using the V4L2 decoder.

$ chromium https://www.youtube.com/embed/R6MlUcmOul8

Note

YouTube and Vimeo perform best when played in an embedded player, as loading the full webpage and thumbnails is CPU-intensive.
Chromium performs Audio decoding using software, as hardware acceleration for audio streams is not supported.
Tested resolutions are up to 1080p30. Higher resolutions might work depending on the platform capabilities.
Hardware accelerated encoding for WebRTC is not currently supported.
Only H.264 codec videos encoded in YUV420 8-bit format are hardware accelerated. Other codecs and formats will fall back to software decoding.

Hardware Acceleration Performance

Platform	Website	CPU Utilisation	GPU Utilisation
J722S	YouTube	41.21%	10%
J722S	Vimeo	62.39%	13%

Software Acceleration Performance

Platform	Website	CPU Utilisation	GPU Utilisation
J722S	YouTube	213.02%	13%
J722S	Vimeo	157.86%	11%

Note

The tests were performed using the Big Buck Bunny video at 1080p24 for Vimeo and Tears of Steel at 1080p30 for YouTube at full screen.