chromium hardware accelerated

[jatpl]

Using meta-tegra I can build the chromium-x11 and chromium-ozone-wayland and they both run on the Jetson Nano, but they are not hardware accelerated. What is missing to get hardware acceleration working with chromium on the Jetson Nano?

[madisongh]

I don't know much about it, but perhaps these instructions could be adapted?

[jatpl]

How is graphics hardware acceleration enabled?

I'm using the Nano with xfce or gnome. I am able to build chromium with the RidgeRun patches, and I have also installed the RidgeRun chromium .deb package. In both cases 2D and 3D graphics are not hardware accelerated (and playing a video is not hardware accelerated). I don't think this is a chromium problem as it fails with the RidgeRun chromium .deb package. I think the problem is the graphics hardware acceleration is not enabled. I think it's using gles2, so I enabled libgles2 and libglesv2-2 in the mesa PACKAGECONFIG, and included mesa and libglvnd in the image. I've tried adding several other related packages, but hardware accelerated graphics is not enabled. Thanks in advance for any suggestions or ideas.

[madisongh]

How is graphics hardware acceleration enabled?

It's enabled automatically using meta-tegra for the normal OpenGL libraries. You shouldn't have to modify the mesa recipes; that's already done, to use libglvnd as the dispatcher, and the NVIDIA provider libraries get used automatically.

That said, I have no idea what the chromium build does - if it has its own copies of what would normally be system-provided libraries (as I suspect it does), then yes, you'd have to configure its build to do something similar, pulling in libglvnd and using that instead of direct calls into mesa libraries (and maybe even omitting mesa altogether). You'd want to make sure that that internal build of libglvnd is configured similar to the way we have it for the recipe, too.

[jatpl]

Thanks for the response. Previously, I've added "mesa" as a DEPENDS += in chromium-x11_%.bbappend to get it to build. Removing "mesa" from this recipe, chromium fails with "Package dri was not found in the pkg-config search path." Seems chromium is using "dri". Does libglvnd or another package (other than mesa) provide dri that is hardware accelerated?

[madisongh]

Nope, NVIDIA doesn't do DRI at all. You're going to have to dig further to see where it's trying to use it and see if there are other options.

[kekiefer]

I'm curious if this is going to dovetail with the work we've been doing on the master branch to get weston 10 working, at least to enable chromium-ozone-wayland.

It is correct that we don't have a proper DRI driver. But a cursory look through at least the wayland sources, I think it's only using this as a catchall for libdrm support. Pulling in mesa just to get the dri.pc file shouldn't hurt here. Simply having mesa installed won't cause any problems on its own, its backend only get used as a fallback. In their absence it wouldn't work in the first place.

That leads me to my main point -- the render nodes (/dev/dri/renderN) we get out of our fake drm infrastructure (provided by tegra-udrm) don't work they way they are supposed to for getting hardware buffers. It is fairly typical to try to open a render node to use with gbm. So if I had to guess, this is going to be a problem:
https://github.com/chromium/chromium/blob/main/ui/ozone/platform/wayland/gpu/drm_render_node_path_finder.cc#L21

In some cases (for example, in weston-simple-dmabuf) the stuff that would normally have used one of these render-only nodes works fine when used with the output nodes (/dev/dri/cardN).

This is probably a good place to start. I would stick to the wayland integration if you can, since generally the wayland design lends itself well to passing hardware buffers around and rendering with egl, which are both things you want to do here, and we know that these essentially work under Weston.

Another thing that hasn't come up, is if you're simply looking for accelerated rendering. At one point chromium used gstreamer to do video on linux, but I don't think it does this anymore. I see a dependency on libvaapi, which I believe we'll get with a newer kernel, but may require heroics to get working now.

[GavinDarkglider]

#967 Should fix video decoding in chrome if done properly. If you could patch chrome to not sandbox calls to /dev/tegra-dec and /dev/tegra-enc, and patch chrome to use ffmpeg vp9, it would fix all chrome issues as far as video encoding/decoding.

[jatpl]

https://forums.developer.nvidia.com/t/graphics-hardare-acceleration/210238

[ichergui]

Excellent, Thanks @jatpl for sharing the link

[kekiefer]

I haven't had any time to devote to this, but it's still an interesting topic. If anyone has patches they'd like contribute to make this work I'm happy to provide a review.

[2opremio]

@jatpl did you manage to make any progress?

[kekiefer]

For what it's worth, if you're interested in embedded a browser, qtwebengine is based on chromium and provides working webgl. I've tested it with a qtwayland compositor and Qt::AA_ShareOpenGLContexts attribute set, and application with qtwebengine's use_virtualized_gl_contexts set. I'd assume that using the kms gbm or eglstreams backend directly should work as well. This doesn't cover encode/decode.

[2opremio]

I managed to make it work with chromium. But I have to use an old version (110)

[GavinDarkglider]

The switchroot team has long fixed this issue, find gman on the discord, and he can fill you in on all of the needed patches, full ffmpeg support, and even widevine, though that needs special patching to glibc.