2012285 - [NVIDIA] Fails to create headless HW accelered GL context

Status: UNCONFIRMED

(Core :: Audio/Video: Playback, defect, P3)

Description

[Thibault [:thibaulltt]]

Attachment: firefox-hdr-not-working.png

Hi, I seem to not be able to get HDR content playing on most YouTube test videos, but I'm unsure at which part of the Linux > Nvidia > KDE > Firefox is causing the issue! It doesn't seem to be on the Firefox side, as both Browser Console and regular Console do not seem to be showing any errors, but I want to make sure of it.

I'm currently testing this using Fedora 42 (KDE edition) and I have enabled both the gfx.wayland.hdr and gfx.wayland.hdr.force-enabled variables (only the former at first, then both) on both Firefox 147.0.1 and Zen 1.17.15b (based on Firefox 146.0.1, which I'm using to write this). I run an Nvidia card, with the proprietary drivers installed directly from Nvidia, as I need their CUDA runtime as well. In KDE's System Settings, HDR is enabled and my monitor is detecting a 10-bit HDR signal coming in. For reference, my monitor is a MSI 321UPX QD-OLED. HDR viewing is working on Windows (same machine, I have a dual-boot installed).

I tried to watch the following video, as I had seen it a lot while browsing for a new TV a while back and know what it's supposed to look like: https://www.youtube.com/watch?v=njX2bu-_Vw4
I have attached a screenshot from the YouTube page in question: in the thumbnail on the bottom, you see a rough approximation of what this scene is supposed to look like (thumbnails are served as SDR images from YouTube directly) and on the top you see what it's currently displayed as.

The video decodes perfectly fine, but the colors seem really washed out, as if they were displayed in log format, before applying any LUT or color matrix transformation: I seem to stumble upon the same issue as Marco a few comments above. Based on M. Stransky's post I stumbled upon, I checked what hardware and Wayland extensions I had access to on this PC. From the available Vulkan extensions, I seem to only have VP9 decoding v1 available in-hardware. My KWin compositor has access to the wp_color_manager_v1 protocol.

I'm open to forwarding more information your way, should you need to.

Comment 1

[Thibault [:thibaulltt]]

Oops, as this was originally written as a response to bug 1642854, the comments I refer to in the original post are those two comments: (first, second).

Comment 2

[Martin Stránský [:stransky] (ni? me)]

First of all, you should set gfx.wayland.hdr - it enables HDR only if you really have everything set. gfx.wayland.hdr.force-enabled is for testing purpose only and you may see various results as the HDR may or may not be supported.

Please attach your about:support page.

Please run on terminal with WAYLAND_DEBUG=1 MOZ_LOG="WidgetWayland:5, FFmpegVideo:5,Dmabuf:5" env variables, reproduce the issue and attach the log here (may be large so you may zip it).
Thanks.

Comment 3

[Thibault [:thibaulltt]]

Hi there, thanks for the quick feedback. I will attach to this bug the following in a tar-gzipped file (compressed with tar czvf firefox-hdr-bug-2012285.tar.gz <files>):

