Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use DRM as a fallback if not on X11 for VAAPI #10922

Merged
merged 1 commit into from Nov 30, 2016

Conversation

@BrandonSchaefer
Copy link

commented Nov 12, 2016

Use DRM in VAAPI as a fallback if X11 is not present.

Description

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):

http://i.imgur.com/OGtB2W7.jpg (x11)

Types of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the Code guidelines of this project
  • My change requires a change to the documentation, either Doxygen or wiki
  • I have updated the documentation accordingly
  • I have read the CONTRIBUTING document
  • I have added tests to cover my change
  • All new and existing tests passed
@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Nov 12, 2016

im pretty sure this would be consider a breaking change since (marked as such) ... ideally nothing changes but now the VAAPI will be using DRM soo there could be some unforeseen edge cases ive yet to hit in test.

@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Nov 13, 2016

I bring comparisons using 3840x2160p60 video:

So for mir on its KMS platform fullscreen:
http://imgur.com/a/NhZX3
(second take) http://i.imgur.com/ONJXkMy.jpg

Mir using no hardware accel:
http://imgur.com/a/drkIg (thats bad)

X11 same DRM VAAPI code:
http://imgur.com/a/YXJPl
(Much better version): http://i.imgur.com/V1tZZ60.jpg

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.

@BrandonSchaefer BrandonSchaefer referenced this pull request Nov 13, 2016

Merged

Mir windowing system for Kodi #10898

4 of 9 tasks complete
@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Nov 13, 2016

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.

@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Nov 13, 2016

Ok, so turning on debug by default for Mir finally solves the dropping (since i needed to switch a vt to send the PlayerDebug event)

http://i.imgur.com/HkIpbg2.jpg

Drop: 0 Skip: 0... yay!

@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Nov 13, 2016

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
X11: drop 0 skip 101

If theres a better way to test this sort of thing let me know!

@fritsch

This comment has been minimized.

Copy link
Member

commented Nov 13, 2016

Hi Brandon, I would map the PlayerDebug to ctrl-o in a custom keyboard.xml, therefore create: ~/.kodi/userdata/keymaps/debug.xml

with the following content

<keymap>
  <fullscreenvideo>
    <keyboard>
      <o mod="ctrl">PlayerDebug</o>
    </keyboard>
  </fullscreenvideo>
</keymap>

Then just press ctrl-o from time to time. Keeping it on screen produces further load, so just check every some seconds / minutes.

@fritsch

This comment has been minimized.

Copy link
Member

commented Nov 13, 2016

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.

@@ -123,14 +128,44 @@ bool CVAAPIContext::EnsureContext(CVAAPIContext **ctx, CDecoder *decoder)
return true;
}

