[Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)

Mon Jun 23 13:21:22 PDT 2014

On Mon, Jun 23, 2014 at 1:54 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 23/06/14 19:31, Aaron Watry wrote:
>> Using /usr/local as PREFIX and an empty /usr/local/lib/vdpau directory
>> to start, after make install of mesa I end up with
>> /usr/local/lib/vdpau/ containing:
>>
>> awatry at ws-awatry:/usr/local/lib/vdpau$ ls -l
>> total 26944
>> lrwxrwxrwx 1 root root       22 Jun 23 13:25 libvdpau_r600.so ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root       22 Jun 23 13:25 libvdpau_r600.so.1 ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root       22 Jun 23 13:25 libvdpau_r600.so.1.0 ->
>> libvdpau_r600.so.1.0.0
>> -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root       26 Jun 23 13:25 libvdpau_radeonsi.so ->
>> libvdpau_radeonsi.so.1.0.0
>> lrwxrwxrwx 1 root root       26 Jun 23 13:25 libvdpau_radeonsi.so.1 ->
>> libvdpau_radeonsi.so.1.0.0
>> lrwxrwxrwx 1 root root       26 Jun 23 13:25 libvdpau_radeonsi.so.1.0
>> -> libvdpau_radeonsi.so.1.0.0
>> -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0
>>
> In case you're interested you can check the i-node for each file (ls -i) where
> both libvdpau*1.0.0 should link to the same one.
>
> Above files look good. I'm guessing that this is with the linked patch ?
>

Yeah, that's with the patch.  I just did an ls -i, and the files do
indeed reference the same i-node.  This matches with the previous
check I had done before the patch (du -sk /usr/local/lib/vdpau roughly
matched the size of one of the links, not the sum of both).

>> Then I run ldconfig:
>> awatry at ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig
>>
> Rather silly question but why ? AFAIK the vdpau backend explicitly dlopened,
> thus you should not need ldconfig here.

The first time that I discovered this was before I knew that libvdpau
only checked it's compile-time prefix for back-end drivers.  I had
added /usr/local/lib/vdpau to /etc/ld.so.conf.d/vdpau.conf on my
system in an attempt to add my vdpau libraries to the library path.
It was a dead-end because of the hard-coded vdpau back-end paths, but
the discovery that the link is getting created after install by the
next ldconfig run was intriguing which is why I called it out.

My system is set up with all distro-provided packages under
/usr/lib/{arch}/, and all of my hand-compiled stuff under
/usr/local/lib (64-bit only).  My library path allows /usr/local/lib
to override /usr/lib/{arch}, but only for packages that I've bothered
to rebuild myself.  At this point, that includes waffle, glamor, mesa,
libclc, xf86-video-ati, and LLVM.  It does NOT include libvdpau, as I
had never known a reason to build that myself.  Now, I'll either rely
on my distro's vdpau-backend drivers, add libvdpau to the list of
packages I'm building myself, or just symlink
/usr/lib/x86_64-linux-gnu/vdpau to /usr/local/lib/vdpau.

--Aaron

