Dave Airlie Linux Graphics blog

F38 just released and seeing a bunch of people complain that TF2 dies on AMD or other platforms when lavapipe is installed. Who's at fault? I've no real idea. How to fix it? I've no real idea. What's happening? AMD OpenGL drivers use LLVM as the backend compiler. Fedora 38 updated to LLVM 16. LLVM 16 is built with c++17 by default. C++17 introduces new "operator new/delete" interfaces[1]. TF2 ships with it's own libtcmalloc_minimal.so implementation, tcmalloc expects to replace all the new/delete interfaces, but the version in TF2 must not support or had incorrect support for the new align interfaces. What happens is when TF2 probes OpenGL and LLVM is loaded, when DenseMap initializes, one "new" path fails to go into tcmalloc, but the "delete" path does, and this causes tcmalloc to explode with "src/tcmalloc.cc:278] Attempt to free invalid pointer" Fixing it? I'll talk to Valve and see if we can work out something, LLVM 16...

There are plans for nouveau to support using the NVIDIA supplied GSP firmware in order to support new hardware going forward The nouveau project doesn't have any input or control over the firmware. NVIDIA have made no promises around stable ABI or firmware versioning. The current status quo is that NVIDIA will release versioned signed gsp firmwares as part of their driver distribution packages that are version locked to their proprietary drivers (open source and binary). They are working towards allowing these firmwares to be redistributed in linux-firmware. The NVIDIA firmwares are quite large. The nouveau project will control the selection of what versions of the released firmwares are to be supported by the driver, it's likely a newer firmware will only be pulled into linux-firmware for: New hardware support (new GPU family or GPU support) Security fix in the firmware New features that is required to be supported This should at least limit the number of firmwares in the linu...

While going over the AV1 a few people commented on the lack of VP9 and a few people said it would be an easier place to start etc. Daniel Almeida at Collabora took a first pass at writing the spec up, and I decided to go ahead and take it to a working demo level. Lynne was busy, and they'd already said it should take an afternoon, so I decided to have a go at writing the ffmpeg side for it as well as finish off Daniel's radv code. About 2 mins before I finished for the weekend on Friday, I got a single frame to decode, and this morning I finished off the rest to get at least 2 test videos I downloaded to work. Branches are at [1] and [2]. There is only 8-bit support so far and I suspect some cleaning up is required. [1] https://github.com/airlied/FFmpeg/tree/vulkan-vp9-decode [2] https://gitlab.freedesktop.org/airlied/mesa/-/commits/radv-vulkan-video-decode-mesa-vp9

 Okay just a short status update. radv H264/H265 decode: The radv h264/h265 support has been merged to mesa main branch. It is still behind RADV_PERFTEST=video_decode flag, and should work for basics from VI/GFX8+. It still has not passed all the CTS tests. anv H264 decode: The anv h264 decode support has been merged to mesa main branch. It has been tested from Skylake up to DG2. It has no enable flag, just make sure to build with h264dec video-codec support. It passes all current CTS tests. hasvk H264 decode: I ported the anv h264 decoder to hasvk the vulkan driver for Ivybridge/Haswell. This in a draft MR ( HASVK H264 ). I haven't given this much testing yet, it has worked in the past. I'll get to testing it before trying to get it merged. radv AV1 decode: I created an MR for spec discussion ( radv av1 ). I've also cleaned up the radv AV1 decode code. anv AV1 decode: I've started on anv AV1 decode support for DG2. I've gotten one very simple frame to decode. I wil...

After hacking the Intel media-driver and ffmpeg I managed to work out how the anv hardware mostly works now for h264 decoding. I've pushed a branch [1] and a MR[2] to mesa. The basics of h264 decoding are working great on gen9 and compatible hardware. I've tested it on my one Lenovo WhiskeyLake laptop. I have ported the code to hasvk as well, and once we get moving on this I'll polish that up and check we can h264 decode on IVB/HSW devices. The one feature I know is missing is status reporting, radv can't support that from what I can work out due to firmware, but anv should be able to so I might dig into that a bit. [1] https://gitlab.freedesktop.org/airlied/mesa/-/tree/anv-vulkan-video-decode [2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20782

Needless to say h264/5 weren't my real goals in life for video decoding. Lynne and myself decided to see what we could do to drive AV1 decode forward by creating our own extensions called VK_MESA_video_decode_av1. This is a radv only extension so far, and may expose some peculiarities of AMD hardware/firmware. Lynne's blog entry[1] has all the gory details, so go read that first. (really read it first). Now that you've read and understood all that, I'll just rant here a bit. Figuring out the DPB management and hw frame ref and curr_pic_idx fields was a bit of a nightmare. I spent a few days hacking up a lot of wrong things before landing on the thing we agreed was the least wrong which was having the ffmpeg code allocate a frame index in the same fashion as the vaapi radeon implementation did. I had another hacky solution that involved overloading the slotIndex value to mean something that wasn't DPB slot index, but it wasn't really any better. I think there may...

After the video decode stuff was fairly nailed down, Lynne from ffmpeg nerdsniped^Wtalked me into looking at h264 encoding. The AMD VCN encoder engine is a very different interface to the decode engine and required a lot of code porting from the radeon vaapi driver. Prior to Xmas I burned a few days on typing that all in, and yesterday I finished typing and moved to debugging the pile of trash I'd just typed in. Lynne meanwhile had written the initial ffmpeg side implementation, and today we threw them at each other, and polished off a lot of sharp edges. We were rewarded with valid encoded frames. The code at this point is only doing I-frame encoding, we will work on P/B frames when we get a chance. There are also a bunch of hacks and workarounds for API/hw mismatches, that I need to consult with Vulkan spec and AMD teams about, but we have a good starting point to move forward from. I'll also be offline for a few days on holidays so I'm not sure it will get much further u...