On 30.06.2016 13:11, Emil Velikov wrote: > Hi poma, > > Seems like you're missed your question. "nouveau_drv_video.so ?" does > not mean much I'm afraid :-( > > On 30 June 2016 at 11:03, poma <pomidorabelis...@gmail.com> wrote: >> On 30.06.2016 08:27, Xiang, Haihao wrote: >>> >>> >>> Are you using VA-API on X11? libva gets the driver name from Xserver, >>> it is nouveau for you. so libva tries to load nouveau_drv_video.so. >>> You can create a symlink for nouveau pointing to a available driver or >>> just ignore the message because you have gallium_drv_video.so now. >>> > Indeed. The tricky part is that libva honours the gallium_drv_video.so > name only in some corner cases :-( > >>> Thanks >>> Haihao >>> >> >> >> In practice, regarding video acceleration, nouveau has proven to be fragile, >> no matter what and how to config >> >> $ file /usr/lib64/dri/nouveau_drv_video.so >> /usr/lib64/dri/nouveau_drv_video.so: cannot open >> `/usr/lib64/dri/nouveau_drv_video.so' (No such file or directory) >> >> $ ll /usr/lib64/dri/nouveau_drv_video.so >> ls: cannot access '/usr/lib64/dri/nouveau_drv_video.so': No such file or >> directory >> > This should no longer be the case with mesa 12.0, where appropriately > named files/links are created. > > >> # ln -s vdpau_drv_video.so nouveau_drv_video.so >> >> $ ll /usr/lib64/dri/nouveau_drv_video.so >> ... /usr/lib64/dri/nouveau_drv_video.so -> vdpau_drv_video.so >> >> $ file /usr/lib64/dri/nouveau_drv_video.so >> /usr/lib64/dri/nouveau_drv_video.so: symbolic link to vdpau_drv_video.so >> > If you do this you're up-to the mercy of the vdpau_drv_video (wrapper) > driver, which seems abandoned for the past 4 years. > > >> # ln -fs gallium_drv_video.so nouveau_drv_video.so >> >> $ ll /usr/lib64/dri/nouveau_drv_video.so >> ... /usr/lib64/dri/nouveau_drv_video.so -> gallium_drv_video.so >> >> $ file /usr/lib64/dri/nouveau_drv_video.so >> /usr/lib64/dri/nouveau_drv_video.so: symbolic link to gallium_drv_video.so >> > As said above, this should no longer be needed. > > >> >> $ icecat >> ... >> libva info: VA-API version 0.39.2 >> libva info: va_getDriverName() returns 0 >> libva info: Trying to open /usr/lib64/dri/nouveau_drv_video.so >> libva info: Found init function __vaDriverInit_0_39 >> libva info: va_openDriver() returns 0 >> icecat: pushbuf.c:727: nouveau_pushbuf_data: Assertion `kref' failed. >> Aborted (core dumped) >> >> https://bugzilla.redhat.com/attachment.cgi?id=1174453 >> > From a quick guess - MT and/or GL VAAPI interop related ? If so, these > two [1] patches could help. > > -Emil > > [1] > https://github.com/imirkin/mesa/commit/be089dd63c6102df48de06bb7184ca1202f1e0f5 > https://github.com/imirkin/mesa/commit/5e8e523514e73afa48916e094583f4ca83f05175 >
Thanks for the explanation $ rpm -qf /usr/lib64/dri/nouveau_drv_video.so mesa-dri-drivers-12.0.0-0.5.rc4.fc24.x86_64 incl.: 0001-WIP-nouveau-add-locking.patch 0002-nouveau-more-locking-make-sure-that-fence-work-is-al.patch $ rpm -qf /usr/lib64/dri/vdpau_drv_video.so libva-vdpau-driver-0.7.4-14.fc24.x86_64 # rpm -evh libva-vdpau-driver Preparing... ################################# [100%] Cleaning up / removing... 1:libva-vdpau-driver-0.7.4-14.fc24 ################################# [100%] icecat-38.8.0 with https://github.com/lejenome/html5-video-everywhere produce kernel oops - it is enough to attempt to change video settings of add-on icecat-38.8.0 without html5-video-everywhere still can crush - running native yt player, but system stays OK although with nouveau 0000:02:00.0: fifo: CACHE_ERROR - ch 6 [source:src[2854]] subc 0 mthd 0060 data beef0201 for comparison, firefox-47.0 with html5-video-everywhere with the exception of delays a few seconds of the first video frame in full screen mode, and same delay at exit the full screen mode, works OK - not breaking anything. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
