[BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC

[Chris Rankin]

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

[Chris Rankin]

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

[BUG][AMD][VDPAU] RX6600 GPU locks up when decoding HEVC

[Chris Rankin]

Hi,

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

[Mesa-dev] [BUG] Large slowdown with RADV / Warcraft with latest Mesa from Git.

[Chris Rankin]

Hi,

I've just noticed a large drop in FPS (from 60 down to 15) when playing World 
of Warcraft with the latest Mesa from Git.
A quick git bisect has identified this commit:

4292fb2139282e6906d4ad2a8be2fd81ed7ca8af is the first bad commit
commit 4292fb2139282e6906d4ad2a8be2fd81ed7ca8af
Author: Michel Dänzer 
Date:   Mon Dec 21 15:41:56 2020 +0100

    wsi/x11: Use PresentOptionAsync for MAILBOX present mode with Xwayland
    
    This allows Xwayland to forward buffers to the Wayland compositor ASAP
    for fullscreen / undecorated windows, which in turn allows true mailbox
    behaviour in the Wayland compositor.
    
    Without this, Xwayland has to emulate the mailbox behaviour itself,
    which it cannot do as well as the Wayland compositor by design.
    
    Reviewed-by: Bas Nieuwenhuizen 
    Part-of: 

 src/vulkan/wsi/wsi_common_x11.c | 7 +++
 1 file changed, 7 insertions(+)

I am playing WoW with this release of Wine:

wine-6.0-0.4rc4.fc33.x86_64

And this version of DXVK:

wine-dxvk-1.7.2-3.fc33.x86_64

Curiously, I am using Xorg rather than Wayland, and so don't understand why 
this commit should affect me.

Glxinfo reports the following:

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon (TM) R7 300 Series (BONAIRE, DRM 3.40.0, 5.10.5, LLVM 
12.0.0) (0x665f)
    Version: 21.0.0
    Accelerated: yes
    Video memory: 2048MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 1483 MB, largest block: 1483 MB
    VBO free aux. memory - total: 2691 MB, largest block: 2691 MB
    Texture free memory - total: 1483 MB, largest block: 1483 MB
    Texture free aux. memory - total: 2691 MB, largest block: 2691 MB
    Renderbuffer free memory - total: 1483 MB, largest block: 1483 MB
    Renderbuffer free aux. memory - total: 2691 MB, largest block: 2691 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 2048 MB
    Total available memory: 5120 MB
    Currently available dedicated video memory: 1483 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon (TM) R7 300 Series (BONAIRE, DRM 3.40.0, 
5.10.5, LLVM 12.0.0)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.0.0-devel 
(git-4292fb2139)

Cheers,
Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [BUG] Large slowdown with RADV / Warcraft with latest Mesa from Git.

[Chris Rankin]

Hi, thanks for replying.

Yes, that simple patch seems to have done the trick.

Cheers,
Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Fix dependency generation for src/mesa/main directory

[Chris Rankin]

Hi,

Ah, so "\file" is for doxygen? I did wonder whether it could be something other 
than a typo :-).

My dependency problem happens only for the file main/dlist.c, and only on my 
T60p. I have *absolutely no idea* why makedepend goes off the deep-end only on 
this machine and not on any of my others. Perhaps someone with makedepend 
wisdom could shed some light, please?

As for my other 64/32 bit problem:

> You'll want to do:
> CFLAGS='-m32 -O2 -g -gdwarf-2' CXXFLAGS='-m32 -O2 -g -gdwarf-2
> ./autogen.sh  --enable-32-bit

Shouldn't the "-m32" flag be implicit in the --enable-32-bit option? I'm only 
adding an explicit CFLAGS to ensure Mesa is built with debug symbols ("just in 
case").


Thanks,
Chris




 From: Kenneth Graunke 
To: Chris Rankin  
Cc: mesa-dev@lists.freedesktop.org 
Sent: Wednesday, 13 June 2012, 8:50
Subject: Re: [Mesa-dev] [PATCH] Fix dependency generation for src/mesa/main 
directory
 
On 06/12/2012 03:42 PM, Chris Rankin wrote:
> Hi,
> 
> I have a Lenovo T60p laptop running 32 bit Fedora 17, and this patch
> fixes makedepend's behaviour when generating the src/mesa/depends file.
> Prior to this patch, makedepend had hung while still consuming 100% of
> the CPU. Strangely, none of the other PCs that I compile Mesa on are
> affected by this problem, despite all of them running Fedora 17 too!

Wow :/ makedepend is even more broken than I thought.

This patch breaks doxygen, so I'd rather not take it if possible...

> For reference, here is the command line I configure Mesa with:
> 
> CFLAGS='-O2 -g -gdwarf-2' ./autogen.sh --prefix=$HOME/local-mesa
> --with-gallium-drivers=swrast,r300,r600 --with-dri-drivers=
> --enable-texture-float --enable-gallium-g3dvl --enable-32-bit

You'll want to do:
CFLAGS='-m32 -O2 -g -gdwarf-2' CXXFLAGS='-m32 -O2 -g -gdwarf-2'
./autogen.sh  --enable-32-bit

(you need -m32 and you need to set CXXFLAGS).  Then it should work.

> Cheers,
> Chris
> 
> P.S. Has anyone tried compiling 32 bit Mesa on a 64 bit machine recently?___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Fix dependency generation for src/mesa/main directory

[Chris Rankin]

Hi,

I have a Lenovo T60p laptop running 32 bit Fedora 17, and this patch 
fixes makedepend's behaviour when generating the src/mesa/depends file. 
Prior to this patch, makedepend had hung while still consuming 100% of 
the CPU. Strangely, none of the other PCs that I compile Mesa on are 
affected by this problem, despite all of them running Fedora 17 too!


For reference, here is the command line I configure Mesa with:

CFLAGS='-O2 -g -gdwarf-2' ./autogen.sh --prefix=$HOME/local-mesa 
--with-gallium-drivers=swrast,r300,r600 --with-dri-drivers= 
--enable-texture-float --enable-gallium-g3dvl --enable-32-bit


Cheers,
Chris

P.S. Has anyone tried compiling 32 bit Mesa on a 64 bit machine recently?
diff --git a/src/mesa/main/mfeatures.h b/src/mesa/main/mfeatures.h
index b67f046..fdfa8ce 100644
--- a/src/mesa/main/mfeatures.h
+++ b/src/mesa/main/mfeatures.h
@@ -24,7 +24,7 @@
 
 
 /**
- * \file mfeatures.h
+ * file mfeatures.h
  * Flags to enable/disable specific parts of the API.
  */
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

AV1 hardware decoding problems with latest Mesa 25.0.0-devel

[Chris Rankin]

Hi,

I've just raised this issue in GitLab:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12337

I thought this video was 4:2:0 AV1, and it used to play OK with both
VA-API and VDPAU hardware decoding.

First bad commit is:
in/HEAD)
Author: David Rosca 
Date:   Mon Dec 16 17:26:09 2024 +0100

radeonsi/vcn: Return error when decoding 12bit VP9 and 4:2:2/4:4:4 AV1

Cheers,
Chris