>
>> And now /usr/local/lib/vdpau/ contains:
>> lrwxrwxrwx 1 root root       22 Jun 23 13:27 libvdpau_gallium.so.1 ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root       22 Jun 23 13:25 libvdpau_r600.so ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root       22 Jun 23 13:25 libvdpau_r600.so.1 ->
>> libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root       22 Jun 23 13:25 libvdpau_r600.so.1.0 ->
>> libvdpau_r600.so.1.0.0
>> -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_r600.so.1.0.0
>> lrwxrwxrwx 1 root root       26 Jun 23 13:25 libvdpau_radeonsi.so ->
>> libvdpau_radeonsi.so.1.0.0
>> lrwxrwxrwx 1 root root       26 Jun 23 13:25 libvdpau_radeonsi.so.1 ->
>> libvdpau_radeonsi.so.1.0.0
>> lrwxrwxrwx 1 root root       26 Jun 23 13:25 libvdpau_radeonsi.so.1.0
>> -> libvdpau_radeonsi.so.1.0.0
>> -rwxr-xr-x 2 root root 13792983 Jun 23 13:25 libvdpau_radeonsi.so.1.0.0
>>
>>
>> Configuration:
>> $ ./configure --with-dri-drivers=
>> --with-dri-driverdir=/usr/local/lib/dri/ --enable-debug
>> --enable-opencl --enable-opencl-icd
>> --with-gallium-drivers=r600,radeonsi --enable-gles1 --enable-gles2
>> --enable-texture-float --with-egl-platforms=drm,x11 --enable-glx-tls
>> --enable-dri3 --enable-omx
>>
>>
>> And just in case it's useful,after building ${mesa_src_root}/lib/gallium has:
>> awatry at ws-awatry:~/src/mesa/lib/gallium$ ls
>> libMesaOpenCL.so    libvdpau_r600.so      libvdpau_r600.so.1.0.0
>> libvdpau_radeonsi.so.1.0      radeonsi_dri.so
>> libMesaOpenCL.so.1    libvdpau_r600.so.1    libvdpau_radeonsi.so
>> libvdpau_radeonsi.so.1.0.0
>> libMesaOpenCL.so.1.0.0    libvdpau_r600.so.1.0  libvdpau_radeonsi.so.1
>>  r600_dri.so
>> awatry at ws-awatry:~/src/mesa/lib/gallium$
>>
> Looks good. Are there any extra messages/warning/errors during the build stage ?
>
> Cheers,
> Emil
>
>> On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 23/06/14 18:07, Aaron Watry wrote:
>>>> On my machine, ${PREFIX}/lib/vdpau contains:
>>>> libvdpau_gallium.so.1 -> libvdpau_r600.so.1.0.0
>>>> libvdpau_r600.so*
>>>> libvdpau_radeonsi.so*
>>>>
>>>> Note that libvdpau_gallium.so.1 is only created when I force an
>>>> ldconfig on my system (until then, I just have
>>>> libvdpau_[r600|radeonsi]*)
>>>>
>>> What do you mean with "force an ldconfig" ? Does [1] help ?
>>>
>>>> For some reason, while the files are in the same place, mplayer -vo
>>>> vdpau chokes on loading these files now.  If I copy
>>>> libvdpau_r600.so.1.0.0 to /usr/local/lib/libvdpau_r600.so, then
>>>> mplayer (-vo vdpau) picks it up and plays without issue.  Is the VDPAU
>>>> backend loader looking in the wrong directory?
>>>>
>>>
>>> The path of the vdpau backends is hard-coded in libvdapu at build time.
>>> vdpau/master can pick the path via VDPAU_DRIVER_PATH but there is no vdpau
>>> release that has it afaik.
>>>
>>> -Emil
>>>
>>> [1] http://patchwork.freedesktop.org/patch/28378/
>>>
>>>> --Aaron
>>>>
>>>>
>>>> On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>> On 23/06/14 16:10, Andy Furniss wrote:
>>>>>> Emil Velikov wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> These patches add support for building (grouping) the various targets
>>>>>>> per API, meaning that only one library will be created  for e.g.
>>>>>>> vdpau (libvdpau_gallium) with individual ones (libvdpau_r600) being a
>>>>>>> hardlink to it.
>>>>>>
>>>>>> How is this supposed to work from a users point of view, by which I mean
>>>>>> that it seems if I build current mesa I no longer have vdpau.
>>>>>>
>>>>> Yes I had a few copy/paste typos that were causing make install to fall short
>>>>> when generating the (sym|hard)links. Should be fixed with commit 11e46a32aed.
>>>>>
>>>>> Let me know if latest master work for you.
>>>>>
>>>>> -Emil
>>>>>
>>>>>> Of course I do if I leave the old libs in place it still uses them, but
>>>>>> if I remove them I get no new links installed.
>>>>>>
>>>>>> ./autogen.sh --prefix=/usr --enable-texture-float
>>>>>> --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast
>>>>>> --enable-opencl --enable-vdpau  --e--prefix you use to compile it. So if you're putting mesa into anable-gbm --enable-shared-glapi
>>>>>> --enable-glx-tls --with-dri-drivers= && make -j5
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mesa-dev mailing list
>>>>> mesa-dev at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>