Hi Thorsten,

Can you please provide some more detailed reproduction instructions, what harware are you using, do you have any special related packages installed (like libva providers from rpmfusion for example), what is the use-case which made you first notice this ?

Once I've some more info I will try to reproduce and then try to fix this :)

Regards,

Hans

Also worth to test if it still work as appropriate when using:
export LIBVA_DRIVER_NAME=i965

(to be tested "with" the libglvnd update).

(In reply to Hans de Goede from comment #1)
> Can you please provide some more detailed reproduction instructions,

Simply running vainfo afaics is enough to verify it's not working, but yes, ...

> do you have any special related packages installed
> (like libva providers from rpmfusion for example),

...obviously you need to have libva-intel-driver installed from RPM Fusion; sorry, should have mentioned this initially.

> what hardware are you using, 

Dell XPS 13 (9360) at home (Kaby Lake CPU and it's GPU). 

> what is the use-case which made you first notice this ?

I noticed that video acceleration wasn't working in VLC due to higher CPU load (fan was working more often), the battery draining more quickly and stuttering when forwarding or playing at higher video speeds (Side note: effects like these are IMHO a good reason why we maybe should find a way how to get libva-intel-driver installed by default in Fedora; but that's a different topic). Then I ran vainfo and noticed that there was no libva acceleration anymore.

(In reply to Nicolas Chauvet (kwizart) from comment #2)
> Also worth to test if it still work as appropriate when using:
> export LIBVA_DRIVER_NAME=i965

$ LC_ALL=C; LIBVA_DRIVER_NAME=i965 vainfo
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: User requested driver 'i965'
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
vainfo: intel_driver.c:103: intel_driver_init: Assertion `drm_state' failed.
Aborted (core dumped)

Ok here is a first data point / workaround:

vainfo does still work when using Xorg instead of wayland, so this may be another eglGetDisplay issue somewhere in the va-api stack, now I need to find where ...

Oh, how ugly:

/* XXX: Wayland/DRM support currently lives in Mesa libEGL.so.* library */
#define LIBWAYLAND_DRM_NAME "libEGL.so.1"

    wl_drm_ctx->handle = dlopen(LIBWAYLAND_DRM_NAME, RTLD_LAZY|RTLD_LOCAL);
    if (!wl_drm_ctx->handle)
        return false;

Well that explains, I'm preparing a patch which will hopefully fix this now.

Thorsten,

Are you sure you ever got vaapi to work in a Wayland session ? I've fixed the vainfo command issue, but vaapi still does not work. Even after downgrading to mesa from the normal updates repo + the latest libva packages (instead of my own fixed packages) it still does not work.

For some reason vlc always tries to use vdpau and not libva for me.

In a Xorg gnome3 session I can get vaapi to work in the following ways:

gst-launch-1.0 playbin uri=file:///home/hans/Music/Movies/Pioneer.One.S01E01.720p.x264-VODO/Pioneer.One.S01E01.720p.x264-VODO.mkv
totem Music/Movies/Pioneer.One.S01E01.720p.x264-VODO/Pioneer.One.S01E01.720p.x264-VODO.mkv
VDPAU_DRIVER=va_gl LIBVA_DRIVER_NAME=i965  vlc Music/Movies/Pioneer.One.S01E01.720p.x264-VODO/Pioneer.One.S01E01.720p.x264-VODO.mkv
VDPAU_DRIVER=va_gl LIBVA_DRIVER_NAME=i965 mplayer -vo vdpau  -vc ffh264vdpau Music/Movies/Pioneer.One.S01E01.720p.x264-VODO/Pioneer.One.S01E01.720p.x264-VODO.mkv

All of which fail when using a Wayland session (with the downgraded packages too).
totem gracefully fallsback the others exit with an error.

If you start your movie player from a terminal then you should see messages like these to indicate it is trying to use vaapi:

libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns -1
libva info: User requested driver 'i965'
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39

Which I'm not seeing with vlc unless I use VDPAU_DRIVER=va_gl LIBVA_DRIVER_NAME=i965, which only works with Xorg.

Regards,

Hans

Oh, totem actually does use vaapi under wayland, but for some reason it still uses quite a bit of CPU too. Let me retry with the updates back in place.

(In reply to Hans de Goede from comment #8)
> Oh, totem actually does use vaapi under wayland, but for some reason it
> still uses quite a bit of CPU too. Let me retry with the updates back in
> place.

Ok that works, kicking of builds with fixed packages now.

Here are fixed libva packages, I head to fix the intel-driver package too, since the same hack is copied there too:

https://koji.fedoraproject.org/koji/buildinfo?buildID=859442
http://koji.rpmfusion.org/koji/buildinfo?buildID=3161

I will submit pull-requests upstream with the fix for both packages and update the glvnd update in bodhi to add the libva update.

Looking at the fix, I wonder why libva-wayland.so.1 isn't linked at libEGL in the first place ?

Using libEGL_mesa.so.0 is probably sane for libva-intel-driver, but might break on non mesa based drivers for libva (aka anything using libva-vdpau-driver).
Testing wayland there isn't easy, so I will try to reproduce on f26.

Anyway having EGL client that need to learn one another EGL backend isn't easy.
This somehow breaks encapsulation.

(In reply to Nicolas Chauvet (kwizart) from comment #11)
> Looking at the fix, I wonder why libva-wayland.so.1 isn't linked at libEGL
> in the first place ?

libva-wayland.so is not using EGL, it is re-using some code from mesa by dl-opening mesa's libEGL and then taking one (non EGL) symbol from it. That code really needs to be moved to a separate helper library which then both mesa and libva can use.

> Using libEGL_mesa.so.0 is probably sane for libva-intel-driver, but might
> break on non mesa based drivers for libva (aka anything using
> libva-vdpau-driver).

See above, this is not about EGL, it is about re-using some utility functions defined in mesa, so we really always wants mesa's EGL implementation here and the dlopen call uses RTLD_LOCAL to avoid that none of the other symbols in libEGL leak into the global runtime linking namespace. It is not pretty but it works, and the RTLD_LOCAL should ensure that any actual libEGL users still get their EGL symbols from the glvnd libEGL.so.1 when glvnd is used.

libglvnd-0.2.999-10.gitdc16f8c.fc25 libva-1.7.3-3.fc25 mesa-13.0.4-1.fc25 wlc-0.0.7-3.git12ee978.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

libglvnd-0.2.999-10.gitdc16f8c.fc25 libva-1.7.3-3.fc25 mesa-13.0.4-1.fc25 wlc-0.0.7-3.git12ee978.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Hans, thx for taking care of this. Vainfo works fine here now with the libva update from koji updates-testing-pending and the libva-intel-driver from RPM Fusion's koji.

libglvnd-0.2.999-10.gitdc16f8c.fc25, libva-1.7.3-3.fc25, mesa-13.0.4-1.fc25, wlc-0.0.7-3.git12ee978.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

libglvnd-0.2.999-10.gitdc16f8c.fc25, libva-1.7.3-3.fc25, mesa-13.0.4-1.fc25, wlc-0.0.7-3.git12ee978.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.