nvidia-bug-report.log.gz (444.7 KB)
about-gpu-2026-05-14T14-51-56-708Z.txt (28.5 KB)
I seem to be unable to get hardware graphics acceleration working on Google Chrome Version 147.0.7727.137 in Ubuntu 24.04.4 LTS running Wayland. I have Nvidia proprietary drivers version 535.288.01. I have tried launching Google Chrome on a standard setup and by modifying EXEC line to “google-chrome-stable --ozone-platform=wayland --use-angle=vulkan --ignore-gpu-blocklist --enable-features=WaylandWindowDecorations,AcceleratedVideoDecodeLinuxGL --disable-gpu-process-crash-limit” but hardware GPU acceleration remains disabled.
I couldn’t make any comment about chrome but if you wish to enable hardware accel in Firefox :
1- enter about:config and type hardware in search ( about:config )
2- media.hardware-video-decoding.force-enabled → true
3- media.hardware-video-encoding.force-enabled → true
4- close firefox and reopen it
5- check result in about:support
Also not related but just a question why do you need to use that much ancient version of nvidia drivers ? Latest stable production drivers are 595.71.05 [ but dont know if ubuntu 24.04.xx had or not those ]
Ah yeah, that’s a good point, I forgot to specify my GPU hardware. I am using a very old Geforce 980Ti so this ancient driver is actually the latest stable release for it
Dont get me wrong i’m not judging you by using any old or new driver it was just a question because of curiosity nothing more.580.159.03 is suitable driver for your 980Ti card { not sure if canonical have 580 drivers as packaged for 24.04.xx , i give up using any product from them (for my desktop system) } [ Driver Details | NVIDIA }
Hi @kisalli , unlucky timing on your attempt to enable GPU hardware-accellerated video decoding in a chromium-based browser…
…upstream release 147.x broke the required nvidia-vaapi-driver.
See my post on Arch Linux Forum here notifying Nvidia users.
There is a PR available, which I’ve confirmed restores GPU accelerated video decoding in chromium v147.x. and 148.x. and derivatives such as Brave.
master ← imperishableSecret:fix/chrome-stream-format-switch
opened 09:55PM - 01 May 26 UTC
## Summary
Fix Chrome playback failures when a stream changes codec or outp… ut format mid playback, for example VP9 to AV1 and SDR to HDR.
The direct backend now keeps exported backing images alive long enough for Chrome to re-import the same dmabuf after VA surface teardown. Imported surfaces can reuse the original CUDA arrays when fd,
format, and dimensions match, avoiding failed external memory imports and repeated `vaCreateSurfaces` or `vaExportSurfaceHandle` allocation failures.
This also fixes AV1 HDR transitions where Chrome creates the decode context before passing render targets. If the first real render surface uses a different format or bit depth than the config guessed,
the decoder is recreated before the first decode so P010/10-bit surfaces get a matching decoder output format.
AoTofu's changes are the foundation for the Chrome path in this branch, including the larger direct backend and Chrome interop work that made this fix possible. This PR keeps that work separate in the branch history and builds the stream transition fixes on top of it.
https://github.com/elFarto/nvidia-vaapi-driver/issues/420#issuecomment-4356503517
## Changes
- Cache direct backend backing images after VA surface detach so exported dmabufs remain reusable.
- Match imported dmabufs by fd, format, width, and height before borrowing CUDA resources.
- Add borrow tracking and backing-image sync so borrowed imports wait on the source backing image without relying on a possibly destroyed VA surface.
- Prune detached cached backing images under allocation pressure.
- Recreate the decoder before first decode when the first render surface format differs from the initial config.
- Treat `VAConfigAttribRTFormat` as a bitmask when selecting 10-bit and 12-bit formats.
- Fix a missing CUDA context pop on `vaExportSurfaceHandle` failure.
## Testing
- Built with `ninja -C build`.
- Ran `git diff --check`.
- Ran `meson test -C build`, no tests defined.
- Runtime tested Chrome VP9 to AV1 transitions:
- SDR AV1 did not regress.
- HDR AV1 no longer shows green output.
- Previous `copyFrameToSurface CUDA ERROR 'invalid argument'` loop is gone.
- Previous `vaExportSurfaceHandle failed, VA error: resource allocation failed` storm is gone.
You’ll need the ability to patch the package.
I repackaged atop the recently released v0.0.17 tag as noted here:
opened 03:00PM - 30 Jan 26 UTC
> Chrome
> Chrome is currently unsupported, and will not function.
I think this… is outdated
**I saw people saying - "everything works" with Chrome parameters**:
```
--enable-features=VaapiVideoDecoder,VaapiIgnoreDriverChecks,AcceleratedVideoDecodeLinuxGL
```
I not going to test everything with Chrome - asking someone else to actually test and figure out is it actually working
pull request - [Workaround for clients like Chromium for AV1, misc fixes](https://github.com/elFarto/nvidia-vaapi-driver/pull/407)
I see related issues still open:
- https://github.com/elFarto/nvidia-vaapi-driver/issues/397
- https://github.com/elFarto/nvidia-vaapi-driver/issues/405
and few closed
- https://github.com/elFarto/nvidia-vaapi-driver/issues/416
- https://github.com/elFarto/nvidia-vaapi-driver/issues/386
**also I see [comment about Discord support](https://github.com/elFarto/nvidia-vaapi-driver/issues/386#issuecomment-3194124037)**:
> Hello, i'm launching discord with these parameters to get HEVC decoding working:
>
> ```
> --start-minimized --enable-features=AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL,VaapiOnNvidiaGPUs,VaapiIgnoreDriverChecks,UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland
> ```
>
> and it actually works
Highly recommend you start with getting the 580 driver installed to begin with.
Critically important if you desire a good Wayland experience with your card.
EDIT: If you do reach the point where you have updated drivers and patched nvidia-vaapi-driver…
…the only flags required for many releases now are:
--enable-features=AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL,VaapiOnNvidiaGPUs
I’m agreeing what @Tekstryder said. At least 555+ is critical for wayland systems [ but still i insist about try to reach 580 series ]