[FFmpeg-devel] [PATCH v6 00/10] make QSV works with the Intel's oneVPL

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Jean-Baptiste Kempf
> Sent: Tuesday, October 19, 2021 11:19 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v6 00/10] make QSV works with the
> Intel's oneVPL
> 
> Hello,
> 
> On Fri, 15 Oct 2021, at 22:23, Soft Works wrote:
> > I really appreciate all the effort that Intel is taking to improve
> > ffmppeg for QSV hw acceleration, but in this case I'm not convinced
> > that this should be merged into ffmpeg at this time.
> >
> > [...]
> > In its current state, oneVPL is all about removal of features that
> > have existed for a long time.
> >
> > In its current state, it does not provide a single benefit over
> > libmfx 1.x
> 
> Indeed.
> But libmfx is not supported anymore by upstream, who's moving to
> oneVPL, aka mfx 2.0.
> 
> You can think this is a bad move from Intel to remove feature, but,
> de facto, they don't support libmfx anymore, the new features will
> come only on oneVPL and the new hardware will only be supported in
> oneVPL.

That's not exactly true. There might no new features be added
but it will still be supported because oneVPL doesn't replace it,
at least not the runtime.

Let's look at it in detail, there are 4 components involved:

1. Dispatchers

The dispatcher is what ffmpeg is interfacing with. It loads the
runtimes (there are GPU and sw runtimes) and forwards calls to 
the runtimes.


1.1. libmfx Dispatcher (Intel Media SDK)

This is the dispatcher that ffmpeg is currently using, latest
version is 1.35:

https://github.com/Intel-Media-SDK/MediaSDK/tree/master/api/mfx_dispatch

Many are also using this variant for ffmpeg compilation:
https://github.com/lu-zero/mfx_dispatch


1.2 oneVPL Dispatcher

This is the new oneVPL dispatcher which has those features 
removed and doesn't include any new ones:

https://github.com/oneapi-src/oneVPL/tree/master/dispatcher



2. Runtimes

The runtimes are containing the actual implementations, which 
are partially CPU gen specific and include a range of hardware
kernels/shaders that provide functionality that VAAPI doesn't
have.

The following table shows which hardware is supported by each
runtime and which runtimes are loaded by the dispatchers:

https://github.com/Intel-Media-SDK/MediaSDK#media-sdk-support-matrix

[I'm leaving out the CPU runtimes]


2.1. Media SDK Runtime (libmfxhw64)

This is what you get from building the MediaSDK repo. It supports 
all Intel hw up to Tiger Lake.

https://github.com/Intel-Media-SDK/MediaSDK#how-to-build


2.2. oneVPL Runtime (libmfx-gen)

The new oneVPL runtime supports only the very latest hardware and
needs to be built  from this repo:

https://github.com/oneapi-src/oneVPL-intel-gpu


THE CONSEQUENCES

If you want to ship the runtimes as part of an application and you
want to support all Intel hardware, you will always need to

    build and ship BOTH runtimes.

The only good thing is that both dispatchers can work with both
runtimes.

And that means in turn that the currently used dispatcher (libmfx
1.35) will be sufficient to work even with the latest hardware.
That means that there's no pressing reason to use the oneVPL 
dispatcher instead.

New features are promised for oneVPL but there don't exist any
yet. Even when those will be added, it will take a number of
years until they'll get really attractive to be used, because
Intel announced that these would only be available with the 
oneVPL runtime.

The only hardware for which the dispatchers are loading the 
oneVPL runtime instead of the MSDK runtime are Alder Lake CPUs.

From my point of view, it's of very low interest to use a
feature - no matter how great it might be - that is limited
to a single CPU gen.

Others might think different, that's why I only said that we 
should at least wait until any of those new features exists.

Factually there doesn't exist a single benefit or reason
to adopt oneVPL at this time.


Kind regards,
softworkz