[opensuse-factory] VA-API support in Mesa and chromium video acceleration
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
Great work, Thanks, On 17 December 2015 at 16:24, Jimmy Berry <jimmy@boombatower.com> wrote:
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
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 17.12.2015 20:24, Jimmy Berry wrote:
There had been a prior attempt to enable VA-API support in Mesa (back in Feb 2015), ...
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
... 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
Great work ! But shouldn't libva-gl package be a branch of libva with shared source and 2 spec-files as it's usually done on OBS ? That way they are easier to maintain and are automatically simultaneously branched into other repoes.
On Fri, Dec 18, 2015 at 10:17 AM, Sergey Kondakov <virtuousfox@gmail.com> wrote:
On 17.12.2015 20:24, Jimmy Berry wrote:
There had been a prior attempt to enable VA-API support in Mesa (back in Feb 2015), ...
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
... 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
Great work ! But shouldn't libva-gl package be a branch of libva with shared source and 2 spec-files as it's usually done on OBS ? That way they are easier to maintain and are automatically simultaneously branched into other repoes.
Yes, as I had already commented on the SR it should be a link. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
SRs for the following were all accepted: - libva - libva-gl (needs link created) - Mesa-libva Confirmed patches remove the need to change flags in chromium to utilize the VA-API support. Confirmed upstream approach for hardlinking driver instances to gallium_drv_video.so in #dri-devel and sent patch and SR. - http://lists.freedesktop.org/archives/mesa-dev/2015-December/103585.html - https://build.opensuse.org/request/show/349699 Cleaned up chromium patch and placed behind %bcond. Synced pbms package for testing (issues building on pmbs due pre-existing issue of missing _constraints file, I sent email to packman list). - https://build.opensuse.org/request/show/349702 Should probably add a wiki comment/page about using h264ify extension to gain the most from this patch. Not sure if it should/can be enabled in package. Otherwise, everything should work out of the box for folks using r600 or radeonsi once everything hits tumbleweed. -- Jimmy On Fri, Dec 18, 2015 at 2:58 PM, Jimmy Berry <jimmy@boombatower.com> wrote:
On Fri, Dec 18, 2015 at 10:17 AM, Sergey Kondakov <virtuousfox@gmail.com> wrote:
On 17.12.2015 20:24, Jimmy Berry wrote:
There had been a prior attempt to enable VA-API support in Mesa (back in Feb 2015), ...
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
... 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
Great work ! But shouldn't libva-gl package be a branch of libva with shared source and 2 spec-files as it's usually done on OBS ? That way they are easier to maintain and are automatically simultaneously branched into other repoes.
Yes, as I had already commented on the SR it should be a link. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Nvidia support can be added by installing libva-vdpau-driver. Perhaps I should add it as a recommends on chromium-ffmpeg as well. One can also use/force via: LIBVA_DRIVER_NAME=vdpau
From my reading there seems to be a slight difference in performance between the two, but either work well.
-- Jimmy On Sat, Dec 19, 2015 at 11:57 PM, Jimmy Berry <jimmy@boombatower.com> wrote:
SRs for the following were all accepted:
- libva - libva-gl (needs link created) - Mesa-libva
Confirmed patches remove the need to change flags in chromium to utilize the VA-API support.
Confirmed upstream approach for hardlinking driver instances to gallium_drv_video.so in #dri-devel and sent patch and SR. - http://lists.freedesktop.org/archives/mesa-dev/2015-December/103585.html - https://build.opensuse.org/request/show/349699
Cleaned up chromium patch and placed behind %bcond. Synced pbms package for testing (issues building on pmbs due pre-existing issue of missing _constraints file, I sent email to packman list). - https://build.opensuse.org/request/show/349702
Should probably add a wiki comment/page about using h264ify extension to gain the most from this patch. Not sure if it should/can be enabled in package.
Otherwise, everything should work out of the box for folks using r600 or radeonsi once everything hits tumbleweed.
-- Jimmy
On Fri, Dec 18, 2015 at 2:58 PM, Jimmy Berry <jimmy@boombatower.com> wrote:
On Fri, Dec 18, 2015 at 10:17 AM, Sergey Kondakov <virtuousfox@gmail.com> wrote:
On 17.12.2015 20:24, Jimmy Berry wrote:
There had been a prior attempt to enable VA-API support in Mesa (back in Feb 2015), ...
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
... 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
Great work ! But shouldn't libva-gl package be a branch of libva with shared source and 2 spec-files as it's usually done on OBS ? That way they are easier to maintain and are automatically simultaneously branched into other repoes.
Yes, as I had already commented on the SR it should be a link. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I am rather happy as I solved everything I set out to and everyone should be able to use in TW. The recommends on chromium package worked so the relevant packages were automatically installed when I updated to 20160107. Please note that the full ffmpeg package is needed so the VA-API support is only installed and utilized when using chromium-ffmpeg package from Packman. I also patch Mesa to create hardlinks for supported drivers so the environment variable is not needed (this is applied to openSUSE Mesa). - http://lists.freedesktop.org/archives/mesa-dev/2015-December/103585.html My understanding at this point is openSUSE is the only distro with all this setup, much less working without tweaks (like env var). :) I need to reroll the patch as the latest chromium made a view va-api changes that need to be accounted for so it may be temporarily disabled (others can feel free to do so before I get to it). Enjoy, and thanks to those who helped with reviews and tweaks to get into Factory! -- Jimmy On Sun, Dec 20, 2015 at 12:42 AM, Jimmy Berry <jimmy@boombatower.com> wrote:
Nvidia support can be added by installing libva-vdpau-driver. Perhaps I should add it as a recommends on chromium-ffmpeg as well.
One can also use/force via: LIBVA_DRIVER_NAME=vdpau
From my reading there seems to be a slight difference in performance between the two, but either work well.
-- Jimmy
On Sat, Dec 19, 2015 at 11:57 PM, Jimmy Berry <jimmy@boombatower.com> wrote:
SRs for the following were all accepted:
- libva - libva-gl (needs link created) - Mesa-libva
Confirmed patches remove the need to change flags in chromium to utilize the VA-API support.
Confirmed upstream approach for hardlinking driver instances to gallium_drv_video.so in #dri-devel and sent patch and SR. - http://lists.freedesktop.org/archives/mesa-dev/2015-December/103585.html - https://build.opensuse.org/request/show/349699
Cleaned up chromium patch and placed behind %bcond. Synced pbms package for testing (issues building on pmbs due pre-existing issue of missing _constraints file, I sent email to packman list). - https://build.opensuse.org/request/show/349702
Should probably add a wiki comment/page about using h264ify extension to gain the most from this patch. Not sure if it should/can be enabled in package.
Otherwise, everything should work out of the box for folks using r600 or radeonsi once everything hits tumbleweed.
-- Jimmy
On Fri, Dec 18, 2015 at 2:58 PM, Jimmy Berry <jimmy@boombatower.com> wrote:
On Fri, Dec 18, 2015 at 10:17 AM, Sergey Kondakov <virtuousfox@gmail.com> wrote:
On 17.12.2015 20:24, Jimmy Berry wrote:
There had been a prior attempt to enable VA-API support in Mesa (back in Feb 2015), ...
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
... 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
Great work ! But shouldn't libva-gl package be a branch of libva with shared source and 2 spec-files as it's usually done on OBS ? That way they are easier to maintain and are automatically simultaneously branched into other repoes.
Yes, as I had already commented on the SR it should be a link. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Jimmy Berry -
Ondřej Súkup -
Sergey Kondakov