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

Emil Velikov emil.l.velikov at gmail.com
Mon Jun 23 12:47:19 PDT 2014 

I'm afraid that I cannot predict the future ("is always going to be.."). IMHO
we should keep the major, for when the loader gains different codepaths for
v1.0 vs v2.0 etc. Adding the mesa version will easily allow us to check for
broken/manged installs and possibly other issues.

Don't plan on touching any of the above yet, but would be nice to see if my
rationale is not completely bonkers :)

Emil

On 23/06/14 20:21, Marek Olšák wrote:
> If the version is always going to be 1.0.0, it's pointless. If it's
> going to be equal to the Mesa version, then it might find some use.
> 
> Marek
> 
> On Mon, Jun 23, 2014 at 9:12 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> The vdpau loader requires only major, and falls back to an unversioned SO.
>> Thus IMHO we should keep at least the major.
>>
>> In the future we might want to move to a versioning scheme similar to nvidia,
>> which lacks the revision number, thus we'll be OK with the BSD guys :)
>>
>> libvdpau_nvidia.so -> libvdpau_nvidia.so.1
>> libvdpau_nvidia.so.1 -> libvdpau_nvidia.so.319.22
>> libvdpau_nvidia.so.319.22
>>
>> libvdpau_nouveau.so -> libvdpau_nouveau.so.1
>> libvdpau_nouveau.so.1 -> libvdpau_nouveau.so.10.2
>> libvdpau_nouveau.so.10.2
>>
>>
>> -Emil
>>
>> On 23/06/14 19:45, Marek Olšák wrote:
>>> 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
>>

More information about the mesa-dev mailing list