namespace
{
int find_open_render_node_fd()

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 13, 2016

Member

I think this is fine as a fallback when running headless (future case), but with UI we should not bypass vaapi api for getting the display handle. Consider the case with multiple cards and monitors connected.

https://cgit.freedesktop.org/libva/tree/va
^^ there should be code to get vaDisplay for MIR. Would you know if anybody intents to write and submit this code?

btw: we prefer camel case for function names.

This comment has been minimized.

Copy link
@fritsch

fritsch Nov 13, 2016

Member

In fact, that's not bypassing VAAPI-API, see the original commit done by Gwenole: http://libva.freedesktop.narkive.com/d5UZ8R3b/patch-0-2-add-support-for-drm-render-nodes

In kodi case I see it that the only thing that should have anything to do with a running Xserver is the display part. Decoding + Rendering should use the future API which is DRM + EGL.

I don't see the point depending a decoder on a display server when it is not needed.

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 13, 2016

Member

I don't see the point depending a decoder on a display server when it is not needed.

makes no sense using the gpu one one gfx card when you have the display on the other one. vaapi provides the API for getting the display on the various systems and this has to be used.

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 13, 2016

Member

further have fun creating an EGL context for interop with info from windowing. that means there is already direct link between decoder and windowing that cannot be removed.

This comment has been minimized.

Copy link
@fritsch

fritsch Nov 13, 2016

Member

Which is no reason to depend the decoder on a specific display API (like X11, etc.). As you see from the patches in the other PR, it will solely depend on EGL as a standard. If your X11 supports it, your MIR, your wayland whatever - you easily get exactly that egl display, which is totally DisplayServer unaware and just speaks the EGL API.

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 14, 2016

Member

We don't use vaPutSurface

This comment has been minimized.

Copy link
@RAOF

RAOF Nov 14, 2016

So, since presentation is (mostly) unimportant, the most sensible approach would be to initialise VA on all available rendernodes and then pick the one with the best format support?

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 14, 2016

Member

Who said that presentation would be unimportant? Kodi maps OpenGL textures to vaSurfaces (zero-copy). Please elaborate how this works when having decoding on one gpu and the GL context on the other.

This comment has been minimized.

Copy link
@RAOF

RAOF Nov 14, 2016

As far as I can tell from VAAPI.cpp, Kodi uses eglCreateImageKHR with the EGL_EXT_image_dma_buf_import extension to import the buffers identified by the dma-buf fds as textures. Those dma-buf fds are cross-GPU handles.

The dma-buf fds you get from the vaSurfaces will be references to memory on the decoder-GPU; if the GL context is not on the same GPU, then eglCreateImageKHR will implicitly perform a GPU→GPU migration.

This means that decoding on one GPU and presenting on a different GPU is not zero-copy, but the copy is hidden in the driver and will generally be performed by a hardware DMA engine. As this is only happening at most 3 times per frame, it shouldn't be a particularly noticeable performance impact.

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 15, 2016

Member

I wrote this code in order to get zero-copy and I certainly won't break this strategy for something I don't see any benefit in. Introducing a hidden any highly brittle copy operation done by the driver does not make any sense to me.

As this is only happening at most 3 times per frame, it shouldn't be a particularly noticeable performance impact

I seriously doubt. Why don't you try with a 4k @ 60 fps movie and post the numbers.

@BrandonSchaefer BrandonSchaefer changed the title * Move VAAPI to use DRM vs directly using X11 Use DRM as a fallback if not on X11 for VAAPI Nov 13, 2016

@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Nov 18, 2016

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.

bool CVAAPIContext::CreateContext()
namespace
{
VADisplay FindValidDRMVaDisplayFromRenderNode()

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 19, 2016

Member

no globals please. make this a method of context

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

Its in an unnamed namespace, so it'll have internal linkage. It also doesnt depend on anything in the class it self (soo I tend to like pure functions :). But fine with me, changing!

VADisplay m_display;
int m_refCount;
int m_attributeCount;
VADisplayAttribute *m_attributes;
int m_profileCount;
VAProfile *m_profiles;
std::vector<CDecoder*> m_decoders;
int m_fd{-1};

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 19, 2016

Member

something more meaningful then fd would be great.

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

O yeah thats a bad name right now.

{
{ CSingleLock lock(g_graphicsContext);
if (!m_X11dpy)
m_X11dpy = XOpenDisplay(NULL);

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 19, 2016

Member

keep the separate display connection

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

I removed this, because it wasnt referenced anywhere, but I can put it back (not sure if there were plans for it later). Ill add back!

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

O sorry, was thinking of something else, you're right!

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 19, 2016

Member

It is referenced in current code:

  { CSingleLock lock(g_graphicsContext);
    if (!m_X11dpy)
      m_X11dpy = XOpenDisplay(NULL);
  }

  m_display = vaGetDisplay(m_X11dpy);
#if HAVE_X11
Display *x11_display{nullptr};
{ CSingleLock lock(g_graphicsContext);
x11_display = XOpenDisplay(nullptr);

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 19, 2016

Member

this opens a display connection every time we start some video. this is not what we want here. we want to
open it once for the lifetime of the application.

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

Right that makes more sense now, fixing!

}
}

CLog::Log(LOGERROR, "FAILED To find any open render nodes in /dev/dri/renderD<num>\n");

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 19, 2016

Member

there is no need for new line character when using Kodi's log

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

Good to know, fixing

VADisplay m_display;
int m_refCount;
int m_attributeCount;
VADisplayAttribute *m_attributes;
int m_profileCount;
VAProfile *m_profiles;
std::vector<CDecoder*> m_decoders;
int m_render_node_fd{-1};

This comment has been minimized.

Copy link
@FernetMenta

FernetMenta Nov 19, 2016

Member

chamelCasePlease :)

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

Shoot, sorry, so use to the other way

@BrandonSchaefer BrandonSchaefer force-pushed the BrandonSchaefer:vaapi-drop-x11 branch from 6d11522 to 1255570 Nov 19, 2016

@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Nov 19, 2016

Opps has to be a static fixing...

@BrandonSchaefer BrandonSchaefer force-pushed the BrandonSchaefer:vaapi-drop-x11 branch from 1255570 to f410ffb Nov 19, 2016

@FernetMenta

This comment has been minimized.

Copy link
Member

commented Nov 19, 2016

looks good now, thanks very much!

}
}

