va: AMD: Wrong buffer size of P010 Luma plane
System information
Please post inxi -GSC -xx
output (fenced with triple backticks) OR fill information below manually
System:
Host: nicolas-tpx395.localdomain Kernel: 5.17.6-300.fc36.x86_64
arch: x86_64 bits: 64 compiler: gcc v: 2.37-27.fc36 Desktop: GNOME v: 42.0
tk: GTK v: 3.24.33 wm: gnome-shell dm: GDM
Distro: Fedora release 36 (Thirty Six)
CPU:
Info: quad core model: AMD Ryzen 7 PRO 3700U w/ Radeon Vega Mobile Gfx
bits: 64 type: MT MCP arch: Zen/Zen+ note: check rev: 1 cache: L1: 384 KiB
L2: 2 MiB L3: 4 MiB
Speed (MHz): avg: 1571 high: 2813 min/max: 1400/2300 boost: enabled
cores: 1: 1395 2: 1394 3: 1397 4: 1397 5: 2813 6: 1397 7: 1388 8: 1394
bogomips: 36727
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
Device-1: AMD Picasso/Raven 2 [Radeon Vega Series / Radeon Mobile Series]
vendor: Lenovo driver: amdgpu v: kernel pcie: speed: 8 GT/s lanes: 16
ports: active: DP-5 off: eDP-1 empty: DP-1, DP-2, DP-3, DP-6, HDMI-A-1
bus-ID: 05:00.0 chip-ID: 1002:15d8
Device-2: Logitech StreamCam type: USB
driver: hid-generic,snd-usb-audio,usbhid,uvcvideo bus-ID: 3-4.1:23
chip-ID: 046d:0893
Device-3: INOGENI 252E-INOGENI 4K2USB3 type: USB
driver: hid-generic,snd-usb-audio,usbhid,uvcvideo bus-ID: 3-4.2.3:25
chip-ID: 2997:0004
Device-4: Lite-On Integrated Camera type: USB driver: uvcvideo
bus-ID: 4-2.1:4 chip-ID: 04ca:7070
Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 22.1.1
compositor: gnome-shell driver: X: loaded: amdgpu
unloaded: fbdev,modesetting,vesa gpu: amdgpu display-ID: 0
Monitor-1: DP-5 res: 3840x2160 size: N/A
OpenGL: renderer: AMD Radeon Vega 10 Graphics (raven LLVM 14.0.0 DRM 3.44
5.17.6-300.fc36.x86_64)
v: 4.6 Mesa 22.0.3 direct render: Yes
Describe the issue
While debugging what I expected to be a GStreamer bug, I endup finding that I'm getting the wrong DMABuf size for the Luma plane when I allocate P010 VA buffers (AMD Vega Mobile GPU as reported in previous section). Here's the dump of the VADRMPRIMESurfaceDescriptor
.
va_create_surfaces (display=0x7fff8c04b570, rt_format=rt_format@entry=256, fourcc=fourcc@entry=808530000, width=3840, height=2160, usage_hint=1, ext_buf=0x0, surfaces=0x7fff9a7fb05c, num_surfaces=1)
va_export_surface_to_dmabuf (display=0x7fff8c04b570, surface=3, flags=7, desc=desc@entry=0x7fff9a7fb0b0)
$4 = {
fourcc = 808530000,
width = 3840,
height = 2160,
num_objects = 2,
objects = {{
fd = 28,
size = 8294400,
drm_format_modifier = 0
}, {
fd = 29,
size = 8294400,
drm_format_modifier = 0
}, {
fd = 0,
size = 0,
drm_format_modifier = 0
}, {
fd = 0,
size = 0,
drm_format_modifier = 0
}},
num_layers = 2,
layers = {{
drm_format = 540422482,
num_planes = 1,
object_index = {0, 0, 0, 0},
offset = {0, 0, 0, 0},
pitch = {7680, 0, 0, 0}
}, {
drm_format = 842224199,
num_planes = 1,
object_index = {1, 0, 0, 0},
offset = {16588800, 0, 0, 0},
pitch = {7680, 0, 0, 0}
}, {
drm_format = 0,
num_planes = 0,
object_index = {0, 0, 0, 0},
offset = {0, 0, 0, 0},
pitch = {0, 0, 0, 0}
}, {
drm_format = 0,
num_planes = 0,
object_index = {0, 0, 0, 0},
offset = {0, 0, 0, 0},
pitch = {0, 0, 0, 0}
}}
}
The fourcc is P010
, meaning the luma plane should have 2 bytes per pixels, that also match the layer fourcc R16
. But the reported size is only 8294400 instead of 16588800.
The rest looks fine to me. I am a little surprise that the offset of the second layer is not relative to the dmabuf start, but includes the expected size of the first dmabuf here. But I'm not familiar enough with VA API to judge, GStreamer seems so assume that, remains very odd to me, this would not be true for lets say GL Dmabuf import. Both offsets would be 0.
Regression
I must admit, I don't know if its a regression or if it never worked. If the VA surface is derived instead, everything works. So the buffer size must be fine internally somewhere.
Any extra information would be greatly appreciated
I'm reproducing this with GStreamer master (its mono repo now and using meson, so perhaps its possible for folks to build and reproduce if needed ?) I would expect other implementation, like ffmpeg DRM hardware context to suffer similar issues. The command to reproduce:
GST_PLUGIN_FEATURE_RANK=vah265dec:MAX gdb --args gst-play-1.0 --use-playbin3 --videosink=glimagesink 10bit.hevc
You can simply break on va_create_surfaces/va_export_surface_to_dmabuf to start digging.