Closed Bug 1859291 Opened 11 months ago Closed 5 months ago

Snap package does not support hw decoding of H264 and VP9 on amd gpu due to mesa < 23.1.1

Categories

(Firefox Build System :: Third Party Packaging, defect)

Product:
Firefox Build System
Component:
Third Party Packaging
Platform:
Desktop
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: gerard-majax, Assigned: gerard-majax)

References

(Blocks 1 open bug)

Details

Attachments

(5 files)

moz tarball
58.62 KB, image/png
Details
snap edge
51.79 KB, image/png
Details
ffmpeg.log
76.39 KB, text/x-log
Details
about:support firefox 125 mesa 23.2
87.02 KB, text/plain
Details
MOZ_GFX_DEBUG=1 firefox 125 mesa 23.2
853 bytes, text/plain
Details

STR:
(1) install nightly from mozilla tarball
(2) start video playback (youtube)
(3) about:support, search "codec support information"

Expected:
H264 and VP9 and supported for hw decoding

Actual:
Repeat steps 2 and 3 on a snap (edge) package, support is disabled

Attached image moz tarball —
Attached image snap edge —
Blocks: snap
$ grep H264 pdm_nightly.log
[Parent 202836: Main Thread]: D/PlatformDecoderModule Broadcast support from 'Utility Generic', support=H264 SW HW, VP9 SW HW, VP8 SW, AV1 SW, HEVC NONE, Theora NONE, AAC SW, MP3 SW, Opus SW, Vorbis SW, FLAC SW, Wave SW
[Parent 202836: Main Thread]: D/PlatformDecoderModule Broadcast support from 'RDD', support=H264 SW HW, VP9 SW HW, VP8 SW, AV1 SW, HEVC NONE, Theora SW, AAC SW, MP3 SW, Opus SW, Vorbis SW, FLAC SW, Wave SW
$ grep H264 pdm_snap_edge.log 
[Parent 200565: Main Thread]: D/PlatformDecoderModule Broadcast support from 'Utility Generic', support=H264 SW, VP9 SW, VP8 SW, AV1 SW, HEVC NONE, Theora NONE, AAC SW, MP3 SW, Opus SW, Vorbis SW, FLAC SW, Wave SW
[Parent 200565: Main Thread]: D/PlatformDecoderModule Broadcast support from 'RDD', support=H264 SW, VP9 SW, VP8 SW, AV1 SW, HEVC NONE, Theora SW, AAC SW, MP3 SW, Opus SW, Vorbis SW, FLAC SW, Wave SW

The snap still relies on ffmpeg libavcodec58 (due to core22 dep ?) https://github.com/canonical/firefox-snap/blob/d359d753e17313641a8fe7dcf93f3fa1de68821c/snapcraft.yaml#L531-L532 whereas the tar uses my system's libavcodec60

Martin, I am unsure where to check in the list of deps involved here which component of the layer might be acting ? Do you have some debugging steps I could apply to check ? Sebastian from Canonical reported to me on IRC that his Intel system on stable channel of Firefox Snap was properly reporting HW decoding for those.

Flags: needinfo?(stransky)
Summary: Snap package does not support hw decoding of H264 and VP9 → Snap package does not support hw decoding of H264 and VP9 on amd gpu

Look at https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
This is for Fedora but basic info may be the same.

If you run Firefox with MOZ_LOG="PlatformDecoderModule:5" env variable you should get complete log about HW decoding and what's missing.
vainfo on terminal gives you details about supported codecs.

libavcodec58 supports all HW decoded formats so that should be fine.

Flags: needinfo?(stransky)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

Look at https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
This is for Fedora but basic info may be the same.

If you run Firefox with MOZ_LOG="PlatformDecoderModule:5" env variable you should get complete log about HW decoding and what's missing.
vainfo on terminal gives you details about supported codecs.

Well the output was in comment #3, there's not much more about why

And vainfo on the host returns:

$ vainfo 
libva info: VA-API version 1.19.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_19
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.19 (libva 2.12.0)
vainfo: Driver version: Mesa Gallium driver 23.2.1-1ubuntu3 for AMD Radeon Graphics (renoir, LLVM 15.0.7, DRM 3.54, 6.5.0-9-generic)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

It's not available within the snap :(

(In reply to :gerard-majax from comment #7)

It's not available within the snap :(

You can easily get that though

$ cp /usr/bin/vainfo ~/snap/firefox/common
$ snap run --shell firefox
$ cd; ./vainfo

(In reply to :gerard-majax from comment #7)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

Look at https://fedoraproject.org/wiki/Firefox_Hardware_acceleration
This is for Fedora but basic info may be the same.

If you run Firefox with MOZ_LOG="PlatformDecoderModule:5" env variable you should get complete log about HW decoding and what's missing.
vainfo on terminal gives you details about supported codecs.

Well the output was in comment #3, there's not much more about why

If that's nightly/119 then you use MOZ_LOG="FFmpegVideo:5" env variable.

(In reply to seb128 from comment #8)

(In reply to :gerard-majax from comment #7)

It's not available within the snap :(

You can easily get that though

$ cp /usr/bin/vainfo ~/snap/firefox/common
$ snap run --shell firefox
$ cd; ./vainfo

Unfortunately, -EPERM.

If that's nightly/119 then you use MOZ_LOG="FFmpegVideo:5" env variable.

120 in fact, but logging is not helping much:

$ grep -i vp9 ffmpeg.log
[RDD 744330: MediaSupervisor #1]: D/FFmpegVideo FFVPX: FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/vp9 Codec ID 167
[RDD 744330: MediaSupervisor #1]: D/FFmpegVideo FFVPX: Codec vp9 is not accelerated
[RDD 744330: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec vp9 : Google VP9

Within Snap:

$ ./vainfo 
libva info: VA-API version 1.20.0
libva info: Trying to open /snap/firefox/3275/gnome-platform/usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.20 (libva 2.12.0)
vainfo: Driver version: Mesa Gallium driver 23.0.4-0ubuntu1~22.04.1 for RENOIR (renoir, LLVM 15.0.7, DRM 3.54, 6.5.0-9-generic)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

Host:

$ vainfo 
libva info: VA-API version 1.19.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_19
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.19 (libva 2.12.0)
vainfo: Driver version: Mesa Gallium driver 23.2.1-1ubuntu3 for AMD Radeon Graphics (renoir, LLVM 15.0.7, DRM 3.54, 6.5.0-9-generic)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

(In reply to :gerard-majax from comment #10)

$ grep -i vp9 ffmpeg.log
[RDD 744330: MediaSupervisor #1]: D/FFmpegVideo FFVPX: FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/vp9 Codec ID 167
[RDD 744330: MediaSupervisor #1]: D/FFmpegVideo FFVPX: Codec vp9 is not accelerated
[RDD 744330: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec vp9 : Google VP9

Please attach full log.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #13)

(In reply to :gerard-majax from comment #10)

$ grep -i vp9 ffmpeg.log
[RDD 744330: MediaSupervisor #1]: D/FFmpegVideo FFVPX: FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/vp9 Codec ID 167
[RDD 744330: MediaSupervisor #1]: D/FFmpegVideo FFVPX: Codec vp9 is not accelerated
[RDD 744330: MediaPDecoder #1]: D/FFmpegVideo FFVPX: codec vp9 : Google VP9

Please attach full log.

that's litterally the first lines

Attached file ffmpeg.log —

ok, so mesa in the snap package is 23.0 from core22 (ubuntu 22.04) where as my laptop's system is using 23.2

https://docs.mesa3d.org/relnotes/23.1.1.html#bug-fixes mentions some stuff Firefox / VA-API / H.264 decoding artifacts on AMD RX 6600 / Fedora 37

$ /snap/firefox/current/usr/lib/firefox/vaapitest --drm /dev/dri/renderD128
VAAPI_SUPPORTED
TRUE
VAAPI_HWCODECS
80

So 80 would suggest H264 and VP9 properly detected by vaapitest, but not after ?

(In reply to :gerard-majax from comment #19)

So 80 would suggest H264 and VP9 properly detected by vaapitest, but not after ?

Yes, looks like VA-API is supported but you're missing HW decode support on ffmpeg side. Do you have correct ffmpeg package installed?

I dont see https://searchfox.org/mozilla-central/rev/10d0e01455559a433670bd718a3ecc0ece5d2cb9/widget/gtk/GfxInfo.cpp#279-280

$ /snap/firefox/3298/usr/lib/firefox/glxtest --wayland
PCI_VENDOR_ID
0x1002
PCI_DEVICE_ID
0x1638
DRI_DRIVER
radeonsi
VENDOR
AMD
RENDERER
RENOIR (renoir, LLVM 15.0.7, DRM 3.54, 6.5.0-9-generic)
VERSION
4.6 (Compatibility Profile) Mesa 23.0.4-0ubuntu1~22.04.1
TFP
TRUE
DRM_RENDERDEVICE
/dev/dri/renderD128
MESA_VENDOR_ID
0x1002
MESA_DEVICE_ID
0x1638
TEST_TYPE
EGL

I think it's your changes : https://searchfox.org/mozilla-central/rev/10d0e01455559a433670bd718a3ecc0ece5d2cb9/widget/gtk/GfxInfo.cpp#1100-1106

This does disable on all AMD hardware with MESA < 23.1 ; this does match what I have, with Mesa 23.0 within the Snap and Mesa 23.2 outside.

Flags: needinfo?(stransky)

You mention the fix being in 23.0.3, Ubuntu 22.04 should have 23.0.4 https://gitlab.freedesktop.org/mesa/mesa/-/issues/8996#note_1908280

Should we change the version checking ?

Flags: needinfo?(bandali)

I think the check is correct, see https://bugzilla.mozilla.org/show_bug.cgi?id=1832080#c5

Flags: needinfo?(stransky)

You can force-enable by media.ffmpeg.vaapi.enabled or by media.hardware-video-decoding.force-enabled at about:config.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #26)

I think the check is correct, see https://bugzilla.mozilla.org/show_bug.cgi?id=1832080#c5

What about your comment on 23.0.3 ? Did it shipped in 23.0.4 or it was just a verification on your side ?

(In reply to :gerard-majax from comment #28)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #26)

I think the check is correct, see https://bugzilla.mozilla.org/show_bug.cgi?id=1832080#c5

What about your comment on 23.0.3 ? Did it shipped in 23.0.4 or it was just a verification on your side ?

That was a verification that the patch works with mesa-23.0.3.

Mesa should get upgraded as part of hardware enablement on 22.04 within a few weeks

Summary: Snap package does not support hw decoding of H264 and VP9 on amd gpu → Snap package does not support hw decoding of H264 and VP9 on amd gpu due to mesa < 23.1.1
Duplicate of this bug: 1871102

Just bring a comment in from the duplicate (bug 1871102) so it's not lost.

Ubuntu typically only updates the mesa package in LTS release a few times between LTS releases in sync with the interim release. Their next release is the LTS release, so I think it's unlikely the Ubuntu 22.04 archive gets another mesa update.

Considering this I do want to ask; why does the snapcraft.yaml need to pull mesa from the Ubuntu archive in the first place? Can't it just pull mesa source tree as one of the dependencies directly from mesa git and build it? Lots of packages do it this way instead of taking binaries from the Ubuntu archive.
doing this then Firefox support can be decoupled from Ubuntu's schedule in the future and it will mean more hardware support within Firefox snap.

OS: Unspecified → Linux
Hardware: Unspecified → Desktop
See Also: → 1760941, https://github.com/MirServer/mesa-core22/pull/11, https://github.com/canonical/mesa-core24

(In reply to Mario Limonciello from comment #32)

Just bring a comment in from the duplicate (bug 1871102) so it's not lost.

Ubuntu typically only updates the mesa package in LTS release a few times between LTS releases in sync with the interim release. Their next release is the LTS release, so I think it's unlikely the Ubuntu 22.04 archive gets another mesa update.

Considering this I do want to ask; why does the snapcraft.yaml need to pull mesa from the Ubuntu archive in the first place? Can't it just pull mesa source tree as one of the dependencies directly from mesa git and build it? Lots of packages do it this way instead of taking binaries from the Ubuntu archive.
doing this then Firefox support can be decoupled from Ubuntu's schedule in the future and it will mean more hardware support within Firefox snap.

I dont remember why but amin or sebastian would know for sure

Flags: needinfo?(bandali) → needinfo?(seb128)
Flags: needinfo?(bandali)

(In reply to Mario Limonciello from comment #32)

Just bring a comment in from the duplicate (bug 1871102) so it's not lost.

Ubuntu typically only updates the mesa package in LTS release a few times between LTS releases in sync with the interim release. Their next release is the LTS release, so I think it's unlikely the Ubuntu 22.04 archive gets another mesa update.

The updates aren't sync-ed with interim Ubuntu releases but usually done for the LTS point releases (which is why an updated version is being validated in jammy-proposed atm)

Considering this I do want to ask; why does the snapcraft.yaml need to pull mesa from the Ubuntu archive in the first place? Can't it just pull mesa source tree as one of the dependencies directly from mesa git and build it? Lots of packages do it this way instead of taking binaries from the Ubuntu archive.
doing this then Firefox support can be decoupled from Ubuntu's schedule in the future and it will mean more hardware support within Firefox snap.

We could bundle a copy of mesa in the firefox snap but I don't think that would be right. We currently include mesa in the gnome-sdk snap, if we want to provide a better version of hardware support I think we should update the gnome-sdk version which would benefit also other snaps.

The version used by the firefox snap should keep rolling by following the distro in fact so it's unclear that we should build from source (we currently have 23.2.1 being SRUed to Jammy but at some point our snaps will roll out to use a core/gnome-sdk based on Noble so firefox will then use the Noble version of the package)

Flags: needinfo?(seb128)

The updates aren't sync-ed with interim Ubuntu releases but usually done for the LTS point releases (which is why an updated version is being validated in jammy-proposed atm)

Right.

We could bundle a copy of mesa in the firefox snap but I don't think that would be right. We currently include mesa in the gnome-sdk snap, if we want to provide a better version of hardware support I think we should update the gnome-sdk version which would benefit also other snaps.

Sure; this would work to help this problem too.

The version used by the firefox snap should keep rolling by following the distro in fact so it's unclear that we should build from source (we currently have 23.2.1 being SRUed to Jammy but at some point our snaps will roll out to use a core/gnome-sdk based on Noble so firefox will then use the Noble version of the package)

But the same snap is used no matter the distro version. If I'm running 18.04, 22.04 or 23.10 either way it would be the exact same Firefox snap binary. That's why I was suggesting to update mesa independently.

(In reply to Mario Limonciello from comment #35)

But the same snap is used no matter the distro version. If I'm running 18.04, 22.04 or 23.10 either way it would be the exact same Firefox snap binary. That's why I was suggesting to update mesa independently.

Right, building from source would give us a bit more flexibility on the version used and avoid delays like we currently have on waiting for a SRU verification, but on the other side by using the Ubuntu deb we ensure that the updated version we pull in went through the Canonical certification testing and Ubuntu review process. If we build from source we would need to define a more rigorous regression testing process for the snap updates...

Flags: needinfo?(bandali)

How about if you match the version in latest stable Ubuntu instead of version in current LTS point release? This should let you get something well tested but without waiting on SRU schedule.

Well, we can't pull a deb from another serie in the snap so we would need to build from source, which mean the generated binaries might behave differently/miss patches that are in Ubuntu (unless we pull the source package from the other serie but then the content might have changes that match the Ubuntu serie) so we will still need to figure out the testing story for that build.

I'm not saying that we shouldn't do it, it's just not a trivial change.

One other thing which was discussed was to have a shared content snap for the graphics stack, which would allow users to opt in for new serie when needed. The discussion isn't really about firefox at this point though, and not about the specific problem reported here which is about to be resolved once the current SRU is verified. I would suggest to create a post on the Ubuntu discourse if you want to discuss the topic further

I am seeing mesa 23.2.1 on my 22.04 VM with jammy-updates enabled, is this what we were waiting for?

The update landed in the gnome-sdk stable channel so in theory that bug should be fixed now if someone could confirm?

Just forced a refresh and no:

alex@portable-alex:~$ snap info gnome-42-2204 
name:      gnome-42-2204
summary:   Shared GNOME 42 Ubuntu stack
publisher: Canonical✓
store-url: https://snapcraft.io/gnome-42-2204
contact:   https://github.com/ubuntu/gnome-sdk/issues
license:   unset
description: |
  This snap provides the GNOME 42 stack to other snaps that use it. It shares the base GNOME
  libraries and desktop integration components through the content interface. This helps reduce the
  size of snaps and helps developers to easily snap desktop applications.
  
  **For users**
  
  This snap is automatically installed and removed when needed. **Manually adding or removing this
  snap is not recommended** and might break things.
  
  * If you are having issues with **snaps** using GNOME, please contact the experts on the Snapcraft
  forum: https://forum.snapcraft.io/
  * If you want to install the GNOME Desktop Environment, then you are in the wrong place. Please
  take a look at https://www.gnome.org/ for more information on how to get it.
  
  **For developers**
  
  * The `gnome` extension is the recommended way to use this in your own snap:
  https://snapcraft.io/docs/gnome-extension
  * You can report issues with this content snap on GitHub:
  https://github.com/ubuntu/gnome-sdk/issues
  * The source code of this snap is available on GitHub in the `gnome-42-2204` branch:
  https://github.com/ubuntu/gnome-sdk/tree/gnome-42-2204
snap-id:      lATO8HzwVvrAPrlZRAWpfyrJKlAJrZS3
tracking:     latest/stable
refresh-date: Il y a 12 jours, à 13 h 44 HNR
channels:
  latest/stable:    0+git.510a601 2024-03-14 (172) 528MB -
  latest/candidate: 0+git.510a601 2024-02-23 (172) 528MB -
  latest/beta:      ↑                                    
  latest/edge:      0+git.510a601 2024-02-23 (172) 528MB -
installed:          0+git.510a601            (172) 528MB -
alex@portable-alex:~$ snap run firefox 
Gtk-Message: 16:55:00.399: Not loading module "atk-bridge": The functionality is provided by GTK natively. Please try to not load it.
^CExiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

alex@portable-alex:~$ snap info firefox 
name:      firefox
summary:   Mozilla Firefox web browser
publisher: Mozilla✓
store-url: https://snapcraft.io/firefox
contact:   https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla
license:   unset
description: |
  Firefox is a powerful, extensible web browser with support for modern web application
  technologies.
commands:
  - firefox
  - firefox.geckodriver
snap-id:      3wdHCAVyZEmYsCMFDE9qt92UV8rC8Wdk
tracking:     latest/stable
refresh-date: hier à 18 h 22 HNR
channels:
  latest/stable:    124.0.1-1    2024-03-22 (4033) 281MB -
  latest/candidate: 124.0.1-1    2024-03-22 (4033) 281MB -
  latest/beta:      125.0b3-1    2024-03-22 (4031) 283MB -
  latest/edge:      126.0a1      2024-03-25 (4050) 301MB -
  esr/stable:       115.9.1esr-1 2024-03-22 (4032) 256MB -
  esr/candidate:    115.9.1esr-1 2024-03-22 (4032) 256MB -
  esr/beta:         ↑                                    
  esr/edge:         ↑                                    
installed:          124.0.1-1               (4033) 281MB -

In about:support the mesa version reported is still 23.0.4: 4.6 (Compatibility Profile) Mesa 23.0.4-0ubuntu1~22.04.1

Flags: needinfo?(seb128)

Ok, it is a bit unfortunate but turns out that the gnome content snap needed to be rebuilt after the sdk one, the manifest is misleading and the staged packages version aren't to be trusted because they are getting overwritten with the sdk versions. There is a new candidate build for gnome-42-2204 and I confirmed that with that one the version listed in about:support is correct now

Flags: needinfo?(seb128)

Hello, this is still not working for me

Flags: needinfo?(seb128)

(In reply to :gerard-majax from comment #43)

Hello, this is still not working for me

You mean using the candidate build of gnome-42-2204? could you confirm which revision you are trying with and what about:support lists as 'Pilote WebGL 1 - Version'?

Flags: needinfo?(seb128)

I meant with gnome-42-2204 that is offered as of today as well as current firefox stable release (125):

$ snap info gnome-42-2204 
name:      gnome-42-2204
summary:   Shared GNOME 42 Ubuntu stack
publisher: Canonical✓
store-url: https://snapcraft.io/gnome-42-2204
contact:   https://github.com/ubuntu/gnome-sdk/issues
license:   unset
description: |
  This snap provides the GNOME 42 stack to other snaps that use it. It shares the base GNOME
  libraries and desktop integration components through the content interface. This helps reduce the
  size of snaps and helps developers to easily snap desktop applications.
  
  **For users**
  
  This snap is automatically installed and removed when needed. **Manually adding or removing this
  snap is not recommended** and might break things.
  
  * If you are having issues with **snaps** using GNOME, please contact the experts on the Snapcraft
  forum: https://forum.snapcraft.io/
  * If you want to install the GNOME Desktop Environment, then you are in the wrong place. Please
  take a look at https://www.gnome.org/ for more information on how to get it.
  
  **For developers**
  
  * The `gnome` extension is the recommended way to use this in your own snap:
  https://snapcraft.io/docs/gnome-extension
  * You can report issues with this content snap on GitHub:
  https://github.com/ubuntu/gnome-sdk/issues
  * The source code of this snap is available on GitHub in the `gnome-42-2204` branch:
  https://github.com/ubuntu/gnome-sdk/tree/gnome-42-2204
snap-id:      lATO8HzwVvrAPrlZRAWpfyrJKlAJrZS3
tracking:     latest/stable
refresh-date: Il y a 14 jours, à 03 h 36 HNR
channels:
  latest/stable:    0+git.510a601 2024-04-05 (176) 529MB -
  latest/candidate: 0+git.510a601 2024-03-26 (176) 529MB -
  latest/beta:      ↑                                    
  latest/edge:      0+git.510a601 2024-03-26 (176) 529MB -
installed:          0+git.510a601            (176) 529MB -

AMD -- RENOIR (renoir, LLVM 15.0.7, DRM 3.54, 6.5.0-21-generic)
4.6 (Compatibility Profile) Mesa 23.2.1-1ubuntu3.1~22.04.2

And yet HW decoding still reported as unsupported

(In reply to :gerard-majax from comment #46)

AMD -- RENOIR (renoir, LLVM 15.0.7, DRM 3.54, 6.5.0-21-generic)
4.6 (Compatibility Profile) Mesa 23.2.1-1ubuntu3.1~22.04.2

And yet HW decoding still reported as unsupported

I wonder if that's a new/other issue then, that mesa update was supposed to fix the problem... is the same firefox version in !snap on 22.04 on the same machine working?

I might have replied too quickly, on 23.10 for sure it works, i dont have 22.04 to verify

FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILED in about:support

Flags: needinfo?(stransky)

Bug 1837140 - VAAPI/AMD is not shipped in release.

Flags: needinfo?(stransky)

My bad, my original report was about nightly. Indeed nightly snap now works. The remainder of non working on stable is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1837140

See Also: → egl-linux-vaapi-release-amd
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: