There had been a prior attempt to enable VA-API support in Mesa (back in Feb 2015), but it was reverted due to a build dependency cycle. The cycle was caused by: libva -> Mesa-libEGL-devel, Mesa-libGL-devel Mesa-libva -> libva-devel I decided to follow the format of libvdpau-va and libvdpau-va-gl packages. Their source seems to be broken up so it was probably natural to break the package up like that. For libva I split off a linked package called libva-gl. - libva: builds everything except gl related - libva-gl: builds libva-egl1 and libva-glx1 This changes the dependency cycle to the following libva -> [nothing mesa related] libva-gl -> Mesa-libEGL-devel, Mesa-libGL-devel Mesa-libva -> libva-devel As you can see this solves the cycle issue. The remaining concern I have is that the Mesa libva driver only generates one file: /usr/lib64/dri/gallium_drv_video.so. When utilizing (for example with vainfo) one needs to specify LIBVA_DRIVER_NAME. LIBVA_DRIVER_NAME=gallium vainfo On intel cards the libva support is provided by a separate (already existing package) instead of through gallium. The driver file it provides is named appropriately that it should just be picked up. Having to set the environment variable seems sub-optimal and is even documented on arch wiki (https://wiki.archlinux.org/index.php/VA-API). Instead providing symbolic links for each of the drivers seems to properly fit the paradigm used by vdpau and base drivers. For example creating the following works on my radeon setup. radeonsi_drv_video.so -> gallium_drv_video.so Setting the environment variable is troublesome: 1) where to set it 2) would need to test for other drivers installed (like intel) Instead it seems like the symbolic links are the way to go. If agreed they could either be added directly in .spec %install, or patched to make install (and perhaps upstreamed). Which seems like the most appropriate solution? I'll hop in #dri-devel and perhaps mesa-dev list and get their thoughts. Finally, I spent many hours searching around the interwebz to figure out the history and state of chromium video acceleration via VA-API. - vdpau is not supported and issues about it have not gone anywhere - va-api works on chromeos so the code is there - support was temporarily enable by intel commit, but quickly reverted There is a out-of-tree patch to change the build flags to look for LINUX instead of CHROMEOS and a tweak to remove the hard coded paths and allow for libva discovery. I managed to get the patch to apply after forward porting it and branching my patched package to build chromium-ffmpeg patch on packman build service (pmbs). Once all the components were installed locally I was able to start chromium and confirm it worked by playing a 4k video on youtube. The 4k video has the most noticable cpu usage and it was clear it dropped significantly. I also used gallium hud to verify increase gpu usage. The end result was the video played the same as if downloaded (via youtube-dl) and played locally in vlc!! Some notes: - installed h264ify chrome extension to force html5 video to use h264 codec instead of h265 or vp9 which are not supported by VA-API yet - previously flipped two flags in chrome while testing a while back - Override software rendering list - Enable GPU rasterization -> enabled I can not set LIBVA_DRIVER_NAME and chromium reverts back to extra cpu usage (also comepare with google-chrome which doesn't have va-api). I need to verify if the patch makes that redundant (I believe it does). Otherwise, it would be good to add that to the patch or change the default values shipped in openSUSE chromium package. My plan going forward then was to add recommends Mesa-libva to chromium along with the patch and submit an SR once the rest of the dust settles. For those interested in following along (SR requests pending). libva - https://build.opensuse.org/request/show/349285 - https://build.opensuse.org/request/show/349402 libva-gl (new) - https://build.opensuse.org/request/show/349403 Mesa - https://build.opensuse.org/request/show/349404 I will followup with the chromium SR assuming these make it in. With luck all this will be accepted/worked out over the next few days. Enjoy! -- Jimmy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org