[Decode] Reenable VC1 decode for DG2

[nyanmisaka]

The VC1 OLP kernel used by DG2 can share the same legacy CM interface with Gen12/TGLLP.
(BTW the existing kernel seems to target GENX_TGLLP instead of GENX_DG2)

Tested on Arc A380 with a few VC1 video samples.

Fixes: #1658

Signed-off-by: nyanmisaka nst799610810@gmail.com

[nyanmisaka]

cc @Jexu

[mitzsch]

@Jexu Can this be merged?

It "still" works with the current upstream codebase...

[XinfengZhang]

I see, it works, but could you share something about the usage , background? I want understand the motivation. we actually plan to deprecate VC1 decoding ...

[nyanmisaka]

This has been brought up again recently because of an issue on Reddit r/IntelArc. I believe some Blu-ray enthusiasts want to rip discs from VC-1 to more efficient encoding formats like HEVC/AV1 to save hard drive space.

The VC-1 software decoder in ffmpeg only supports single-threading, so no matter how advanced your processor is, it cannot utilize multi-threading. Therefore, transcoding is always slow, even if you use a hardware encoder, especially for Blu-ray movies that are several hours long.

Personally, I don't expect Intel to bring it back on future Xe platforms, but since the VC-1 HAL on DG2 is already open source, it only requires a small patch to make it work by reusing the legacy CM interface from TGL, just as it already works on Windows. Although Intel probably won't want to spend the time validating it.

[mitzsch]

I couldn't have said it better myself! Thanks!

• Video decoding performed in hardware is more efficient than doing it on the system's CPU... This frees up resources that can be used elsewhere.

I know that VC-1 is a legacy codec and (luckily) no new content is released in VC-1, but as the user on Reddit wrote, there is still content available out there... and the hardware supports it! So why depcrecate and remove that capability?

[Zepmann]

Tested this as a patch for an Arch Linux package building recipe based on package intel-media-driver. It works flawlessly on Arc A310.

@XinfengZhang, @guowillyy
I am not trying to interfere in your planning, but can you please give some indication on whether:

1. This PR has a chance of being merged?
2. An indication of when you have time to thoroughly review this and maybe merge it (if approved, of course)?

I see no disadvantages. My 2 cents:

• The hardware supports this.
• The code is fully open source, so I would say there is no conflict of interest.
• Windows already supports VC-1 decoding on DG2. Why not Linux? 😃

[nyanmisaka]

@Zepmann Unfortunately, Intel's own open-source collaboration methods differ significantly from similar projects like Mesa. If they have a reason not to support a deprecated feature and don't want to invest resources in testing, the code may never be merged, and you'll need to carry the patches yourself.

[XinfengZhang]

I m not sure whether there is some risk that you replace current DG2 ISA with TGL one.

[XinfengZhang]

it means that these two kernel ISA will removed , why?

[nyanmisaka]

These two DG2 kernels have never been open sourced or upstreamed to this repo, so they are disabled by _MEDIA_RESERVED. Do you have any closed-source drivers using them internally?

[XinfengZhang]

looks you are using TGL isa on DG2?

[nyanmisaka]

Yes, this was done intentionally. The last platform CM supported was TGLx. DG2's VC1 kernel contained GENX_TGLLP instead of GENX_DG2, and not doing so would cause CM to fail when loading and verifying the kernel.

[XinfengZhang]

typo

[nyanmisaka]

Fixed

[XinfengZhang]

@nyanmisaka , thanks for contribution. about the PR, I still have 1 concern about changing CMHal from CmHalXe_Xpm;
to CM_HAL_G12_X, I actually not sure whether this cm HAL only used for OLP kernel or all kernels?

[nyanmisaka]

@nyanmisaka , thanks for contribution. about the PR, I still have 1 concern about changing CMHal from CmHalXe_Xpm; to CM_HAL_G12_X, I actually not sure whether this cm HAL only used for OLP kernel or all kernels?

Other functions on the DG2 do not depend on the CM device - they are either already embedded in the hardware via Low-Power mode or are film-grain kernels in AV1 decoding that do not depend on the CM. VC1 OLP kernel is the only function that requires CM initialization.

Regarding reliability, we have a large number of users using Alchemist in their transcoding servers. We've included this patch in our own iHD driver build since 2024, and we haven't received any reports of a regression.

We cannot guarantee that we have tested each type of VC1 sample, so if you later find a regression, feel free to revert it.

[XinfengZhang]

just like you mentioned , from my perspective, accepting new feature always means we should enlarge our test/release scope. but we will accept the feature enabling PR if there is real user, or someone's usage was blocked. maybe will not claim support on frontpage (is it ok for you? ) .
for this PR itself, from my personal perspective, VC1 should be deprecated, but just like your comments , someone is still using it. (actually, maybe I misunderstand something, looks the original request if for B580? it is battlemage), the PR is LGTM now.

[Zepmann]

@XinfengZhang

I think whether a codec should be deprecated or not solely based on its age/usage is not a good discussion. DG2 also supports decoding of MPEG-2, which is even older and also rarely used these days. Furthermore, CPU's have no problem decoding MPEG-2 in software.

Instead, I would look at what the hardware can support. DG2 supports decoding of VC-1. It already does this in Windows. So why not support it in Linux? The hardware is there, the use cases are there (I also use this). Why not include it in the software?

I agree that it must be tested well and not cause regressions, of course. However, looking at @nyanmisaka and my experience with this patch, I would not expect trouble coming from this. And if in an obscure, untested scenario trouble occurs, the patch can always be reverted.

[nyanmisaka]

just like you mentioned , from my perspective, accepting new feature always means we should enlarge our test/release scope. but we will accept the feature enabling PR if there is real user, or someone's usage was blocked. maybe will not claim support on frontpage (is it ok for you? ) . for this PR itself, from my personal perspective, VC1 should be deprecated, but just like your comments , someone is still using it. (actually, maybe I misunderstand something, looks the original request if for B580? it is battlemage), the PR is LGTM now.

I understand that not stating it in the README is a form of disclaimer. This is perfectly acceptable as community level support.

VC1 has been removed from Battlemage and similar Xe2+ platforms, making it impossible to enable using this method. Therefore, this PR is entirely Alchemist oriented.