[Question]: Can version 1.4.30 headers be used with AMF 1.4.31 from repo.radeon.com for building ffmpeg?

Since I'm on Ubuntu 22.04 LTS where the default ffmpeg and its associated libraries (e.g. libavcodec, libavdevice, etc.) are not built with AMF support by default, I always have to compile a custom ffmpeg from source in order to use it with AMF, which means of course pulling this repo's contents and copying the headers within AMF/amf/public/include/ over to an AMF/ directory within my system include path per instructions here. Also, each time before I rebuild and reinstall my custom ffmpeg install AFTER updating my system amf-amdgpu-pro install, I always test my amf-amdgpu-pro install using the EncoderLatency sample provided in this repo, because from my experience if that EncoderLatency sample doesn't work with the appropriate headers copied over to the AMF/ directory within my system include path, then there's no way that my custom ffmpeg install will work with the updated system amf-amdgpu-pro install even after rebuilding and reinstalling the custom ffmpeg with the updated appropriate headers copied over.

No more than two weeks ago, after updating my system amf-amdgpu-pro install to the latest version (bundled with amdgpu-pro version 23.10, which in turn was released together with ROCm version 5.5.3), I tested that amf-amdgpu-pro install with the aforementioned EncoderLatency sample, and lo and behold I get an error that basically stated that the system AMF libraries were expecting VCN encoder firmware version 1.26, but found version 1.27 instead. So I solved the issue by rolling back not only my system amf-amdgpu-pro install to an earlier version, but the associated system amdgpu-dkms-firmware install to an earlier version, both of which were still associated with amdgpu-pro version 23.10, but instead were actually released together with an earlier ROCm version 5.5.1 release.

So, just today I saw that ROCm 5.7 dropped, and when I checked repo.radeon.com I also saw here that a new amdgpu-pro version 23.20 was released alongside an updated AMF version 1.4.31 as seen here. However, what I don't know is that if the VCN encoder firmware within amdgpu-dkms-firmware associated with the latest ROCm/amdgpu-pro release has also been updated to an even newer version than what the newly updated AMF system libraries within amf-amdgpu-pro and libamdenc-amdgpu-pro are expecting, and I especially don't know if the headers within AMF/amf/public/include/ in this repo need to be updated to reflect any changes going from AMF version 1.4.30 to AMF version 1.4.31.

May I know then if I will be OK to go ahead and install the latest amdgpu-dkms-firmware/amf-amdgpu-pro/libamdenc-amdgpu-pro etc. as of today (11:30 pm ish on 9/15/23 on the American East Coast) and use the old AMF version 1.4.30 headers with the new AMF version 1.4.31 libraries, or will I have to wait until this public repository also gets officially updated to AMF version 1.4.31? Sorry for the wall of text, I was just trying to explain the context clearly behind my question.

Edit - I also understand that I can probably just test this myself BUT I really don't want to have to go through the trouble of having to roll back my install AGAIN if things don't work out.

In general, driver installation should bring all binaries compatible with each other. This includes firmware, AMF runtime, Vulkan driver and some other libraries. It is better to use AMD Linux installation script as described in the driver installation guide and uninstall older version. Regarding AMF headers: they are always backwards compatible with driver and runtime meaning that an app like FFmpeg built with older headers will be always compatible with newer driver. So you can use older headers if really needed. Note, most of the time such app is also forward-compatible meaning it will run with older driver as long as the presence of newer features is checked and proper fallback is implemented. Like check returned codes when a property is set.

In general, driver installation should bring all binaries compatible with each other. This includes firmware, AMF runtime, Vulkan driver and some other libraries. It is better to use AMD Linux installation script as described in the driver installation guide and uninstall older version. Regarding AMF headers: they are always backwards compatible with driver and runtime meaning that an app like FFmpeg built with older headers will be always compatible with newer driver. So you can use older headers if really needed. Note, most of the time such app is also forward-compatible meaning it will run with older driver as long as the presence of newer features is checked and proper fallback is implemented. Like check returned codes when a property is set.

Unfortunately, I tested the AMF libraries and amdgpu firmware bundled with ROCm 5.7 and ROCm 5.5.3, and neither was able to work due to firmware mismatch errors. Only when I rolled all the way back to the AMF libraries and firmware bundled together with ROCm 5.5.2 was I able to get things working again :/

There is a bug and it will be fixed in an upcoming release. In the meantime, here is a workaround to allow you to proceed with your development. Since it is a workaround, it requires a few extra steps.

Below are the steps for Ubuntu, they should be similar for other OS’s:

1. Download the firmware binaries fw-23.20.tar.gz

2. Copy the firmware binaries into /usr/lib/firmware/updates/amdgpu

3. Run update-initramfs -u

4. Reboot

5. Verify the firmware version: sudo dmesg | grep VCN

   • VCN2 should be: 1.20
   • VCN3 should be: 1.28
   • VCN4 should be: 1.11

Since I broke the system containing my RX 6800 while attempting to upgrade its system memory, and no longer have the time nor energy to maintain my own desktop system, I just sold my RX 6800 (my only AMD GPU). Therefore, since I will not be able to repro the fix of this issue anymore, I am closing this issue for the time being. Will be more than willing to reopen this if anyone else runs into the same issue as me.