CLog::Log(LOGERROR, "FAILED To find any open render nodes in /dev/dri/renderD<num>");

This comment has been minimized.

Copy link
@hudokkow

hudokkow Nov 19, 2016

Member

Failed to find any...

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

Yeah that does look better


if (m_display == nullptr)
{
CLog::Log(LOGERROR, "FAILED To find any a VaDisplay for this system\n");

This comment has been minimized.

Copy link
@hudokkow

hudokkow Nov 19, 2016

Member

Failed to find a VaDisplay...

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

Opps and forgot about the \n ... annd fixing

This comment has been minimized.

Copy link
@hudokkow

hudokkow Nov 19, 2016

Member

Sorry for nitpicking. It's either "any VaDisplay" or "a VaDisplay". But English is not my native language...

This comment has been minimized.

Copy link
@BrandonSchaefer

BrandonSchaefer Nov 19, 2016

Author

Yeah you're right, english is my native language and im not super good at it :)

@BrandonSchaefer BrandonSchaefer force-pushed the BrandonSchaefer:vaapi-drop-x11 branch from f410ffb to 53a06da Nov 19, 2016

@BrandonSchaefer BrandonSchaefer force-pushed the BrandonSchaefer:vaapi-drop-x11 branch from 53a06da to 97e0668 Nov 19, 2016

@FernetMenta

This comment has been minimized.

Copy link
Member

commented Nov 30, 2016

jenkins build this please

@FernetMenta FernetMenta merged commit 19a13a8 into xbmc:master Nov 30, 2016

2 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
jenkins4kodi You did a great job. Have a cookie.
Details

@hudokkow hudokkow added this to the L 18.0-alpha1 milestone Nov 30, 2016

@hudokkow hudokkow added the v18 Leia label Nov 30, 2016

@candrews

This comment has been minimized.

Copy link
Contributor

commented Nov 30, 2016

With this change, I'm getting a build failure:

make[1]: Leaving directory '/var/tmp/portage/media-tv/kodi-9999/work/kodi-9999/xbmc/cores/VideoPlayer/DVDSubtitles'
x86_64-pc-linux-gnu-g++ -DNDEBUG=1 -O2 -march=native -pipe -fomit-frame-pointer -fno-lto -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG=1 -O2 -march=native -pipe -fomit-frame-pointer -fno-lto -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-O1 -Wl,--as-needed -flto -fno-lto -Wl,-O1 -Wl,--as-needed -flto -fno-lto -o kodi.bin xbmc/platform/posix/posix.a -Wl,--start-group xbmc/platform/posix/posix.a xbmc/linux/linux.a xbmc/network/network.a xbmc/video/windows/videowindows.a xbmc/utils/utils.a xbmc/cores/DllLoader/exports/util/exports_utils.a xbmc/cores/DllLoader/exports/exports.a xbmc/settings/settings.a xbmc/video/video.a xbmc/pvr/addons/pvraddons.a xbmc/pvr/windows/pvrwindows.a xbmc/guilib/guilib.a  xbmc/cores/VideoPlayer/VideoPlayer.a xbmc/cores/VideoPlayer/DVDCodecs/DVDCodecs.a xbmc/cores/VideoPlayer/DVDCodecs/Audio/Audio.a xbmc/cores/VideoPlayer/DVDCodecs/Overlay/Overlay.a xbmc/cores/VideoPlayer/DVDCodecs/Video/Video.a xbmc/cores/VideoPlayer/DVDDemuxers/DVDDemuxers.a xbmc/cores/VideoPlayer/DVDInputStreams/DVDInputStreams.a xbmc/cores/VideoPlayer/DVDSubtitles/DVDSubtitles.a xbmc/cores/VideoPlayer/Process/Process.a xbmc/addons/addons.a xbmc/addons/binary/interfaces/addon-interfaces.a xbmc/addons/binary/interfaces/api1/Addon/addon-callbacks-addon.a xbmc/addons/binary/interfaces/api1/AudioDSP/addon-callbacks-audiodsp.a xbmc/addons/binary/interfaces/api1/AudioEngine/addon-callbacks-audioengine.a xbmc/addons/binary/interfaces/api1/Codec/addon-callbacks-codec.a xbmc/addons/binary/interfaces/api1/GUI/addon-callbacks-gui.a xbmc/addons/binary/interfaces/api1/InputStream/addon-callbacks-inputstream.a xbmc/addons/binary/interfaces/api1/Peripheral/addon-callbacks-peripheral.a xbmc/addons/binary/interfaces/api1/PVR/addon-callbacks-pvr.a xbmc/contrib/kissfft/kissfft.a xbmc/cores/AudioEngine/audioengine.a xbmc/cores/DllLoader/dllloader.a xbmc/cores/ExternalPlayer/ExternalPlayer.a xbmc/cores/VideoPlayer/VideoRenderers/VideoRenderer.a xbmc/cores/VideoPlayer/VideoRenderers/VideoShaders/VideoShaders.a xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/HwDecRender.a xbmc/cores/cores.a xbmc/cores/paplayer/paplayer.a xbmc/cores/playercorefactory/playercorefactory.a xbmc/dbwrappers/dbwrappers.a xbmc/dialogs/dialogs.a xbmc/epg/epg.a xbmc/events/events.a xbmc/filesystem/MusicDatabaseDirectory/musicdatabasedirectory.a xbmc/filesystem/VideoDatabaseDirectory/videodatabasedirectory.a xbmc/filesystem/filesystem.a xbmc/games/controllers/controllers.a xbmc/games/controllers/dialogs/controllerdialogs.a xbmc/games/controllers/guicontrols/controllerguicontrols.a xbmc/games/controllers/windows/controllerwindows.a xbmc/input/input.a xbmc/interfaces/builtins/builtins.a xbmc/interfaces/generic/interfaces-generic.a xbmc/interfaces/info/info.a xbmc/interfaces/interfaces.a xbmc/interfaces/json-rpc/json-rpc.a xbmc/interfaces/legacy/legacy.a xbmc/interfaces/python/python_binding.a xbmc/listproviders/listproviders.a xbmc/platform/platform.a xbmc/media/media.a xbmc/messaging/messaging.a xbmc/messaging/helpers/messagingHelpers.a xbmc/music/dialogs/musicdialogs.a xbmc/music/infoscanner/musicscanner.a xbmc/music/music.a xbmc/music/tags/musictags.a xbmc/music/windows/musicwindows.a xbmc/network/dacp/dacp.a xbmc/network/websocket/websocket.a xbmc/peripherals/addons/peripheral-addons.a xbmc/peripherals/bus/peripheral-bus.a xbmc/peripherals/devices/peripheral-devices.a xbmc/peripherals/dialogs/peripheral-dialogs.a xbmc/peripherals/peripherals.a xbmc/pictures/pictures.a xbmc/playlists/playlists.a xbmc/powermanagement/powermanagement.a xbmc/profiles/profiles.a xbmc/profiles/dialogs/profiles_dialogs.a xbmc/profiles/windows/profiles_windows.a xbmc/programs/programs.a xbmc/pvr/channels/pvrchannels.a xbmc/pvr/dialogs/pvrdialogs.a xbmc/pvr/pvr.a xbmc/pvr/recordings/pvrrecordings.a xbmc/pvr/timers/pvrtimers.a xbmc/rendering/rendering.a xbmc/settings/dialogs/settings_dialogs.a xbmc/settings/lib/settings_lib.a xbmc/settings/windows/settings_windows.a xbmc/storage/storage.a xbmc/video/dialogs/videodialogs.a xbmc/video/jobs/video-jobs.a xbmc/video/videosync/videosync.a xbmc/view/view.a xbmc/windowing/windowing.a xbmc/windows/windows.a xbmc/xbmc.a xbmc/cdrip/cdrip.a xbmc/interfaces/legacy/wsgi/legacy-wsgi.a xbmc/network/httprequesthandler/httprequesthandlers.a xbmc/network/httprequesthandler/python/httprequesthandlers-python.a xbmc/rendering/gl/rendering_gl.a lib/libUPnP/libupnp.a xbmc/network/upnp/upnp.a xbmc/input/joysticks/input_joysticks.a xbmc/input/joysticks/dialogs/input_joystick_dialogs.a xbmc/input/joysticks/generic/input_joysticks_generic.a xbmc/input/linux/input_linux.a xbmc/input/touch/input_touch.a xbmc/input/touch/generic/input_touch_generic.a xbmc/network/linux/network_linux.a xbmc/powermanagement/linux/powermanagement_linux.a xbmc/storage/linux/storage_linux.a xbmc/windowing/X11/windowing_X11.a lib/UnrarXLib/UnrarXLib.a -Wl,--end-group xbmc/threads/threads.a xbmc/commons/commons.a -lavahi-client -lavahi-common -lmicrohttpd -lresolv -ltinyxml -lssl -lcrypto -lz -llzo2 -lpthread -lbz2 -lgcrypt -lgpg-error -lGLU -lGL  -L/usr/lib64 -lpython2.7 -lssl -lcrypto -Wl,-O1 -Wl,--as-needed -flto -fno-lto -lcrossguid -luuid -lyajl -lxml2 -lxslt -lxml2 -lz -llzma -licui18n -licuuc -licudata -lm -ldl -lm -lxml2 -lfribidi -lglib-2.0 -lsqlite3 -lpcrecpp -lpcre -lfreetype -ltag -lcdio -lm -lasound -ldbus-1 -lasound -lpulse -lX11 -lXext -lXrandr -ldrm -lEGL -lssh -lsmbclient -ludev -llcms2 -lbluetooth -lcap -lavcodec -lavfilter -lavformat -lavutil -lpostproc -lswscale -lswresample -lva-x11 -lva -rdynamic
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: xbmc/cores/VideoPlayer/DVDCodecs/Video/Video.a(VAAPI.o): undefined reference to symbol 'vaGetDisplayDRM'
/usr/lib64/libva-drm.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [Makefile:449: kodi.bin] Error 1

It looks like "-lva-drm" is missing.

@FernetMenta

This comment has been minimized.

Copy link
Member

commented Dec 1, 2016

yes, seems jenkins does not build vaapi then

@FernetMenta

This comment has been minimized.

Copy link
Member

commented Dec 2, 2016

@BrandonSchaefer could you submit a fix for this?

@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Dec 2, 2016

Opps yeah I didnt add finding libva-drm to the FindVaapi.cmake. Ill get something up tomorrow (a bit late for me)

@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Dec 2, 2016

Though whats strange, it builds fine for me as well as here:
https://api.travis-ci.org/jobs/177342760/log.txt?deansi=true

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.

@candrews

This comment has been minimized.

Copy link
Contributor

commented Dec 2, 2016

I'm using auto tools/make, not cmake, not sure if that matters.

@BrandonSchaefer

This comment has been minimized.

Copy link
Author

commented Dec 2, 2016

Autotools are planned to be removed soon, annnd I didnt test it out there :). You can try cmake in kodi/project/cmake which looks to be working.

#10429

@FernetMenta

This comment has been minimized.

Copy link
Member

commented Dec 2, 2016

I'm using auto tools/make, not cmake, not sure if that matters.

if you are using autotools, you are on your own.

if it builds with cmake, all fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.