• config-information.json: the JSON output I got from the about:support page (didn't know this page was "exportable" as JSON, very nice) ;
• out.log: the full output of a run of firefox invoked with the following arguments: env WAYLAND_DEBUG=1 MOZ_LOG="WidgetWayland:5, FFmpegVideo:5,Dmabuf:5" firefox https://www.youtube.com/watch?v=njX2bu-_Vw4 and tee'd into this file.

And with those files, I've already located something, it seems YUV data cannot be properly copied into the DMABuf :

$ rg -i fail out.log
111172:[RDD 49879: MediaPDecoder #1]: D/Dmabuf   failed to convert YUV data to DMABuf memory!
111173:[RDD 49879: MediaPDecoder #1]: D/FFmpegVideo FFVPX: Failed to uploaded video data to DMABuf
136201:[RDD 49879: MediaPDecoder #2]: D/Dmabuf   failed to convert YUV data to DMABuf memory!
136202:[RDD 49879: MediaPDecoder #2]: D/FFmpegVideo FFVPX: Failed to uploaded video data to DMABuf
< ... snip ... >

I'll let you examine those files a bit more carefully, but it seems to stem from something wrong with the dmabuf kernel subsystem... I'll paste the kernel command line here just in case :

BOOT_IMAGE=(hd2,gpt1)/vmlinuz-6.18.6-100.fc42.x86_64 root=/dev/mapper/fedora-root ro resume=UUID=3165cb11-be59-4620-9863-a7e819e14174 rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet rd.driver.blacklist=nouveau,nova_core,nova_core rd.driver.blacklist=nova-core

And I'll also attach the current kernel configuration that Fedora 42 provided and is running on my system, just in case this can help you figure out why the problem arises :)

Comment 4

[Thibault [:thibaulltt]]

Attachment: Firefox logs from a HDR video playback

Comment 5

[Thibault [:thibaulltt]]

Attachment: Kernel configuration of the system I'm running on

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Yeah, NVIDIA stuff here. With missing HW decoding we fail to upload YUV frames to dmabuf for direct scanout. We use ClaimSnapshotGLContext() which may be missing the export extensions we need for dmabuf upload as NVIDIA doesn't support GBM.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Please try again latest nightly and run with MOZ_LOG="FFmpegVideo:5,Dmabuf:5" and attach the log here.
Thanks.

Comment 8

[Thibault [:thibaulltt]]

Hi, sorry for the time it took. I will attach a log shortly after this comment of the following firefox-nightly invocation:

env  MOZ_LOG="FFmpegVideo:5,Dmabuf:5" firefox-nightly https://www.youtube.com/watch?v=njX2bu-_Vw4 2>&1 | tee firefox-hdr-bugreport/nightly-20260202.log

I took the newly released RPM package from https://packages.mozilla.org/rpm/firefox to install it via DNF, and ran this command with firefox-nightly version 149.0a1, build ID 20260202095009.

Comment 9

[Thibault [:thibaulltt]]

Attachment: firefox-hdr-bug2012285-nightly-log.tar.gz

Comment 10

[Martin Stránský [:stransky] (ni? me)]

[GFX1-]: DMABufSurface::UseDmaBufExportExtension(): MESA_image_dma_buf_export is missing!
[RDD 9662: MediaPDecoder #2]: V/Dmabuf Vendor: Mesa
[RDD 9662: MediaPDecoder #2]: V/Dmabuf Renderer: llvmpipe (LLVM 20.1.8, 256 bits)

Here we come. While we use NVIDIA gfx card for rendering our snapshot GL context uses llvmpipe which is missing the dmabuf import extension.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

I wonder if it's possible to ensure we create the snapshot on actual hardware - I guess we may need to have display connection or so for it.

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Looks like AMD/Mesa creates the snapshot context correctly:

[RDD 505667: MediaPDecoder #5]: V/Dmabuf Vendor: AMD
[RDD 505667: MediaPDecoder #5]: V/Dmabuf Renderer: AMD Radeon RX 6600 XT (radeonsi, navi23, LLVM 21.1.5, DRM 3.64, 6.18.7-200.fc43.x86_64)

Comment 13

[Martin Stránský [:stransky] (ni? me)]

A solution may be to move dmabuf creation to rendering process so pass the buffer as shm image. But that will require significant plumbing across rendering pipeline.

Comment 14

[Martin Stránský [:stransky] (ni? me)]

I wonder if we can re-use the existing SHM machinery where shared buffers are used as custom ones for ffmpeg decoder.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

We perhaps also want to remove snapshot GL context for non-MESA drivers as the headless context is useless. Or investigate why.

Comment 16

[Martin Stránský [:stransky] (ni? me)]

btw. the headless context is created without CreateContextFlags::FORBID_HARDWARE flags so it's supposed to run on HW:
https://searchfox.org/firefox-main/rev/7709f0a26aeb3c39a5fd86e794425530f0d0b528/widget/gtk/DMABufSurface.cpp#218

Comment 17

[Martin Stránský [:stransky] (ni? me)]

We may also update how the context is created:
https://searchfox.org/firefox-main/rev/7709f0a26aeb3c39a5fd86e794425530f0d0b528/gfx/gl/GLContextProviderEGL.cpp#1115
if it's possible to create it on HW/NVIDIA.

Comment 18

[Thibault [:thibaulltt]]

Any reason why the snapshot context created is based on OpenGL ? Why not Vulkan, as it seems like Firefox supports Vulkan operations ?

And as an aside, would something like the trickery used by the nvidia-prime shell script work here (see it on Arch Linux's gitlab) ? It's basically a few environment variables before launching a program, which forces the creation of a HW-accelerated GL context by the driver.

Comment 19

[Thibault [:thibaulltt]]

And thinking of it (it would also require a lot of plumbing) but why do you need to create a new context, GL or otherwise, and not an off-screen rendering target in the "main" context ?

Comment 20

[hdr]

Got the exact same issue.
Nvidia 5070ti - Hyprland - Archlinux 6.18.8-3

Comment 21

[Martin Stránský [:stransky] (ni? me)]

Jeff,
may we ask NVIDIA folks for help? NVIDIA fails to create headless HW accelerated GL context here (while AMD/Intel works):
https://searchfox.org/firefox-main/rev/7709f0a26aeb3c39a5fd86e794425530f0d0b528/gfx/gl/GLContextProviderEGL.cpp#1115
Thanks.