> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Jean-Baptiste Kempf > Sent: Tuesday, October 19, 2021 11:19 PM > To: ffmpeg-devel@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
