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

Mon Jun 23 11:45:27 PDT 2014

On a different note, do we really need the suffixes .1.0.0 etc.? It's
not like the version is going to change.

Marek

On Mon, Jun 23, 2014 at 8:31 PM, Aaron Watry <awatry at gmail.com> 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
>
> Then I run ldconfig:
> awatry at ws-awatry:/usr/local/lib/vdpau$ sudo ldconfig
>
> 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$
>
> 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
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev