AMD Radeon™ 890M HW Acceleration

#1

I am working on a new Proxmox setup for my Channels Configuration. As part of it I am using a Minisform M5 Pro that has an AMD Radeon 890M. Is this supported via AMF?

Here is my output and it denotes an issue with an unknown family_id and chip_external_rev:

h264_amf
[Parsed_testsrc_0 @ 0x262a5a40] size:1280x720 rate:60/1 duration:-1.000000 sar:1/1
Input #0, lavfi, from 'testsrc=size=1280x720:rate=60':
  Duration: N/A, start: 0.000000, bitrate: N/A
  Stream #0:0: Video: wrapped_avframe, 1 reference frame, rgb24, 1280x720 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 60 tbn
Stream mapping:
  Stream #0:0 -> #0:0 (wrapped_avframe (native) -> h264 (h264_amf))
Press [q] to stop, [?] for help
[graph 0 input from stream 0:0 @ 0x262ae2c0] w:1280 h:720 pixfmt:rgb24 tb:1/60 fr:60/1 sar:1/1
[auto_scale_0 @ 0x262adc40] w:iw h:ih flags:'' interl:0
[format @ 0x262af8c0] auto-inserting filter 'auto_scale_0' between the filter 'Parsed_null_0' and the filter 'format'
[auto_scale_0 @ 0x262adc40] w:1280 h:720 fmt:rgb24 sar:1/1 -> w:1280 h:720 fmt:yuv420p sar:1/1 flags:0x00000004
amdgpu: unknown (family_id, chip_external_rev): (150, 20)
[h264_amf @ 0x262aaa40] AMF failed to initialise on the given Vulkan device: 1.
[vost#0:0/h264_amf @ 0x262aa740] Error initializing output stream: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Terminating demuxer thread 0
Conversion failed!

On the same processor if I do a vainfo run:

root@tcode:~/channels-dvr# vainfo
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: can't connect to X server!
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_17
amdgpu: unknown (family_id, chip_external_rev): (150, 20)
libva error: /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so init failed
libva info: va_openDriver() returns 2
vaInitialize failed with error code 2 (resource allocation failed),exit

But if I upgrade my mesa components to the trixie backports to get a new version into debian 12, vainfo now works but my container doesn't have that setup right now. Let me know if you need to see that also.

#2

I had more time tonight so I installed installed a newer mesa-va-drivers:

apt install mesa-va-drivers/bookworm-backports

And now vainfo does work so passthrough is likely correct. Here is the output of vainfo:

root@tcode:~/channels-dvr# vainfo
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: can't connect to X server!
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.12.0)
vainfo: Driver version: Mesa Gallium driver 25.0.7-2~bpo12+1 for AMD Radeon Graphics (radeonsi, gfx1150, ACO, DRM 3.61, 6.14.11-2-pve)
vainfo: Supported profile and entrypoints
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointEncSlice
      VAProfileNone                   : VAEntrypointVideoProc

So given that vainfo works with newer drivers and both vainfo and AMF failed with unknown family and chip revs before, I suspect I need an updated part of channels.

#3

We only support amf for AMD transcoding, so the va drivers won't help.

Possible we need to update our version of AMF

#4

I understand va drivers are not supported. I only provided vainfo to denote that it was likely a need for a new version of AMF to support brand new hardware.

1 Like
#5

Maybe you have to install the amdgpu-install driver?

We're already using v1.4.36 which is latest

#6

I have a Minisform N5 Pro running Proxmox 9 with a Debian 12 LXC container that now supports Hardware Transcode!

image
image730×110 16.7 KB

Time to blow away the computer and reinstall from scratch to figure out the exact things that worked.

Here is the debug:

[Parsed_testsrc_0 @ 0x106f7a40] size:1280x720 rate:60/1 duration:-1.000000 sar:1/1
Input #0, lavfi, from 'testsrc=size=1280x720:rate=60':
  Duration: N/A, start: 0.000000, bitrate: N/A
  Stream #0:0: Video: wrapped_avframe, 1 reference frame, rgb24, 1280x720 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 60 tbn
Stream mapping:
  Stream #0:0 -> #0:0 (wrapped_avframe (native) -> h264 (h264_amf))
