[snap] chromium browser does not work with accelerated graphics on Tegra (arm64)

Bug #2028864 reported by Nicolas Dechesne
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Tegra Orin platforms come in various flavor / dev kit. They all ship with a 'slightly' customized Ubuntu image. One of the customization is the addition of the Nvidia GPU drivers for Tegra.

When running chromium browser debian package (either when running 18.04, or when running 22.04 with the package fetched from this PPA: https://launchpad.net/~nteodosio/+archive/ubuntu/chromium/+packages) then chromium works with hardware acceleration, as reported in 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
Raw Draw: Disabled
Video Decode: Hardware accelerated
Video Encode: Software only. Hardware acceleration disabled
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
WebGPU: Disabled

When using the snap version of chromium browser (on either 20.04 or 22.04), hardware acceleration is disabled, as shown in chrome://gpu:

Graphics Feature Status
Canvas: Software only, hardware acceleration unavailable
Canvas out-of-process rasterization: Disabled
Direct Rendering Display Compositor: Disabled
Compositing: Software only. Hardware acceleration disabled
Multiple Raster Threads: Enabled
OpenGL: Disabled
Rasterization: Software only. Hardware acceleration disabled
Raw Draw: Disabled
Skia Graphite: Disabled
Video Decode: Software only. Hardware acceleration disabled
Video Encode: Software only. Hardware acceleration disabled
Vulkan: Disabled
WebGL: Software only, hardware acceleration unavailable
WebGL2: Software only, hardware acceleration unavailable
WebGPU: Disabled
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
Gpu compositing has been disabled, either via blocklist, about:flags or the command line. The browser will fall back to software compositing and hardware acceleration will be unavailable.
Disabled Features: gpu_compositing

These tests are done with X11.

Revision history for this message
Nicolas Dechesne (ndec) wrote :
Revision history for this message
Nicolas Dechesne (ndec) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote (last edit ):

I suspect this is a general problem with Nvidia proprietary drivers being accessible in snaps. Not Tegra-specific.

First we will need apps to start using graphics-core22 instead of gnome-42-2204 to get OpenGL support. It might help if gnome-42-2204 is ported to use graphics-core22 first.

Second we'll want to verify that amd64 apps can now use nvidia-core22.

Third someone will need to add Tegra support to arm64 builds of nvidia-core22. That's probably better than creating a whole new 'tegra-core22' snap?

tags: added: arm64 nvidia snap tegra
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
Revision history for this message
Nicolas Dechesne (ndec) wrote :

Thanks for the additional information. You are referring to a lot of things which are quite new to me. That seems a non trivial problem to solve.

If I understand correctly, there are several problems here:

1. Applications should use graphics-core22 interface. But that interface does not seem to be used by chromium or firefox, or snap-store... does that mean that we can't get any acceleration until we fix that in each app?

2. We will need a specific graphics-core22 provide for Tegra. We might be able to leverage/reuse the nvidia-core22, but the tegra software stack is very different, so that would need some investigation..

But then I have more questions..

1. Who is supposed to 'install' the hardware specific provider? Users typically install chromium and expect it will just work. How will the chromium snap figure out that the nvidia graphics provider is installed? do we need to manually connect the interfaces?
2. Where can I find the nvidia-core22 snap definition (yaml)?
3. Is fixing these problems (outside of Tegra) already 'in the works'? If so is there a timeline? If i understand correctly these problems exist since 20.04, so they are definitely not new.

Revision history for this message
Daniel van Vugt (vanvugt) wrote (last edit ):

> 1. Who is supposed to 'install' the hardware specific provider? Users typically install chromium and expect it will just work. How will the chromium snap figure out that the nvidia graphics provider is installed? do we need to manually connect the interfaces?

AIUI, a machine only ever needs one graphics snap. So Tegra images in future should ship with a 'tegra-core22' or arm64 variant of 'nvidia-core22'. When it exists...

> 2. Where can I find the nvidia-core22 snap definition (yaml)?

https://github.com/snapcore/nvidia-core22 (supports amd64 AND arm64 but not sure if that's enough for Tegra)

> 3. Is fixing these problems (outside of Tegra) already 'in the works'? If so is there a timeline? If i understand correctly these problems exist since 20.04, so they are definitely not new.

Not as far as I can tell. I think:

 (a) The desktop team needs to own converting chromium to graphics-core22; and
 (b) No team yet owns the snapping of a "tegra-core22", although I'm curious what the existing arm64 support in nvidia-core22 covers.

Revision history for this message
Michał Sawicz (saviq) wrote :

Let me just add nvidia-core22 is geared at Ubuntu Core usage, not Classic (because of problems keeping the kernel driver and userspace in sync).

On Classic, SnapD exposes the proprietary Nvidia pieces in `/var/lib/snapd/lib/gl`. This is normally handled by snap wrappers (e.g. https://github.com/ubuntu/snapcraft-desktop-helpers/blob/ec861254c2a1d2447b2c589446e6cdf04c75c260/common/desktop-exports#L103-L109), and supported by mesa-core22.

So while moving snaps to graphics-core22 is an important piece on Core, it not working on Classic suggests something else needs looking at.

Check out https://snapcraft.io/graphics-test-tools, hopefully it can give you some insight as to what's missing.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This is not Classic. Chromium is fully confined AFAIK.

Revision history for this message
Michał Sawicz (saviq) wrote :

I didn't mean classic confinement… Yay for naming conflicts. Not sure how else to refer to Ubuntu !Core…

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Keeping the kernel driver in sync would probably be easier (already done) for Tegra images. But that does sound like a scary problem if we're to solve this for Nvidia on amd64 "classic" Ubuntu. Aside from anything else, "classic" Ubuntu supports multiple different Nvidia driver versions which are necessary to support multiple different GPU generations.

Revision history for this message
Michał Sawicz (saviq) wrote :

There's possibly another path - if the Tegra kernel driver does _not_ need to be closely in sync with the userspace driver, the nvidia-core22 snap could also be a solution for "classic" Ubuntu. The kernel driver would then come from the deb installation, but userspace could be supplied from the snap.

Revision history for this message
Loïc Minier (lool) wrote :

It's probably fair to assume userspace libs and driver are somewhat decoupled, but not sure; NVIDIA does their own kernel builds and their own debs with the GL libs, while we would want to do our kernels and deliver libs as debs or snaps, so we'll probably see all combinations – wee!

I'm not sure of the licensing terms for the GL libs, so I guess we should research them to see if they could go into the nvidia-core22 snap. I guess that would be the preferred path, and if that's not an option, I guess we should patch snap-confine and the libs would be distributed through (NVIDIA-provided) debs

Revision history for this message
Sandeep (sashinde) wrote :

Can you please update on the issue? Let me know if there is any help required from nvidia side?

Revision history for this message
Sandeep (sashinde) wrote :

Hi, is there any update on the issue? When should we expect the fix to be available by?

Revision history for this message
Nicolas Dechesne (ndec) wrote :

hey Sandeep, there has been no (direct) progress so far on this issue. However we now have Ubuntu 22.04 images/support for Jetson Orin. For now without graphics/desktop support, but we are planning to enable desktop/graphics in our current development cycle (before end of April). We will look further into this issue during this timeframe.

Revision history for this message
Sandeep (sashinde) wrote :

Thanks for the update Nicolas.

Is there any further progress on this as we are past April now?

Revision history for this message
Nicolas Dechesne (ndec) wrote :

hey Sandeep, unfortunately, there is no update. We have not been able to work on desktop with hardware GPU enabled on Tegra yet, as we've been working on other areas. At this point I am not sure when we will look into it.

Revision history for this message
theofficialgman (theofficialgman) wrote (last edit ):

@Sandeep I gave a summary of the problems currently experienced in January and the things that need to be done to fix them (I am just a user). You can work on them instead of waiting on ubuntu developers.
https://forums.developer.nvidia.com/t/chromium-electron-applications-hang-on-launch-on-gnome-wayland/276978/12?u=theofficialgman

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.