Use DRM as a fallback if not on X11 for VAAPI #10922
Use DRM in VAAPI as a fallback if X11 is not present.
If we are not on the X11 windowing system lets fall back to using DRM for VAAPI. Which will use vaGetDisplayDRM using render nodes. This requires opening any device in /dev/dri/renderD.
Motivation and Context
This will allow hardware acceleration in other display servers that use DRM/EGL such as mir (and most likely wayland, untested).
How Has This Been Tested?
This has been tested on X11 and my Mir branch here: #10898 on ubuntu 16.10 (yakkety)
This change does require at lease a kernel >= 3.15.
Screenshots (if appropriate):
Types of change
I bring comparisons using 3840x2160p60 video:
Mir using no hardware accel:
Not 100% sure why mir's drop is 60 perfectly with the FPS. But the X11 version (when I didnt switch workspaces) was very good.
Seems to be hard to get good drop/skip numbers when you switch VTs or move workspaces. Though they seem very close in numbers besides X11 have a 0 drop when never moving a workspace (soo very good!) Mir I can seem to get ~20 drop but I have to switch VT to send the debug message not sure if thats causing extra drop doing that.
Some more testing running Big Buck Bunny 3840x2160p60 on both Mir and X11 with the same code from start 0:00 until 8:18 (about when the credits start). Kodi is compiled with player debug enabled so no extra WM stuff getting in the way.
Mir: drop 0 skip 3
If theres a better way to test this sort of thing let me know!
Hi Brandon, I would map the PlayerDebug to ctrl-o in a custom keyboard.xml, therefore create:
with the following content
Then just press ctrl-o from time to time. Keeping it on screen produces further load, so just check every some seconds / minutes.
The code is fine. I don't see a problem when comparing also our render part with: https://dvdhrm.wordpress.com/tag/drm/ . We succesfully use: EGL_LINUX_DMA_BUF_EXT to display it afterwards.
On thing that could be tested on MIR though is: Go to setting and disable Prefer VAAPI-Output - then a cpu intensive SSE4 copy is used that is based on vaDeriveImage and vaMapBuffer. It should just continue to work. If not - that's on the list to be dropped anyways.
Edit: This path will only be used for < 1080p input, as it does not scale performance wise for larger images. Don't forget to enable Prefer VAAPI-Output again after testing or performance will suck.
Either way it goes, I think its still a good idea to get a fallback for render nodes/DRM here. Mainly if the windowing system (ie. Mir in this case) doesnt support a direct GetVaDisplay. Mir requires some work to allow direct access to its buffers. So DRM will be far better then software rendering.
This will still pick X11 VaDisplay vs render nodes when on X11.
Let me know when you want me to squash the commits.
Nov 19, 2016
Nov 30, 2016
With this change, I'm getting a build failure:
It looks like "-lva-drm" is missing.
Though whats strange, it builds fine for me as well as here:
How did you compile this? I should be adding libva-drm to the FindVAAPI.cmake but just curious how I cant get it to fail nor does it fail when ran through travis.