fix(vaapi): force CQP on Intel xe driver where HuC is unavailable

[ssdnk]

Problem

Intel Arc A770 (DG2/XeHPG) with the xe kernel driver does not load HuC firmware, which causes CBR/VBR rate control to fail at encode time — even though vaGetConfigAttributes() incorrectly reports support for them.

Solution

Added is_xe_driver() which detects the kernel driver via sysfs. When the xe driver is detected, VA_RC_CBR and VA_RC_VBR are stripped from the rc_attr bitmask before rate control selection. The existing fallback path then correctly selects CQP using the user-configured qp value.

Tested on

• GPU: Intel Arc A770
• • Driver: xe kernel driver
• • Kernel: Linux 7.0.8 (CachyOS)

Log output

Using LP encoding mode
xe driver detected: HuC unavailable, forcing CQP rate control
Using CQP with single frame VBV size

My own logs
logs.log

[ClassicOldSong]

So are there other drivers for the arc series cards? Is this only affecting A770 or broader?

[ssdnk]

So are there other drivers for the arc series cards? Is this only affecting A770 or broader?

There is i915 which does support HuC on DG2, so VAAPI works fine there. But i915 lacks VM_BIND, which breaks sparse residency in vkd3d-proton. For anyone gaming via Proton, xe is the only viable option.

All DG2/Alchemist (Arc A-series). Intel has explicitly decided not to implement HuC for DG2 in xe. Older Intel cards (pre-DG2) and Arc B-series are unaffected.

https://www.phoronix.com/news/Intel-Xe-DG2-No-HuC

[ssdnk]

I see. is_xe_driver() would also affect Arc B-series which uses the xe driver but has working HuC. Working on a fix to check the actual HuC status.

[ssdnk]

Initial xe driver detection would incorrectly affect Arc B-series and newer where HuC works fine. Replaced it with an explicit vaapi_force_cqp config option and UI toggle instead.