| Summary: | kodi segfault since auxiliary/vl: rework the build of the VL code | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Andy Furniss <adf.lists> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | ckoenig.leichtzumerken, darkbasic, john.ettedgui, laszlo.kertesz, lee295012, smoki00790 |
| Version: | git | Keywords: | bisected, have-backtrace, regression |
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
vdpau trace showing errors
build.log |
||
|
Description
Andy Furniss
2014-11-28 23:43:04 UTC
Created attachment 110209 [details]
vdpau trace showing errors
A trace shows that 'No backend implementation could be loaded.'
mplayer is working though.
Sigh... sorry for the break Andy. Seems that I should have tested with nv_vdpau_interop apps, which was never really worked with nouveau :( I'll take a look at this over the next few days. Most likely we end up with the implementation with the dummy symbols loaded first (e.g. kodi loads OGL first the VDPAU). This results in a couple of problems when VDPAu tries to query the video capabilities from the screen. Would it be possible to define the dummy symbols as weak and pointing to zero instead? That might allow overwriting them after loading VDPAU. *** Bug 87054 has been marked as a duplicate of this bug. *** (In reply to Christian König from comment #3) > Most likely we end up with the implementation with the dummy symbols loaded > first (e.g. kodi loads OGL first the VDPAU). This results in a couple of > problems when VDPAu tries to query the video capabilities from the screen. > > Would it be possible to define the dummy symbols as weak and pointing to > zero instead? That might allow overwriting them after loading VDPAU. > There are two catches with using weak symbols: 1. Both modules must be opened with RTLD_GLOBAL (presently holds true). 2. The VDPAU must be opened/used prior to GL. Otherwise we end up with one of two issues: A: DRI module doesn't define the functions -> segfault, as we call function @0 B: DRI module defines stubs -> the stubs end up used, rather than the ones in VDPAU module. So based (and the note below) on those I'll revert the previous approach and shove everything but vl_winsys_dri.c back into the DRI modules :'( On a closer look it seems that we have a _very_ nasty ABI between the DRI and VDPAU modules, which lacks any checks and can explode at any moment. Would be interesting to see if the nvidia driver uses similar approach or copies the objects back and forth between the two contexts, keeping them in sync. An interesting TODO for rainy days :) Christian, Are you concerned about the hidden and unchecked ABI mentioned - can you see an easy way around it ? Guys can you confirm that the patch posted brings back gl-vdpau interop :) (In reply to Emil Velikov from comment #6) > Christian, > > Are you concerned about the hidden and unchecked ABI mentioned - can you see > an easy way around it ? Not really. To be honest I don't have much experience with such kind of linker hacks. But as far as I know if we use weak symbols it shouldn't matter if VDPAU or OGL is loaded first. The strong symbols in the VDPAU module should overwrite the weak ones in the DRI module. As for letting the two interfaces work together that obviously only works if you use the same version of the gallium interface for both. (In reply to Christian König from comment #8) > (In reply to Emil Velikov from comment #6) > > Christian, > > > > Are you concerned about the hidden and unchecked ABI mentioned - can you see > > an easy way around it ? > > Not really. To be honest I don't have much experience with such kind of > linker hacks. > > But as far as I know if we use weak symbols it shouldn't matter if VDPAU or > OGL is loaded first. The strong symbols in the VDPAU module should overwrite > the weak ones in the DRI module. > Unfortunately it does not seem to work. Check out this example project [1], and toggle the USE_FOO_DRI_FIRST at [2]. > As for letting the two interfaces work together that obviously only works if > you use the same version of the gallium interface for both. > True, but we currently do not check if there is a miss-match. Thus my "hidden and unchecked" comment earlier. [1] https://github.com/evelikov/weaksymbols [2] https://github.com/evelikov/weaksymbols/blob/master/Makefile.am#L6 please let me know what logs you need to test this error. I'm willing to help to get this fixed and back on track. *** Bug 87769 has been marked as a duplicate of this bug. *** Seems like Christian dropped the link with the tentative fix. http://patchwork.freedesktop.org/patch/39400/ Guys can you test this please ? Christian, kindly tell me your opinion to the proposal in the patch thread. (In reply to Emil Velikov from comment #12) > Seems like Christian dropped the link with the tentative fix. > http://patchwork.freedesktop.org/patch/39400/ > > Guys can you test this please ? Works OK for me testing with Kodi. (In reply to Emil Velikov from comment #12) > Seems like Christian dropped the link with the tentative fix. > http://patchwork.freedesktop.org/patch/39400/ > > Guys can you test this please ? > Works OK for me too with mpv. Bug 87769 I can confirm this patch allows me to be back on git as well. Since November or so I've been unable to use vdpau with mesa-git, but with this patch it works. I can also confirm that this patch works. Running OpenGL version:2.1 Mesa 10.4.0(git-fb3f7c0) great work! (In reply to Andy Furniss from comment #13) > (In reply to Emil Velikov from comment #12) > > Seems like Christian dropped the link with the tentative fix. > > http://patchwork.freedesktop.org/patch/39400/ > > > > Guys can you test this please ? > > Works OK for me testing with Kodi. I spoke too soon. When trying to build for Kodi, my display works, but my videos do not play. @Andy Furniss, what is your command line for building mesa? I'm using this -- ./autogen.sh --prefix=/opt/xorg --with-gallium-drivers=r600 --with-dri-drivers=radeon --enable-glx-tls am I missing something? (In reply to bgunteriv from comment #17) > (In reply to Andy Furniss from comment #13) > > (In reply to Emil Velikov from comment #12) > > > Seems like Christian dropped the link with the tentative fix. > > > http://patchwork.freedesktop.org/patch/39400/ > > > > > > Guys can you test this please ? > > > > Works OK for me testing with Kodi. > > I spoke too soon. > When trying to build for Kodi, my display works, but my videos do not play. > > @Andy Furniss, what is your command line for building mesa? > I'm using this -- ./autogen.sh --prefix=/opt/xorg > --with-gallium-drivers=r600 --with-dri-drivers=radeon --enable-glx-tls > > > am I missing something? okay, realizing that maybe I don't have the patches included previous to this for Kodi. (In reply to bgunteriv from comment #17) > (In reply to Andy Furniss from comment #13) > > (In reply to Emil Velikov from comment #12) > > > Seems like Christian dropped the link with the tentative fix. > > > http://patchwork.freedesktop.org/patch/39400/ > > > > > > Guys can you test this please ? > > > > Works OK for me testing with Kodi. > > I spoke too soon. > When trying to build for Kodi, my display works, but my videos do not play. > > @Andy Furniss, what is your command line for building mesa? > I'm using this -- ./autogen.sh --prefix=/opt/xorg > --with-gallium-drivers=r600 --with-dri-drivers=radeon --enable-glx-tls > > > am I missing something? I see it may be kodi related - I was testing with git. My build is for radeonsi so looks different anyway. I don't know if your prefix will mean any extra setup needed for vdpau, possibly not - it's a long time since I installed/prefix other than /usr. Haven't retested recently but one thing that I need(ed) on si is --sysconfdir=/etc as for si there are some gpu lockup saving app specific lines in /etc/drirc and it doesn't (or didn't) get read from $prefix/etc which is where it will go by default. I also leave --with-dri-drivers= just like above to build nothing. (In reply to Andy Furniss from comment #19) > (In reply to bgunteriv from comment #17) > > @Andy Furniss, what is your command line for building mesa? Forgot to put I also have --enable-texture-float Not that it's likely to affect this issue anyway. (In reply to bgunteriv from comment #17) > (In reply to Andy Furniss from comment #13) > > (In reply to Emil Velikov from comment #12) > > > Seems like Christian dropped the link with the tentative fix. > > > http://patchwork.freedesktop.org/patch/39400/ > > > > > > Guys can you test this please ? > > > > Works OK for me testing with Kodi. > > I spoke too soon. > When trying to build for Kodi, my display works, but my videos do not play. > > @Andy Furniss, what is your command line for building mesa? > I'm using this -- ./autogen.sh --prefix=/opt/xorg > --with-gallium-drivers=r600 --with-dri-drivers=radeon --enable-glx-tls > > > am I missing something? Where is your libvdpau.so installed? The vdpau drivers need to be in a subdirectory named vdpau under the same directory that the libvdpau.so is installed in. If libvdpau.so is in /usr/lib/x86_64-linux-gnu, and you've got your drivers installed to /opt/xorg, then copy /opt/xorg/lib/vdpau/* to /usr/lib/x86_64-linux-gnu/vdpau/. You may want to use something like smplayer to make sure that vdpau playback works before running something full-screen like kodi... LIBGL_DEBUG=verbose smplayer Then make sure that you're configured to use vdpau for playback, and try to play a file. Then view the mplayer log (in the menus), and see if there's any errors about not being able to find a vdpau driver. (In reply to Aaron Watry from comment #21) > (In reply to bgunteriv from comment #17) > > (In reply to Andy Furniss from comment #13) > > > (In reply to Emil Velikov from comment #12) > > > > Seems like Christian dropped the link with the tentative fix. > > > > http://patchwork.freedesktop.org/patch/39400/ > > > > > > > > Guys can you test this please ? > > > > > > Works OK for me testing with Kodi. > > > > I spoke too soon. > > When trying to build for Kodi, my display works, but my videos do not play. > > > > @Andy Furniss, what is your command line for building mesa? > > I'm using this -- ./autogen.sh --prefix=/opt/xorg > > --with-gallium-drivers=r600 --with-dri-drivers=radeon --enable-glx-tls > > > > > > am I missing something? > > Where is your libvdpau.so installed? The vdpau drivers need to be in a > subdirectory named vdpau under the same directory that the libvdpau.so is > installed in. > > If libvdpau.so is in /usr/lib/x86_64-linux-gnu, and you've got your drivers > installed to /opt/xorg, then copy /opt/xorg/lib/vdpau/* to > /usr/lib/x86_64-linux-gnu/vdpau/. > that did it! working properly now, with the patch. thanks @Aaron Watry. Any news on this? Will this be making it into a future Mesa release? Hi guys, sorry about the delay. Christian had some comments on the original patch which I've addressed here - http://patchwork.freedesktop.org/patch/42201/ Can you give it a spin ? (In reply to Emil Velikov from comment #25) > Hi guys, sorry about the delay. > > Christian had some comments on the original patch which I've addressed here > - http://patchwork.freedesktop.org/patch/42201/ Can you give it a spin ? Works for me. Created attachment 113327 [details]
build.log
It doesn't build anymore with your latest patch (Mesa-dev-4-4-auxiliary-vl-bring-back-the-VL-code-for-the-dri-targets.patch).
With the old "Mesa-dev-auxiliary-vl-move-most-sources-back-into-the-aux-library.patch" it still compiles and work flawlessly.
(In reply to Emil Velikov from comment #25) > Hi guys, sorry about the delay. > > Christian had some comments on the original patch which I've addressed here > - http://patchwork.freedesktop.org/patch/42201/ Can you give it a spin ? I just tried building mesa-git with it. It breaks building openmax: ../../../../src/gallium/state_trackers/omx/.libs/libomxtracker.a(entrypoint.o): In function `omx_get_screen': entrypoint.c:(.text+0x92): undefined reference to `vl_screen_create' ../../../../src/gallium/state_trackers/omx/.libs/libomxtracker.a(entrypoint.o): In function `omx_put_screen': entrypoint.c:(.text+0xf1): undefined reference to `vl_screen_destroy' but if I disable that state tracker, then I have no issue building and vdpau works fine as with the previous patch. So... almost there I guess. Forgot to update the omx target, silly me - v2 of the patch should handle that http://patchwork.freedesktop.org/patch/42260/ (In reply to Emil Velikov from comment #29) > Forgot to update the omx target, silly me - v2 of the patch should handle > that > http://patchwork.freedesktop.org/patch/42260/ That works! Thanks for the quick v2. Works fine here, thanks. commit c39dbfdd0f764b1aaa7319b4694e7335692993dd Author: Emil Velikov <emil.l.velikov@gmail.com> Date: Tue Feb 10 15:11:09 2015 +0000 auxiliary/vl: bring back the VL code for the dri targets The patch has landed in master + 10.5(rc1). Thanks guys for testing and sorry again for breaking it. Already fixed for quite a while. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.