[BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC
I have discovered that my RX6600 cannot use VDPAU to decode HEVC, although VA-API works OK. Unfortunately, VLC 3.x only supports VDPAU these days for hardware decoding. I have raised this issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10599 Mesa 23.3.5 just used to fail, but both Mesa 24.0.1 and 24.1.0-devel actually lock up the GPU and force me to reboot my PC. According to vdpauinfo: namelevel macbs width height ... HEVC_MAIN 186 139264 8192 4352 HEVC_MAIN_10 186 139264 8192 4352 HEVC_MAIN_STILL--- not supported --- HEVC_MAIN_12 --- not supported --- HEVC_MAIN_444 --- not supported --- HEVC_MAIN_444_10 --- not supported --- HEVC_MAIN_444_12 --- not supported --- ... Cheers, Chris
RE: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC
[AMD Official Use Only - General] This is being looked. > -Original Message- > From: mesa-dev On Behalf Of > Chris Rankin > Sent: Thursday, February 15, 2024 10:38 AM > To: mesa-dev@lists.freedesktop.org > Subject: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC > > I have discovered that my RX6600 cannot use VDPAU to decode HEVC, although > VA-API works OK. Unfortunately, VLC 3.x only supports VDPAU these days for > hardware decoding. > > I have raised this issue: > https://gitlab.freedesktop.org/mesa/mesa/-/issues/10599 > > Mesa 23.3.5 just used to fail, but both Mesa 24.0.1 and 24.1.0-devel actually > lock up the GPU and force me to reboot my PC. > > According to vdpauinfo: > > namelevel macbs width height > > ... > HEVC_MAIN 186 139264 8192 4352 > HEVC_MAIN_10 186 139264 8192 4352 > HEVC_MAIN_STILL--- not supported --- > HEVC_MAIN_12 --- not supported --- > HEVC_MAIN_444 --- not supported --- > HEVC_MAIN_444_10 --- not supported --- > HEVC_MAIN_444_12 --- not supported --- > ... > > Cheers, > Chris
Re: Lavapipe license
What I've seen done elsewhere is to collate all licenses. Last time I checked all components (re)used in mesa had permissive licenses (and this was done by design.)Even if one ends up including a license of a component that's not actually used, one is erring on the safe side. If one stumbles across any restrictive licenses then one would definitely want to ensure it wasn't actually used (I think this happened in the past, for example, with code used just for build time, or something along those lines.) If one really wanted a precise list of components, the most accurate way would be to use some sort of file-system tracing tool while running meson that listed all files touched when building, but it's probably overkill. Though I'm pretty sure src/glx/ is not used for lavapipe, Jose On Tue, Feb 13, 2024 at 10:08 AM George Karpathios wrote: > Hi everyone, > > I'd like to bundle Lavapipe's binary that I've built (also contains LLVM > thanks to static linking) with a commercial application and I'm confused > regarding which licenses I should include into the product. Reading in > https://docs.mesa3d.org/license.html, "Different copyrights and licenses > apply to different components" and "In general, consult the source files > for license terms." makes me think that I should search into every > component that Lavapipe uses (how can I figure these out precisely?), is > that correct? For example, do I need the licenses for LLVM, Main Mesa code, > Gallium, llvmpipe and more? Additionally, looking inside Lavapipe's source > files under src/gallium/frontends/lavapipe, I see various license texts > from RedHat, Intel, AMD, Valve, VMware etc. > > I feel a bit overwhelmed as to what's the proper thing to do, so if anyone > could help me learn how to figure situations like this out, I would be > really grateful. Thanks in advance. > > Best regards, > George > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Re: Lavapipe license
You should only see the MIT license for all Mesa contributions that don't import external source code. Marek On Tue, Feb 13, 2024 at 5:23 AM George Karpathios wrote: > > Hi everyone, > > I'd like to bundle Lavapipe's binary that I've built (also contains LLVM > thanks to static linking) with a commercial application and I'm confused > regarding which licenses I should include into the product. Reading in > https://docs.mesa3d.org/license.html, "Different copyrights and licenses > apply to different components" and "In general, consult the source files for > license terms." makes me think that I should search into every component that > Lavapipe uses (how can I figure these out precisely?), is that correct? For > example, do I need the licenses for LLVM, Main Mesa code, Gallium, llvmpipe > and more? Additionally, looking inside Lavapipe's source files under > src/gallium/frontends/lavapipe, I see various license texts from RedHat, > Intel, AMD, Valve, VMware etc. > > I feel a bit overwhelmed as to what's the proper thing to do, so if anyone > could help me learn how to figure situations like this out, I would be really > grateful. Thanks in advance. > > Best regards, > George
Re: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC
Thanks, I have discovered that my PC needs for VLC to use hardware decoding when playing 4K HEVC streams, but that VLC won't support VA-API again until VLC 4 is released. As an aside, one of these 4K HEVC streams correctly uses VDPAU if I use: $ mpv --vo=gpu --hwdec=vdpau --hwdec-image-format=yuv420p but uses software decoding if I remove the '--hwdec-image-format=yuv420p' parameter because: [vd] Opening decoder hevc [vd] Looking at hwdec hevc-vdpau... [vd] Trying hardware decoding via hevc-vdpau. [vd] Selected codec: hevc (HEVC (High Efficiency Video Coding)) [vd] Pixel formats supported by decoder: vaapi vdpau cuda yuv420p10le [vd] Codec profile: Main 10 (0x2) [ffmpeg] AVHWFramesContext: Unsupported sw format: yuv420p10le Failed to allocate hw frames. [vd] Requesting pixfmt 'yuv420p10le' from decoder. [vd] Attempting next decoding method after failure of hevc-vdpau. [vd] Skipping previously attempted hwdec: hevc-vdpau [vd] Using software decoding. Does this look like another Mesa / VDPAU bug (i.e. should I raise a new issue for it?), or is it actually a problem with mpv? Cheers, Chris On Thu, 15 Feb 2024 at 16:01, Liu, Leo wrote: > > [AMD Official Use Only - General] > > This is being looked. > > > -Original Message- > > From: mesa-dev On Behalf Of > > Chris Rankin > > Sent: Thursday, February 15, 2024 10:38 AM > > To: mesa-dev@lists.freedesktop.org > > Subject: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC > > > > I have discovered that my RX6600 cannot use VDPAU to decode HEVC, although > > VA-API works OK. Unfortunately, VLC 3.x only supports VDPAU these days for > > hardware decoding. > > > > I have raised this issue: > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/10599 > > > > Mesa 23.3.5 just used to fail, but both Mesa 24.0.1 and 24.1.0-devel > > actually > > lock up the GPU and force me to reboot my PC. > > > > According to vdpauinfo: > > > > namelevel macbs width height > > > > ... > > HEVC_MAIN 186 139264 8192 4352 > > HEVC_MAIN_10 186 139264 8192 4352 > > HEVC_MAIN_STILL--- not supported --- > > HEVC_MAIN_12 --- not supported --- > > HEVC_MAIN_444 --- not supported --- > > HEVC_MAIN_444_10 --- not supported --- > > HEVC_MAIN_444_12 --- not supported --- > > ... > > > > Cheers, > > Chris
[ANNOUNCE] mesa 23.3.6
Hello everyone, The bugfix release 23.3.6 is now available. This is the last release of the 23.3 series. Users are encouraged to switch to the 24.0 series to continue receiving bugfixes. Cheers, Eric --- Blisto (1): driconf: set vk_x11_strict_image_count for Atlas Fallen Vulkan Boris Brezillon (2): panfrost: Pad compute jobs with zeros on v4 pan/va: Add missing valhall_enums dep to valhall_disasm Christian Duerr (1): panfrost: Fix dual-source blending Connor Abbott (1): ir3/ra: Fix bug with collect source handling Corentin Noël (1): zink: Only call reapply_color_write if EXT_color_write_enable is available Dave Airlie (5): zink: use sparse residency for buffers. radv: fix correct padding on uvd radv: init decoder ip block earlier. radv/uvd: uvd kernel checks for full dpb allocation. radv: don't submit 0 length on UVD either. David Heidelberg (1): meson: upgrade zlib wrap to 1.3.1 David Rosca (2): frontends/va: Fix updating AV1 rate control parameters radeonsi/vcn: Don't reinitialize encode session on bitrate/fps change Eric Engestrom (12): docs: add sha256sum for 23.3.5 .pick_status.json: Update to 5d293f01cc718af0ea5db3309605cf49dcbf8cca vk/util: fix 'beta' check for physical device features vk/util: fix 'beta' check for physical device properties .pick_status.json: Mark 62508856401e082486f2ff0dc80f17ac852f4882 as denominated .pick_status.json: Mark 7b7a581a52db21ed8826d6f2986ea6dfc208fb2a as denominated .pick_status.json: Mark 46f5a226d6613e0a4c7b3a3496e745090fc14429 as denominated .pick_status.json: Mark 38e92556a041cc421dadb95aaac43a4619311a87 as denominated .pick_status.json: Update to fa8e0ba3f739cb46cf7bb709903c0206f240c584 .pick_status.json: Update to 90eae30bcb84d54dc871ddbb8355f729cf8fa900 docs: add release notes for 23.3.6 VERSION: bump for 23.3.6 Friedrich Vock (2): radv/rt: Write inactive node data in ALWAYS_ACTIVE workaround radv,driconf: Enable active AS leaf workaround for Jedi Survivor Georg Lehmann (3): aco/gfx11+: disable v_pk_fmac_f16_dpp aco: don't remove branches that skip v_writelane_b32 aco/gfx11+: limit hard clauses to 32 instructions José Roberto de Souza (2): iris: Fix return of iris_wait_syncobj() intel: Fix intel_get_mesh_urb_config() Juston Li (1): venus: refactor query feedback cmds Karol Herbst (1): nir/lower_cl_images: record image_buffers and msaa_images Kenneth Graunke (1): driconf: Advertise GL_EXT_shader_image_load_store on iris for SVP13 Konstantin Seurer (2): zink: Always set mfence->submit_count to the fence submit_count Revert "zink: always force flushes when originating from api frontend" Lepton Wu (1): llvmpipe: Set "+64bit" for X86_64 Lionel Landwerlin (1): vulkan/runtime: add helper to query attachment layout M Henning (1): nvk: Don't clobber vb0 after repeated blits Mark Janes (1): hasvk: add missing linker arguments Mike Blumenkrantz (7): zink: fix sparse bo placement zink: zero allocate resident_defs array in ntv zink: move sparse lowering up in file zink: run sparse lowering after all optimization passes mesa: plumb errors through to texture allocation zink: adjust swizzled deref loads by the variable component offset nir/lower_io: fix handling for compact arrays with indirect derefs Pavel Ondračka (1): r300: fix vs output register indexing Pierre-Eric Pelloux-Prayer (1): egl/drm: flush before calling get_back_bo Rhys Perry (1): aco: fix >8 byte linear vgpr copies Rob Clark (1): freedreno: Fix MSAA z/s layout in GMEM Samuel Pitoiset (1): radv: fix RGP barrier reason for RP barriers inserted by the runtime Sviatoslav Peleshko (2): anv,driconf: Add sampler coordinate precision workaround for AoE 4 driconf: Apply dual color blending workaround to Dying Light Tapani Pälli (1): anv: flush tile cache independent of format with HIZ-CCS flush Timothy Arceri (2): glsl: don't tree graft globals Revert "ci: Enable GALLIUM_DUMP_CPU=true only in the clang job" git tag: mesa-23.3.6 https://mesa.freedesktop.org/archive/mesa-23.3.6.tar.xz SHA256: cd3d6c60121dea73abbae99d399dc2facaecde1a8c6bd647e6d85410ff4b577b mesa-23.3.6.tar.xz SHA512: b52ee34de90b77cd4f204a0cfeabc72064f30c3a11668b5280ad5d1c59c3c805b14a8d892f33c32db68a8ada330fbe7fe2124edccfd45cc84636ca7605c10048 mesa-23.3.6.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-23.3.6.tar.xz.sig signature.asc Description: PGP signature
Re: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC
Hi, Please use the issue tracker on the Mesa Gitlab for discussing bug reports. I recommend to include all information that you can in there, we don't use this mailing list for bug reports. Thanks & best regards, Timur On Thu, 2024-02-15 at 17:23 +, Chris Rankin wrote: > Thanks, I have discovered that my PC needs for VLC to use hardware > decoding when playing 4K HEVC streams, but that VLC won't support > VA-API again until VLC 4 is released. > > As an aside, one of these 4K HEVC streams correctly uses VDPAU if I > use: > > $ mpv --vo=gpu --hwdec=vdpau --hwdec-image-format=yuv420p > > but uses software decoding if I remove the > '--hwdec-image-format=yuv420p' parameter because: > > [vd] Opening decoder hevc > [vd] Looking at hwdec hevc-vdpau... > [vd] Trying hardware decoding via hevc-vdpau. > [vd] Selected codec: hevc (HEVC (High Efficiency Video Coding)) > [vd] Pixel formats supported by decoder: vaapi vdpau cuda yuv420p10le > [vd] Codec profile: Main 10 (0x2) > [ffmpeg] AVHWFramesContext: Unsupported sw format: yuv420p10le > Failed to allocate hw frames. > [vd] Requesting pixfmt 'yuv420p10le' from decoder. > [vd] Attempting next decoding method after failure of hevc-vdpau. > [vd] Skipping previously attempted hwdec: hevc-vdpau > [vd] Using software decoding. > > Does this look like another Mesa / VDPAU bug (i.e. should I raise a > new issue for it?), or is it actually a problem with mpv? > > Cheers, > Chris > > On Thu, 15 Feb 2024 at 16:01, Liu, Leo wrote: > > > > [AMD Official Use Only - General] > > > > This is being looked. > > > > > -Original Message- > > > From: mesa-dev On Behalf > > > Of > > > Chris Rankin > > > Sent: Thursday, February 15, 2024 10:38 AM > > > To: mesa-dev@lists.freedesktop.org > > > Subject: [BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC > > > > > > I have discovered that my RX6600 cannot use VDPAU to decode HEVC, > > > although > > > VA-API works OK. Unfortunately, VLC 3.x only supports VDPAU these > > > days for > > > hardware decoding. > > > > > > I have raised this issue: > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/10599 > > > > > > Mesa 23.3.5 just used to fail, but both Mesa 24.0.1 and 24.1.0- > > > devel actually > > > lock up the GPU and force me to reboot my PC. > > > > > > According to vdpauinfo: > > > > > > name level macbs width height > > > > > > ... > > > HEVC_MAIN 186 139264 8192 4352 > > > HEVC_MAIN_10 186 139264 8192 4352 > > > HEVC_MAIN_STILL --- not supported --- > > > HEVC_MAIN_12 --- not supported --- > > > HEVC_MAIN_444 --- not supported --- > > > HEVC_MAIN_444_10 --- not supported --- > > > HEVC_MAIN_444_12 --- not supported --- > > > ... > > > > > > Cheers, > > > Chris
