Old package review is here: https://bugzilla.redhat.com/show_bug.cgi?id=770371

Some Debian attempt: https://github.com/sebastinas/intel-vaapi-driver/tree/2.2.0-remove-non-free-shaders

Here is the package review of the newer intel-media-driver: https://bugzilla.redhat.com/show_bug.cgi?id=1637139

Note that the Mesa VA-API drivers for AMD & Nvidia GPUs are included in the mesa-dri-drivers package.

Hmm, I can take a shot with intel-media-driver-free (that could be obsoleted by rpmfusions's full blown package).

Hmm, I can take a shot with intel-media-driver-free (that could be obsoleted by rpmfusions's full blown package).

Sounds good to me.

And intel-media-driver-free itself is the replacement for vaapi, yes?

Note that the Mesa VA-API drivers for AMD & Nvidia GPUs are included in the mesa-dri-drivers package.

[taps microphone] Is this thing on? ;)

Fedora Workstation has been shipping VA-API drivers (installed by default) for AMD GPUs for over six years, so I'm not sure why issues with Intel drivers should block this.

ACTION: Michael to talk to GStreamer and gstreamer-vaapi developers. Should we install gstreamer-vaapi by default?

Hmm, I can take a shot with intel-media-driver-free (that could be obsoleted by rpmfusions's full blown package).

Thanks for volunteering! ACTION: @frantisekz to investigate packaging intel-media-driver-free.

Note that we should install gstreamer1-vaapi. :wink:

ACTION: Michael to talk to GStreamer and gstreamer-vaapi developers. Should we install gstreamer-vaapi by default?

Summary of discussion: gstreamer-vaapi is headed towards obsolescence. It will soon be replaced by the new gstreamer-plugins-bad/sys/va hardware decoder. We already have it: it is not stripped from our gstreamer1-plugins-bad-free because it's under sys/ and our sanitizer script accepts all new things under sys/. Only new things under gst/ require approval apparently. However, it is still experimental and disabled by default at runtime, so gstreamer-vaapi is still the current solution.

I'm left with the impression that if we want hardware-accelerated playback today, we should use gstreamer-vaapi. However, I'm also told that gstreamer-vaapi is incompatible with clutter, so it does not work in totem, which is the only app we have installed by default that plays videos using GStreamer. So the main benefit here would be to users who install things that are not present by default (e.g. Epiphany). I'm left unconvinced whether it's worth installing this if it's soon going to be obsoleted by gstreamer-plugins-bad-free and if it's not going to work in totem anyway. I hear the gnome-shell screen recorder might want to depend on gstreamer-vaapi in the future, but if so the gnome-shell RPM should just add a Requires IMO.

Conclusion: undecided

but if so the gnome-shell RPM should just add a Requires IMO.

Or a Recommends, if appropriate, which would result in it getting pulled in by default just the same as a requires.

I've created a review request: https://bugzilla.redhat.com/show_bug.cgi?id=1942132 .

It should be built just with a free/open code according to media-writer documentation ( ENABLE_NONFREE_KERNELS=OFF ). It might be necessary to add BUILD_KERNELS=ON not to use anything prebuilt (I'll have to package a bunch of other stuff too in that case), we'll see how the review goes.

@kwizart Would it be feasible to add something like Provides/Obsoletes into full blown intel-media-driver on rpmfusion? I think people should then automatically get the package from rpmfusion once they add the repos, if I am not mistaken. Thanks!

@kwizart Would it be feasible to add something like Provides/Obsoletes into full blown intel-media-driver on rpmfusion?

Nope, this prevent our guideline to not replace any "distro base" package.
This is the end-user decision to switch to the rpmfusion-nonfree version or keep the fedora one for any reason. Also the namespace for having the intel-media-driver-free vs intel-media-driver to co-exists is not working (so it will clash on silverblue).

Please remind that this package was previously discarded from fedora because of patents (and non-free component pre-build in the source code).

Also the namespace for having the intel-media-driver-free vs intel-media-driver to co-exists is not working (so it will clash on silverblue).

What does this mean?

Please remind that this package was previously discarded from fedora because of patents (and non-free component pre-build in the source code).

The Working Group assumes any such issues will be addressed by stripping the source tarball of problematic code before the source tarball is uploaded.

Also the namespace for having the intel-media-driver-free vs intel-media-driver to co-exists is not working (so it will clash on silverblue).

What does this mean?

Hmmm, for now, I've added Conflicts with intel-media-driver, I guess I/we'll need to think about it a bit more.

Please remind that this package was previously discarded from fedora because of patents (and non-free component pre-build in the source code).

The Working Group assumes any such issues will be addressed by stripping the source tarball of problematic code before the source tarball is uploaded.

I didn't strip out anything just yet, I'll take a closer look tomorrow. I'll remove it from copr just to be sure for now.

So, I was finally able to move with this a bit forward. I am still not sure about a bunch of things:

• Can we ship some parts pre-built? If not, I'll go ahead and package a bunch of libraries to compile everything (igc, maybe something else)

• Somebody should probably take a look if I am removing everything problematic for inclusion in Fedora ( @ajax maybe? :) :) I've seen you've commented on some really old package reviews of intel vaapi drivers, it might even be impossible to include this at all (hopefully that's not a case, I am not sure))

I've put together a stripping script, it's available here: https://pagure.io/intel-media-driver-strip (PRs welcome!). Bunch of stuff in non_free_files list is commented out, the commented things are included only in non-free build, but: a) free build fails without them, b) it's mainly header files, without anything that looks like patented/non-free.

And finally:

SRPM: https://mojefedora.cz/intel-driver-review/intel-media-driver-free-21.1.3-1.fc33.src.rpm

SPEC: https://mojefedora.cz/intel-driver-review/intel-media-driver.spec

Can we ship some parts pre-built? If not, I'll go ahead and package a bunch of libraries to compile everything (igc, maybe something else)

We do need to be able to build everything from source.

Can we ship some parts pre-built? If not, I'll go ahead and package a bunch of libraries to compile everything (igc, maybe something else)

We do need to be able to build everything from source.

Mhm, I was wondering if this could go under the firmware binary umbrella (it's a kernel for video processor)?

Anyway, I've started poking the "build it entirely" path, but that will take some time (if it is going to be reasonably possible at all). For that, we need:

• intel-igc and intel-igc-opengl : those seem to be okay, available from https://copr.fedorainfracloud.org/coprs/jdanecki/intel-opencl (which would need some cleaning before packaging to Fedora)

• intel-igc-cm : this is not good, "Currently We test our opensource compiler on Centos-7.3 and Ubuntu-16.04." (https://github.com/intel/cm-compiler#linux-prerequisites), I've tried to grab some rpm from the github which they've built and build the driver kernels with that, just to end with sigsegv in the compiler. Also, "Probably last bugfix before external SDK" in the release notes doesn't sound too great.

I'll try to get in touch with Jacek Danecki from intel, who is maintaining the mentioned copr repository and ask about this (if he can point me where to report bugs, if (and when) Intel is going to start using something else than igc-cm,...).

EDIT: I didn't dig in too much, but VP firmware for AMD is part of linux-firmware. If I understand it right, these kernels seem to be the same thing.

No updates here for 4 months. What's the best path forward at this point?

Removing the pending-action tag, since it's unclear what the next action should be.

So, the situation is following:

• the spec I've prepared and linked above uses pre-compiled kernels distributed by Intel, with strip tool ( https://pagure.io/intel-media-driver-strip ) that removes all the patented stuff (I believe, IANAL)
• we need to rebuild the kernels (by adding BUILD_KERNELS=ON )

For rebuilding the kernels, there is a bunch of other stuff that needs to be packaged in Fedora:

• opencl-clang - https://github.com/intel/opencl-clang
• cm-compiler - https://github.com/intel/cm-compiler
• intel-graphics-compiler - https://github.com/intel/intel-graphics-compiler

The codebase of some of them is in rough state. The current roadblock is that the igc requires llvm == 10 ( https://github.com/intel/intel-graphics-compiler/issues/191 ) . There seem to be some way to get it working by patching and reverting some stuff mentioned in the ticket but it doesn't sound like a great and maintainable way forward. There is a lvvm compat package in Fedora, but the igc's build system doesn't seem particularly happy with it (cmake fails to find it).

The other issue would be cm-compiler, which should be pretty easy to get working as it doesn't exactly require any specific llvm version, but the codebase is not maintained much and build documentation is written for el-7.3.

If we really need to rebuild kernels, I'd say it's not a great idea to try to maintain the entire stack in its current form. It seems it'd be a bit fragile until Intel gets it sorted out to work on modern platforms and not require exact versions of some deps.

To post an update, I've recently had some time and made some progress (to see glass half full and not half empty...).

The prerequisites that had to be changed/added to be able to build the media-driver in Fedora are: spirv-llvm-translator, intel-opencl-clang, intel-igc (would be useful for Intel opencl driver packaging too) and intel-cm-compiler .

• spirv-llvm-translator: updated to match the llvm release used by the rest of the stack and Fedora ( https://src.fedoraproject.org/rpms/spirv-llvm-translator/pull-request/2 )
• intel-opencl-clang: Everything in place, pending package review request submit
• intel-igc: Everything in place, pending package review request submit
• intel-cm-compiler: Working on this, made some progress, slowly getting further, depends on llvm 8.0, doesn't have ton of documentation on "how to build this thing"

The current progress can be seen on https://copr.fedorainfracloud.org/coprs/frantisekz/intel-media-driver-free/ .

I've submitted review requests for everything that is needed to build the Intel vaapi driver from source:

• intel-opencl-clang: https://bugzilla.redhat.com/show_bug.cgi?id=2036098
• intel-igc: https://bugzilla.redhat.com/show_bug.cgi?id=2036099

• intel-compute-runtime (this also serves as OpenCl driver, [0]): https://bugzilla.redhat.com/show_bug.cgi?id=2036135

• llvm8.0: https://bugzilla.redhat.com/show_bug.cgi?id=2036104

• intel-llvm8.0-vc-intrinsics: https://bugzilla.redhat.com/show_bug.cgi?id=2036106
• spirv-llvm8.0-translator: https://bugzilla.redhat.com/show_bug.cgi?id=2036105
• intel-cm-compiler: https://bugzilla.redhat.com/show_bug.cgi?id=2036109

[0] OpenCl part currently broken due to https://github.com/intel/intel-graphics-compiler/issues/204 . Serves well enough for media-driver compilation however.

All the dependencies necessary are pre-built here: https://copr.fedorainfracloud.org/coprs/frantisekz/intel-media-driver-free/

The WIP src.rpm of the driver itself is available here: https://mojefedora.cz/intel-driver-review/intel-media-driver-free-22.1.0-1.fc36.src.rpm

I'll need to go through the source tree f the driver again and check/remove non-free bits that possibly got added since I've began working on it. Also, there is a bunch of duct-tape style patches for the driver that I probably should ask upstream about.

To sum it up, building that results in a working, free from patented stuff (hopefully, to be be reviewed by fedora-legal, IANAL), built from source vaapi driver that actually works (tested in vlc, firefox, chrome part is broken even in unmodified version since some 21.4.x release, previous releases worked well in chrome).

Also, after we get through the reviews, it'd be nice if somebody would help me with maintaining this collection of packages.

ACTION: Michael to talk to GStreamer and gstreamer-vaapi developers. Should we install gstreamer-vaapi by default?

Note: gstreamer-vaapi is deprecated by the va element in gst-plugins-bad. We should definitely not install gstreamer-vaapi.

To sum it up, building that results in a working, free from patented stuff (hopefully, to be be reviewed by fedora-legal, IANAL), built from source vaapi driver that actually works (tested in vlc, firefox, chrome part is broken even in unmodified version since some 21.4.x release, previous releases worked well in chrome).

Also, after we get through the reviews, it'd be nice if somebody would help me with maintaining this collection of packages.

It seems the reviewed packages are all present in Fedora now, right? What exactly does this allow? I understand we are not allowed to do hardware-accelerated decoding of H.264, but perhaps it allows hardware decoding of other stuff?

Any further steps required for this ticket (e.g. actually install stuff by default)?

It seems the reviewed packages are all present in Fedora now, right? What exactly does this allow? I understand we are not allowed to do hardware-accelerated decoding of H.264, but perhaps it allows hardware decoding of other stuff?

It allows accelerated decoding of VP8, VP9 and AV1 as supported by hardware, which means VP8 on Intel up to Tiger Lake, VP9 on AMD Ryzen APUs (Zen and later microarchitecture) and Intel Kaby Lake/Goldmont or newer and AV1 on AMD Ryzen 5000 APUs and RX 6000 GPUs and Intel Tiger Lake or newer.

Any further steps required for this ticket (e.g. actually install stuff by default)?

AMD APUs and GPUs are handled by radeonsi from mesa-dri-drivers already. libva-intel-driver for older Intel GPUs and intel-media-driver-free for newer ones should be installed by default to support all Intel GPUs.

So remaining action item here is to add these to comps, or ensure they get pulled in some other way.

Also, we are still waiting for intel-media-driver-free to be approved in https://bugzilla.redhat.com/show_bug.cgi?id=1942132

Updated review request for intel-media-driver-free: https://bugzilla.redhat.com/show_bug.cgi?id=1942132

Updated review request for intel-media-driver-free: https://bugzilla.redhat.com/show_bug.cgi?id=1942132

Yeah, I've internally pinged one of my legal contacts, so it will hopefully move forward a bit faster. If anybody with fc37 (here it also pulls in newer gmmlib)/fc38 wants to give it a try, you can use my package review copr: https://copr.fedorainfracloud.org/coprs/frantisekz/intel-media-driver-free/

@kwizart are you planning to bump gmmlib also in f37? Can I help you with it somehow? I've already verified it doesn't break the OpenCl stack. Due to upstream refactoring that took place in 26.6 branch, I can't easily use older media-driver release with everything that's needed in-place.

Any further updates here?

Waiting for a response to my latest ask in the BZ.

Package is in rawhide, I'll try to get it to f39 too (see https://bugzilla.redhat.com/show_bug.cgi?id=1942132#c66 for explanation).

Do we want this present in the default Workstation package set? And in spins?

Do we want this present in the default Workstation package set?

Yes!

And in spins?

Probably, but that's not up to Workstation WG.

It should be added to the general multimedia comps group, which should take care of it for everyone.

It should be added to the general multimedia comps group, which should take care of it for everyone.

https://pagure.io/fedora-comps/pull-request/923

OK, I see the comps change has been merged. I suppose the only step remaining is to test a fresh install and verify that it works?

Yes, once a compose has run and an image is available here: https://koji.fedoraproject.org/koji/packageinfo?packageID=22087

I see the only remaining task here is to verify that this is implemented and working. Any volunteers with Intel hardware willing to test an install of F40 Workstation and verify that the accelerated video decoding works out-of-the-box?

I see the only remaining task here is to verify that this is implemented and working. Any volunteers with Intel hardware willing to test an install of F40 Workstation and verify that the accelerated video decoding works out-of-the-box?

Worst case I'll give it a try Tuesday on a testing laptop (works fine for manually installed build on f39).

Firefox works out of the box, chrome needs the following (maybe not all of them anymore):

google-chrome-stable --enable-gpu-rasterization --ignore-gpu-blocklist --disable-gpu-driver-bug-workarounds --enable-features=VaapiVideoDecoder,VaapiVideoEncoder,UseOzonePlatform,Vulkan,DefaultANGLEVulkan,VulkanFromANGLE,UseChromeOSDirectVideoDecoder --enable-zero-copy

And you can verify it with (check the Video column):

sudo intel_gpu_top

This needs to be backported to get VA-API to work by default: https://chromium-review.googlesource.com/c/chromium/src/+/3646633

Well, Chromium isn't installed by default anyway. Let's just verify that it works in Firefox and totem.

Actually, it won't work in totem until GStreamer 1.24 (because the va element is "downranked" prior to 1.24) so we only need to check Firefox.

This is Rawhide Workstation built on 20240201, vaapi works out of the box. The only caveat is AV1, I'd tested it on the GPU that supports it, vainfo reports it as supported, but it's not accelerated in Firefox.

I can dig in more next week, @stransky , should that work?

Thanks for testing. I'm going to close as FIXED. Of course it would be wonderful to have AV1 working in Firefox too, but for the purposes of this issue, having intel-media-sdk generally working is excellent. Nice!