Press [q] to stop, [?] for help
[graph 0 input from stream 0:0 @ 0x107002c0] w:1280 h:720 pixfmt:rgb24 tb:1/60 fr:60/1 sar:1/1
[auto_scale_0 @ 0x106ffc40] w:iw h:ih flags:'' interl:0
[format @ 0x107018c0] auto-inserting filter 'auto_scale_0' between the filter 'Parsed_null_0' and the filter 'format'
[auto_scale_0 @ 0x106ffc40] w:1280 h:720 fmt:rgb24 sar:1/1 -> w:1280 h:720 fmt:yuv420p sar:1/1 flags:0x00000004
[h264_amf @ 0x106fca40] AMF initialisation succeeded via Vulkan.
Output #0, null, to '/dev/null':
  Metadata:
    encoder         : Lavf60.3.100
  Stream #0:0: Video: h264, 1 reference frame, yuv420p(tv, progressive), 1280x720 (0x0) [SAR 1:1 DAR 16:9], q=2-31, 4000 kb/s, 60 fps, 60 tbn
    Metadata:
      encoder         : Lavc60.3.100 h264_amf
No more output streams to write to, finishing.
[out#0/null @ 0x106fb8c0] All streams finished
[out#0/null @ 0x106fb8c0] Terminating muxer thread
frame=   60 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.98 bitrate=N/A speed=7.19x    
[AVIOContext @ 0x106f5900] Statistics: 398 bytes written, 0 seeks, 2 writeouts
video:53kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Input file #0 (testsrc=size=1280x720:rate=60):
  Input stream #0:0 (video): 61 packets read (29280 bytes); 61 frames decoded; 
  Total: 61 packets (29280 bytes) demuxed
Output file #0 (/dev/null):
  Output stream #0:0 (video): 60 frames encoded; 60 packets muxed (53812 bytes); 
  Total: 60 packets (53812 bytes) muxed
Terminating demuxer thread 0

I have done a whole bunch of stuff so I am not sure exactly what worked. I will come back after my rebuild and give some more details.

#7

Here are the steps in my solution:

  1. Installed Proxmox 9
  2. Changed to the non-subscription repo
  3. Updated Proxmox to the latest version
  4. Rebooted the computer
  5. Downloaded Debian 12 template (as Debian 13 isn't yet ready for a Proxmox LXC)
  6. Created LXC Privileged Container with Debian 12
  7. Passed thru /dev/dri/card1 to the container making sure the permissions and owners were correct.
  8. Passed thru /dev/dri/renderD128 to the container making sure the permissions and owners were correct.
  9. Started the container
  10. Updated container to support bookwork backports (hopefully Debian 13 removes the need for this):
    10.1. Added bookworm backports to the container
    10.2 Updated the mesa-vulkan-drivers package in the container to the bookwork back ports
  11. Added curl to the container
  12. Downloaded the Jammy version of amdgpu-install for 6.4.4 from AMD
  13. Installed the AMF libraries to the container using: amdgpu-install --accept-eula --usecase=amf --no-dkms
  14. Installed Channels

And that allows for hardware transcoding in the container via Channels.

@tmm1 The magic was in that bug report. It led me down the path that Vulkan had to be upgraded in the container and that the AMDGPU driver in the Proxmox kernel was likely aok for this.

Thanks for a great product and AWESOME support!

1 Like
#8

Congratulations! As a huge fan, and several year user of Proxmox, your "blow away the computer" comment caught my attention. Hopefully you're talking about blowing away the LXC, and not Proxomox, as that would suggest you've made many changes to it.

You may already know this, and if so hopefully this comment will benefit somebody else in the future, but Proxmox is at its very best when installing anything at the hypervisor level is kept to an absolute minimum. Other than drivers for the iGPU, intel-gpu-tools and Tailscale, I'd be hard-pressed to think of anything else I've needed to install directly on Proxmox.

I credit this "keep it stock" approach to both month-upon-month of continuous uptime, and the flawless in-place upgrades I've been able to make when moving between major Proxmox releases. I'm probably preaching to the choir :slight_smile:, but I still remember having to fight a few of my own impulses when getting started with Proxmox.

#9

Thanks!

Actually I did wipe the box down to nothing and start over. I made a number of changes trying to sort thru the issue and wanted to get back to stock. I like to have a known condition for things like this. I want this to run for years with no trouble.

This is my first foreray into Proxmox but have used other Hypervisors for years at the office. I knew I was close with everything stock in Proxmox and I made the choice of actually installing something in the host to try and get further. WIth the rebuild, I know I didn't need to do that.

Onto my next item in the build up to a Home Server Cluster.

#10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.