Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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. 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 --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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 --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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]*)
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?
--Aaron
On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@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 --enable-gbm --enable-shared-glapi
--enable-glx-tls --with-dri-drivers= make -j5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On Mon, Jun 23, 2014 at 1:07 PM, Aaron Watry awa...@gmail.com 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]*)
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?
libvdpau only loads files from a fixed location, as determined by the
--prefix you use to compile it. So if you're putting mesa into a
different prefix than libvdpau it won't work.
--Aaron
On Mon, Jun 23, 2014 at 11:42 AM, Emil Velikov emil.l.veli...@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 --enable-gbm --enable-shared-glapi
--enable-glx-tls --with-dri-drivers= make -j5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
Emil Velikov wrote:
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.
No, it fails to install anything to do with libvdpau_gallium* which is
present in the tree in /src/gallium/targets/vdpau/.libs some output below.
Additionally it copies/makes the links for libvdpau_radeonsi* but
doesn't install the target libvdpau_radeonsi.so.1.0.0, which is present
in tree in lib/gallium.
/bin/mkdir -p '/usr/lib/vdpau'
/bin/sh ../../../../libtool --mode=install /bin/install -c
libvdpau_gallium.la '/usr/lib/vdpau'
libtool: install: /bin/install -c .libs/libvdpau_gallium.so.1.0.0
/usr/lib/vdpau/libvdpau_gallium.so.1.0.0
libtool: install: (cd /usr/lib/vdpau { ln -s -f
libvdpau_gallium.so.1.0.0 libvdpau_gallium.so.1 || { rm -f
libvdpau_gallium.so.1 ln -s libvdpau_gallium.so.1.0.0
libvdpau_gallium.so.1; }; })
libtool: install: (cd /usr/lib/vdpau { ln -s -f
libvdpau_gallium.so.1.0.0 libvdpau_gallium.so || { rm -f
libvdpau_gallium.so ln -s libvdpau_gallium.so.1.0.0
libvdpau_gallium.so; }; })
libtool: install: /bin/install -c .libs/libvdpau_gallium.lai
/usr/lib/vdpau/libvdpau_gallium.la
libtool: finish: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/sbin ldconfig -n
/usr/lib/vdpau
--
Libraries have been installed in:
/usr/lib/vdpau
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--
make install-data-hook
make[5]: Entering directory
'/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau'
GEN install-data-hook
ln: failed to create hard link
‘//usr/lib/vdpau/libvdpau_radeonsi.so.1.0.0’ =
‘.libs/libvdpau_gallium.so.1.0.0’: Invalid cross-device link
make[5]: Leaving directory
'/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau'
make[4]: Leaving directory
'/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau'
make[3]: Leaving directory
'/mnt/sdb1/Src64/Mesa-git/mesa/src/gallium/targets/vdpau'
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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.veli...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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@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@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@ws-awatry:~/src/mesa/lib/gallium$ ls
libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0
libvdpau_radeonsi.so.1.0 radeonsi_dri.so
libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so
libvdpau_radeonsi.so.1.0.0
libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1
r600_dri.so
awatry@ws-awatry:~/src/mesa/lib/gallium$
On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@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.veli...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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 awa...@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@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@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@ws-awatry:~/src/mesa/lib/gallium$ ls
libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0
libvdpau_radeonsi.so.1.0 radeonsi_dri.so
libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so
libvdpau_radeonsi.so.1.0.0
libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1
r600_dri.so
awatry@ws-awatry:~/src/mesa/lib/gallium$
On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@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.veli...@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
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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@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 ?
Then I run ldconfig:
awatry@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.
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@ws-awatry:~/src/mesa/lib/gallium$ ls
libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0
libvdpau_radeonsi.so.1.0 radeonsi_dri.so
libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so
libvdpau_radeonsi.so.1.0.0
libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1
r600_dri.so
awatry@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.veli...@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.veli...@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
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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 awa...@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@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@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@ws-awatry:~/src/mesa/lib/gallium$ ls
libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0
libvdpau_radeonsi.so.1.0 radeonsi_dri.so
libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so
libvdpau_radeonsi.so.1.0.0
libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1
r600_dri.so
awatry@ws-awatry:~/src/mesa/lib/gallium$
On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@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.veli...@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
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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.veli...@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 awa...@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@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@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@ws-awatry:~/src/mesa/lib/gallium$ ls
libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0
libvdpau_radeonsi.so.1.0 radeonsi_dri.so
libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so
libvdpau_radeonsi.so.1.0.0
libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1
r600_dri.so
awatry@ws-awatry:~/src/mesa/lib/gallium$
On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@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.veli...@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
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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.veli...@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 awa...@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@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@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@ws-awatry:~/src/mesa/lib/gallium$ ls
libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0
libvdpau_radeonsi.so.1.0 radeonsi_dri.so
libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so
libvdpau_radeonsi.so.1.0.0
libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1
r600_dri.so
awatry@ws-awatry:~/src/mesa/lib/gallium$
On Mon, Jun 23, 2014 at 1:12 PM, Emil Velikov emil.l.veli...@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
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On Mon, Jun 23, 2014 at 1:54 PM, Emil Velikov emil.l.veli...@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@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@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@ws-awatry:~/src/mesa/lib/gallium$ ls
libMesaOpenCL.solibvdpau_r600.so libvdpau_r600.so.1.0.0
libvdpau_radeonsi.so.1.0 radeonsi_dri.so
libMesaOpenCL.so.1libvdpau_r600.so.1libvdpau_radeonsi.so
libvdpau_radeonsi.so.1.0.0
libMesaOpenCL.so.1.0.0libvdpau_r600.so.1.0 libvdpau_radeonsi.so.1
r600_dri.so
awatry@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.veli...@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
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 23/06/14 21:21, Aaron Watry wrote:
On Mon, Jun 23, 2014 at 1:54 PM, Emil Velikov emil.l.veli...@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@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).
Great, now all we need is for distros to package them properly preserving the
hardlink :)
Then I run ldconfig:
awatry@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.
Makes sense, thanks for clarifying.
AFAIK pretty much every library provided by mesa follows the rule - Is it
installed in ${libdir} ?
- No, dlopen only.
- Yes, dlopen/link against it.
-Emil
--Aaron
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 17/06/14 19:24, Emil Velikov wrote: On 12/06/14 20:56, 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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. The former method has been used by the egl-static while the latter by opencl and gbm targets since they were introduced. By default we build with static pipe-drivers. Some numbers + extra info [1] [Static] dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB [Shared] Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB [Current] dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB The previous series can be found here [2] Changes since then - Convert targets individually. - OMX targets now work, and the final library is now libomx-mesa.so - Dropped the DRI targets for now - A handfull of typos thinkos and bugs fixed. My plan is to have these pushed in ~4 stages, with two stages per week. This way I will be able to crack on with the remaining bits and have all of it tested well before we branch the next release. Gents, In case I was not clear enough - my plan is to push 01-11 (prep work) - this wednesday(tomorrow) For everyone interested, I have disabled the i915-sw target, and omitted patches 3 and 4 before pushing. As neither i915 nor svga needs the link to wrapper winsys and softpipe/llvmpipe. -Emil 12-16 (vdpau, xvmc)- over the weekend 17-23 (omx, cleanup)- mid next week 24-26 (xa, gbm, egl)- next week's weekend Don't be shy to speak up, if you feel that any of the above sounds unreasonable. Feel free to shout at me as soon as you notice any bugs :) -Emil Series is availabe at https://github.com/evelikov/Mesa/tree/static-or-shared-pipe-drivers As always comments and suggestions are greatly appreciated. Cheers, -Emil [1] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059806.html [2] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059628.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
Hi Emil,
On Fri, Jun 13, 2014 at 3:56 AM, Emil Velikov emil.l.veli...@gmail.com 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.
This allows us to have substantial space savings as the API(state-tracker)
is available only once. Additionally it adds support for shared
pipe-drivers via a _unstable_ interface, which saves us the duplication
across X APIs.
The former method has been used by the egl-static while the latter by
opencl and gbm targets since they were introduced.
By default we build with static pipe-drivers.
Some numbers + extra info [1]
[Static]
dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB
vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB
Total: 10MiB
[Shared]
Libraries:
dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB
vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB
gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB
Total: 9.8MiB
[Current]
dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB
vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB
Total: 20.2MiB
The previous series can be found here [2]
Changes since then
- Convert targets individually.
- OMX targets now work, and the final library is now libomx-mesa.so
- Dropped the DRI targets for now
- A handfull of typos thinkos and bugs fixed.
My plan is to have these pushed in ~4 stages, with two stages per week.
This way I will be able to crack on with the remaining bits and have all
of it tested well before we branch the next release.
Series is availabe at
https://github.com/evelikov/Mesa/tree/static-or-shared-pipe-drivers
As always comments and suggestions are greatly appreciated.
Thanks for working on this. This is a tough issue to tackle. I have
a few questions/comments, which I am fine to see them resolved either
before or after landing your series.
I see this work as to define an internal API to manage pipe drivers.
The lack of such API previously led us to targets, where each target
knows how to load a specific driver. With your changes, state
trackers that need to work with pipe drivers have a way to do so. As
a result, files such as
dri/target.c,
xa/target.c,
xvmc/target.c,
vdpau/target.c, and
omx/target.c
become quite dummy and redundant. Do you see a way to get rid of
targets entirely?
In the same view, and noticing that all users of the API have this snippet
#if GALLIUM_STATIC_TARGETS
scrn-base.pscreen = dd_create_screen(fd);
#else
if (pipe_loader_drm_probe_fd(scrn-base.dev, fd, true))
scrn-base.pscreen = pipe_loader_create_screen(scrn-base.dev,
PIPE_SEARCH_DIR);
#endif // GALLIUM_STATIC_TARGETS
I think it makes sense hide this difference behind the API. Another
thing I noted is that the non-static path allows the user to auth the
fd while the static path doesn't. It is not clear to me how come the
static path works.
On the other hand, the implementation of the API extends itself a bit
when DRI_TARGET is defined. That is ugly from the API's point of
view. Could that be abstracted somehow so that it can be used
elsewhere or at least looks nicer?
Finally, the API is limited to C API (i.e., inline_{drm,sw}_helper.h).
At the build system level, we also like a way to easily manage a pipe
driver. For example, we can see this snippet in many of the
Makefile.am
if HAVE_GALLIUM_RADEONSI
STATIC_TARGET_CPPFLAGS += -DGALLIUM_RADEONSI
STATIC_TARGET_LIB_DEPS += \
$(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \
$(RADEON_LIBS)
endif
If pipe drivers can be accompanies by some Makefile rules specifying
how it should be built, in addition to how it can be loaded, we can
get rid of those duplicated rules.
Cheers,
-Emil
[1] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059806.html
[2] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059628.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
o...@lunarg.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 18 June 2014 08:21, Chia-I Wu olva...@gmail.com wrote:
Hi Emil,
On Fri, Jun 13, 2014 at 3:56 AM, Emil Velikov emil.l.veli...@gmail.com
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.
This allows us to have substantial space savings as the API(state-tracker)
is available only once. Additionally it adds support for shared
pipe-drivers via a _unstable_ interface, which saves us the duplication
across X APIs.
The former method has been used by the egl-static while the latter by
opencl and gbm targets since they were introduced.
By default we build with static pipe-drivers.
Some numbers + extra info [1]
[Static]
dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB
vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB
Total: 10MiB
[Shared]
Libraries:
dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB
vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB
gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB
Total: 9.8MiB
[Current]
dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8
MiB
vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB
Total: 20.2MiB
The previous series can be found here [2]
Changes since then
- Convert targets individually.
- OMX targets now work, and the final library is now libomx-mesa.so
- Dropped the DRI targets for now
- A handfull of typos thinkos and bugs fixed.
My plan is to have these pushed in ~4 stages, with two stages per week.
This way I will be able to crack on with the remaining bits and have all
of it tested well before we branch the next release.
Series is availabe at
https://github.com/evelikov/Mesa/tree/static-or-shared-pipe-drivers
As always comments and suggestions are greatly appreciated.
Thanks for working on this. This is a tough issue to tackle. I have
a few questions/comments, which I am fine to see them resolved either
before or after landing your series.
I see this work as to define an internal API to manage pipe drivers.
Interesting, I do not see this as an attempt to define an API, but to
cleanup all the mayhem that our targets currently are:
* Cleanup the build system - drop symlinks, including the same source
files from different locations.
* Make targets less error prone by using static pipe-drivers by
default. Shared ones we lack versioning and ... are a big can of
worms.
* Minimize all the target.c duplication across each target. Makefiles
are in similar boat.
* Allow people to use the unstable pipe-drivers if they are really
short on size and know what they are doing.
The lack of such API previously led us to targets, where each target
knows how to load a specific driver. With your changes, state
trackers that need to work with pipe drivers have a way to do so. As
a result, files such as
dri/target.c,
xa/target.c,
xvmc/target.c,
vdpau/target.c, and
omx/target.c
become quite dummy and redundant. Do you see a way to get rid of
targets entirely?
Indeed if/when an API comes around these targets may become redundant.
In the same view, and noticing that all users of the API have this snippet
#if GALLIUM_STATIC_TARGETS
scrn-base.pscreen = dd_create_screen(fd);
#else
if (pipe_loader_drm_probe_fd(scrn-base.dev, fd, true))
scrn-base.pscreen = pipe_loader_create_screen(scrn-base.dev,
PIPE_SEARCH_DIR);
#endif // GALLIUM_STATIC_TARGETS
I think it makes sense hide this difference behind the API. Another
I'm not sure that is feasible, yet. Biggest obstacle is the
pipe-loaders API, and mainly the software winsys' with their
variation.
thing I noted is that the non-static path allows the user to auth the
fd while the static path doesn't. It is not clear to me how come the
static path works.
Some of the targets do not need an auth as the loader (libGL,
libEGL...) already does that. I have not extensively tested the
pipe-loader paths but they seems to work with simple tasks - glxgears,
mplayer(vpdau). It could be that we might need to drop the auth in
some cases - to be sorted out once confirmed to be an issue.
On the other hand, the implementation of the API extends itself a bit
when DRI_TARGET is defined. That is ugly from the API's point of
view. Could that be abstracted somehow so that it can be used
elsewhere or at least looks nicer?
Finally, the API is limited to C API (i.e., inline_{drm,sw}_helper.h).
At the build system level, we also like a way to easily manage a pipe
driver. For example, we can see this snippet in many of the
Makefile.am
if HAVE_GALLIUM_RADEONSI
STATIC_TARGET_CPPFLAGS += -DGALLIUM_RADEONSI
STATIC_TARGET_LIB_DEPS += \
$(top_builddir)/src/gallium/drivers/radeonsi/libradeonsi.la \
$(RADEON_LIBS)
endif
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On Wed, Jun 18, 2014 at 8:14 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 18 June 2014 08:21, Chia-I Wu olva...@gmail.com wrote: Hi Emil, On Fri, Jun 13, 2014 at 3:56 AM, Emil Velikov emil.l.veli...@gmail.com 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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. The former method has been used by the egl-static while the latter by opencl and gbm targets since they were introduced. By default we build with static pipe-drivers. Some numbers + extra info [1] [Static] dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB [Shared] Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB [Current] dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB The previous series can be found here [2] Changes since then - Convert targets individually. - OMX targets now work, and the final library is now libomx-mesa.so - Dropped the DRI targets for now - A handfull of typos thinkos and bugs fixed. My plan is to have these pushed in ~4 stages, with two stages per week. This way I will be able to crack on with the remaining bits and have all of it tested well before we branch the next release. Series is availabe at https://github.com/evelikov/Mesa/tree/static-or-shared-pipe-drivers As always comments and suggestions are greatly appreciated. Thanks for working on this. This is a tough issue to tackle. I have a few questions/comments, which I am fine to see them resolved either before or after landing your series. I see this work as to define an internal API to manage pipe drivers. Interesting, I do not see this as an attempt to define an API, but to cleanup all the mayhem that our targets currently are: * Cleanup the build system - drop symlinks, including the same source files from different locations. * Make targets less error prone by using static pipe-drivers by default. Shared ones we lack versioning and ... are a big can of worms. * Minimize all the target.c duplication across each target. Makefiles are in similar boat. The reason that the state trackers can manage statically linked pipe drivers, or the duplications in target.c can be killed is because of the introduction of an API (inline_drm_helper.h), or if you prefer, helper functions. Either way, a set of functions are defined to help manage statically linked pipe drivers. State trackers tend to do #ifdef GALLIUM_STATIC_TARGETS /* use inline_drm_helper.h */ ... #else /* use pipe_loader.h */ ... #endif IMHO, we should be able to define a single API, or a single set of helper functions, to manage pipe drivers, no matter they are statically linked or dynamically loaded. Note that inline_drm_helper.h is not stateless: dd_create_screen must be called first to initialize a static variable. It may even be possible to extend pipe loader for the statically linked case. * Allow people to use the unstable pipe-drivers if they are really short on size and know what they are doing. The lack of such API previously led us to targets, where each target knows how to load a specific driver. With your changes, state trackers that need to work with pipe drivers have a way to do so. As a result, files such as dri/target.c, xa/target.c, xvmc/target.c, vdpau/target.c, and omx/target.c become quite dummy and redundant. Do you see a way to get rid of targets entirely? Indeed if/when an API comes around these targets may become redundant. Well, with inline_drm_helper.h and the like, there is already basically nothing in those target.c. I do not even get why we need those #include's in them :) As things are right now, for most state trackers (dri, gbm, omx, vdpau, xa, and xvmc), there is a matching target, and the only things in the target are rules to build it. I am not suggesting you should update the series to kill the targets. As I said, I believe it takes a lot of time to get things to where they are now, and I am fine to see any of this resolved later. In the same view, and noticing that all users of the API have this snippet #if GALLIUM_STATIC_TARGETS scrn-base.pscreen = dd_create_screen(fd); #else if (pipe_loader_drm_probe_fd(scrn-base.dev, fd, true)) scrn-base.pscreen =
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 18/06/14 15:07, Chia-I Wu wrote: On Wed, Jun 18, 2014 at 8:14 PM, Emil Velikov emil.l.veli...@gmail.com wrote: [...] Interesting, I do not see this as an attempt to define an API, but to cleanup all the mayhem that our targets currently are: * Cleanup the build system - drop symlinks, including the same source files from different locations. * Make targets less error prone by using static pipe-drivers by default. Shared ones we lack versioning and ... are a big can of worms. * Minimize all the target.c duplication across each target. Makefiles are in similar boat. The reason that the state trackers can manage statically linked pipe drivers, or the duplications in target.c can be killed is because of the introduction of an API (inline_drm_helper.h), or if you prefer, helper functions. Seems like my definition of API slightly differs :) /me drops down the EE books and picks up a CS one. Either way, a set of functions are defined to help manage statically linked pipe drivers. State trackers tend to do #ifdef GALLIUM_STATIC_TARGETS /* use inline_drm_helper.h */ ... #else /* use pipe_loader.h */ ... #endif IMHO, we should be able to define a single API, or a single set of helper functions, to manage pipe drivers, no matter they are statically linked or dynamically loaded. Note that inline_drm_helper.h is not stateless: dd_create_screen must be called first to initialize a static variable. It may even be possible to extend pipe loader for the statically linked case. I.e. move the static or shared pipe-drivers decision to the pipe-loader ? Currently we need the latter due to the opencl target, although with that sorted it sounds doable. * Allow people to use the unstable pipe-drivers if they are really short on size and know what they are doing. The lack of such API previously led us to targets, where each target knows how to load a specific driver. With your changes, state trackers that need to work with pipe drivers have a way to do so. As a result, files such as dri/target.c, xa/target.c, xvmc/target.c, vdpau/target.c, and omx/target.c become quite dummy and redundant. Do you see a way to get rid of targets entirely? Indeed if/when an API comes around these targets may become redundant. Well, with inline_drm_helper.h and the like, there is already basically nothing in those target.c. I do not even get why we need those #include's in them :) As things are right now, for most state trackers (dri, gbm, omx, vdpau, xa, and xvmc), there is a matching target, and the only things in the target are rules to build it. I am not suggesting you should update the series to kill the targets. As I said, I believe it takes a lot of time to get things to where they are now, and I am fine to see any of this resolved later. Cheers, I just wanted to have a clear picture what you have in mind before I start working on it. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 12/06/14 20:56, 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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. The former method has been used by the egl-static while the latter by opencl and gbm targets since they were introduced. By default we build with static pipe-drivers. Some numbers + extra info [1] [Static] dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB [Shared] Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB [Current] dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB The previous series can be found here [2] Changes since then - Convert targets individually. - OMX targets now work, and the final library is now libomx-mesa.so - Dropped the DRI targets for now - A handfull of typos thinkos and bugs fixed. My plan is to have these pushed in ~4 stages, with two stages per week. This way I will be able to crack on with the remaining bits and have all of it tested well before we branch the next release. Gents, In case I was not clear enough - my plan is to push 01-11 (prep work) - this wednesday(tomorrow) 12-16 (vdpau, xvmc)- over the weekend 17-23 (omx, cleanup)- mid next week 24-26 (xa, gbm, egl)- next week's weekend Don't be shy to speak up, if you feel that any of the above sounds unreasonable. Feel free to shout at me as soon as you notice any bugs :) -Emil Series is availabe at https://github.com/evelikov/Mesa/tree/static-or-shared-pipe-drivers As always comments and suggestions are greatly appreciated. Cheers, -Emil [1] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059806.html [2] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059628.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov emil.l.veli...@gmail.com 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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. Given that this is an unstable API, how do you handle versioning? What will happen when people (invariably) mix match? The former method has been used by the egl-static while the latter by opencl and gbm targets since they were introduced. By default we build with static pipe-drivers. Some numbers + extra info [1] [Static] dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB [Shared] Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB [Current] dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB The previous series can be found here [2] Changes since then - Convert targets individually. - OMX targets now work, and the final library is now libomx-mesa.so - Dropped the DRI targets for now - A handfull of typos thinkos and bugs fixed. My plan is to have these pushed in ~4 stages, with two stages per week. This way I will be able to crack on with the remaining bits and have all of it tested well before we branch the next release. Series is availabe at https://github.com/evelikov/Mesa/tree/static-or-shared-pipe-drivers As always comments and suggestions are greatly appreciated. Cheers, -Emil [1] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059806.html [2] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059628.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 17/06/14 19:39, Ilia Mirkin wrote: On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov emil.l.veli...@gmail.com 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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. Given that this is an unstable API, how do you handle versioning? What will happen when people (invariably) mix match? Thanks for asking. Perhaps I should mention here as well that the xa, gbm and opencl targets currently use it. This series converts the former to to static by default. If one wants to use shared pipe-drivers they need to edit the configure script :) Once all the mayhem is done, a few explicit notes will be added to the documentation/release notes. About mix and match: The api has not changed since the addition of configuration function (commit ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit 317be33d732 ~2011). Not sure about future changes though. The series will make things that are already broken more obvious, rather than introducing the issue. (Hope that explanation was not too much). In short: Some targets are already fragile, this series makes things safer by default and provides a big hidden hammer for people that (think they) know what they are doing. -Emil The former method has been used by the egl-static while the latter by opencl and gbm targets since they were introduced. By default we build with static pipe-drivers. Some numbers + extra info [1] [Static] dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB [Shared] Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB [Current] dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB The previous series can be found here [2] Changes since then - Convert targets individually. - OMX targets now work, and the final library is now libomx-mesa.so - Dropped the DRI targets for now - A handfull of typos thinkos and bugs fixed. My plan is to have these pushed in ~4 stages, with two stages per week. This way I will be able to crack on with the remaining bits and have all of it tested well before we branch the next release. Series is availabe at https://github.com/evelikov/Mesa/tree/static-or-shared-pipe-drivers As always comments and suggestions are greatly appreciated. Cheers, -Emil [1] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059806.html [2] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059628.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 17/06/14 19:39, Ilia Mirkin wrote: On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov emil.l.veli...@gmail.com 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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. Given that this is an unstable API, how do you handle versioning? What will happen when people (invariably) mix match? Thanks for asking. Perhaps I should mention here as well that the xa, gbm and opencl targets currently use it. This series converts the former to to static by default. If one wants to use shared pipe-drivers they need to edit the configure script :) Once all the mayhem is done, a few explicit notes will be added to the documentation/release notes. About mix and match: The api has not changed since the addition of configuration function (commit ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit 317be33d732 ~2011). Not sure about future changes though. The series will make things that are already broken more obvious, rather than introducing the issue. Well, the API is not just the list of functions, but also how they're used and what their arguments mean. For example I recently introduced pipe_context-clear_buffer, which in turn would have shifted a bunch of functions down. A state tracker with one idea of pipe_context layout and a driver with a different idea would lead to a general lack of happiness. I'm sure there are other similar situatoins. (Or perhaps I'm misunderstanding the level at which these things are split up.) I guess what I was alluding to in a passive-aggressive way was that versioning should be handled... somehow. Not sure if versions have to be numeric, but if not, throwing the git commit into the SONAME would suffice, for example. I'm just concerned this will lead to very strange issues that will be difficult to diagnose. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 17/06/14 20:25, Ilia Mirkin wrote: On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 17/06/14 19:39, Ilia Mirkin wrote: On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov emil.l.veli...@gmail.com 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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. Given that this is an unstable API, how do you handle versioning? What will happen when people (invariably) mix match? Thanks for asking. Perhaps I should mention here as well that the xa, gbm and opencl targets currently use it. This series converts the former to to static by default. If one wants to use shared pipe-drivers they need to edit the configure script :) Once all the mayhem is done, a few explicit notes will be added to the documentation/release notes. About mix and match: The api has not changed since the addition of configuration function (commit ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit 317be33d732 ~2011). Not sure about future changes though. The series will make things that are already broken more obvious, rather than introducing the issue. Well, the API is not just the list of functions, but also how they're used and what their arguments mean. For example I recently introduced pipe_context-clear_buffer, which in turn would have shifted a bunch of functions down. A state tracker with one idea of pipe_context layout and a driver with a different idea would lead to a general lack of happiness. I'm sure there are other similar situatoins. (Or perhaps I'm misunderstanding the level at which these things are split up.) I guess what I was alluding to in a passive-aggressive way was that versioning should be handled... somehow. Not sure if versions have to be numeric, but if not, throwing the git commit into the SONAME would suffice, for example. How do you propose we retrofit the existing problem that xa, gbm and opencl expose ? Perhaps I should re-iterate - by default I'm removing the issue. People that know what they are doing (manually edit configure.ac) get to pick the pieces themselves. I'm just concerned this will lead to very strange issues that will be difficult to diagnose. Simple idea that just came to mind: add a compile + runtime note: You're using an unstable and unsupported... when the pipe-drivers are used. IMHO you're worrying too much, considering the current users and the number of issues that is has caused so far. Or can it be that I'm overly optimistic ? Either way the above suggestion (apart from the force static code in configure, and don't do it documentation) sounds reasonable imho. -Emil -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On Tue, Jun 17, 2014 at 4:25 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 17/06/14 20:25, Ilia Mirkin wrote: On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 17/06/14 19:39, Ilia Mirkin wrote: On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov emil.l.veli...@gmail.com 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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. Given that this is an unstable API, how do you handle versioning? What will happen when people (invariably) mix match? Thanks for asking. Perhaps I should mention here as well that the xa, gbm and opencl targets currently use it. This series converts the former to to static by default. If one wants to use shared pipe-drivers they need to edit the configure script :) Once all the mayhem is done, a few explicit notes will be added to the documentation/release notes. About mix and match: The api has not changed since the addition of configuration function (commit ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit 317be33d732 ~2011). Not sure about future changes though. The series will make things that are already broken more obvious, rather than introducing the issue. Well, the API is not just the list of functions, but also how they're used and what their arguments mean. For example I recently introduced pipe_context-clear_buffer, which in turn would have shifted a bunch of functions down. A state tracker with one idea of pipe_context layout and a driver with a different idea would lead to a general lack of happiness. I'm sure there are other similar situatoins. (Or perhaps I'm misunderstanding the level at which these things are split up.) I guess what I was alluding to in a passive-aggressive way was that versioning should be handled... somehow. Not sure if versions have to be numeric, but if not, throwing the git commit into the SONAME would suffice, for example. How do you propose we retrofit the existing problem that xa, gbm and opencl expose ? ~nobody uses those, in comparison to the number of people who use GL. And just because they were doing it badly before doesn't mean that you should keep doing the bad thing :) Perhaps I should re-iterate - by default I'm removing the issue. People that know what they are doing (manually edit configure.ac) get to pick the pieces themselves. Oh. I thought it was a --enable-foo option. If you have to manually go around messing with stuff just to get to it, fine. I'm just concerned this will lead to very strange issues that will be difficult to diagnose. Simple idea that just came to mind: add a compile + runtime note: You're using an unstable and unsupported... when the pipe-drivers are used. IMHO you're worrying too much, considering the current users and the number of issues that is has caused so far. Or can it be that I'm overly optimistic ? Either way the above suggestion (apart from the force static code in configure, and don't do it documentation) sounds reasonable imho. Agreed. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
Sorry if this is a stupid question, but are you only talking about gallium-gbm? What is the purpose of the gbm state tracker and how is it different from the default one in src/gbm? Thanks, Marek On Tue, Jun 17, 2014 at 10:25 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 17/06/14 20:25, Ilia Mirkin wrote: On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 17/06/14 19:39, Ilia Mirkin wrote: On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov emil.l.veli...@gmail.com 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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. Given that this is an unstable API, how do you handle versioning? What will happen when people (invariably) mix match? Thanks for asking. Perhaps I should mention here as well that the xa, gbm and opencl targets currently use it. This series converts the former to to static by default. If one wants to use shared pipe-drivers they need to edit the configure script :) Once all the mayhem is done, a few explicit notes will be added to the documentation/release notes. About mix and match: The api has not changed since the addition of configuration function (commit ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit 317be33d732 ~2011). Not sure about future changes though. The series will make things that are already broken more obvious, rather than introducing the issue. Well, the API is not just the list of functions, but also how they're used and what their arguments mean. For example I recently introduced pipe_context-clear_buffer, which in turn would have shifted a bunch of functions down. A state tracker with one idea of pipe_context layout and a driver with a different idea would lead to a general lack of happiness. I'm sure there are other similar situatoins. (Or perhaps I'm misunderstanding the level at which these things are split up.) I guess what I was alluding to in a passive-aggressive way was that versioning should be handled... somehow. Not sure if versions have to be numeric, but if not, throwing the git commit into the SONAME would suffice, for example. How do you propose we retrofit the existing problem that xa, gbm and opencl expose ? Perhaps I should re-iterate - by default I'm removing the issue. People that know what they are doing (manually edit configure.ac) get to pick the pieces themselves. I'm just concerned this will lead to very strange issues that will be difficult to diagnose. Simple idea that just came to mind: add a compile + runtime note: You're using an unstable and unsupported... when the pipe-drivers are used. IMHO you're worrying too much, considering the current users and the number of issues that is has caused so far. Or can it be that I'm overly optimistic ? Either way the above suggestion (apart from the force static code in configure, and don't do it documentation) sounds reasonable imho. -Emil -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 17/06/14 21:30, Marek Olšák wrote:
Sorry if this is a stupid question, but are you only talking about
gallium-gbm? What is the purpose of the gbm state tracker and how is
it different from the default one in src/gbm?
The whole of these series (in the various forms that have been on the list)
target exclusively the gallium targets.
Don't ask me about specifics but the overall picture is:
There are a couple of loaders (src/egl and src/gbm) each of which has two
_backends_ - dri (src/{egl,gbm}/backends/dri) and gallium
(src/gallium/statetracker). The former works with the *_dri.so modules while
the latter strips down layers of abstractions we have and works directly with
gallium. The dri backends are built into their loaders, while the gallium ones
are separate modules.
One can use egl_dri + gbm_dri or gallium_egl + gallium_gbm.
Would you feel like chipping in and/or testing the radeon patches ?
Emil
Thanks,
Marek
On Tue, Jun 17, 2014 at 10:25 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 17/06/14 20:25, Ilia Mirkin wrote:
On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 17/06/14 19:39, Ilia Mirkin wrote:
On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov emil.l.veli...@gmail.com
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.
This allows us to have substantial space savings as the
API(state-tracker)
is available only once. Additionally it adds support for shared
pipe-drivers via a _unstable_ interface, which saves us the duplication
across X APIs.
Given that this is an unstable API, how do you handle versioning? What
will happen when people (invariably) mix match?
Thanks for asking.
Perhaps I should mention here as well that the xa, gbm and opencl targets
currently use it. This series converts the former to to static by
default.
If one wants to use shared pipe-drivers they need to edit the configure
script :)
Once all the mayhem is done, a few explicit notes will be added to the
documentation/release notes.
About mix and match:
The api has not changed since the addition of configuration function
(commit
ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit 317be33d732
~2011). Not sure about future changes though.
The series will make things that are already broken more obvious, rather
than
introducing the issue.
Well, the API is not just the list of functions, but also how they're
used and what their arguments mean. For example I recently introduced
pipe_context-clear_buffer, which in turn would have shifted a bunch
of functions down. A state tracker with one idea of pipe_context
layout and a driver with a different idea would lead to a general lack
of happiness. I'm sure there are other similar situatoins. (Or perhaps
I'm misunderstanding the level at which these things are split up.)
I guess what I was alluding to in a passive-aggressive way was that
versioning should be handled... somehow. Not sure if versions have to
be numeric, but if not, throwing the git commit into the SONAME would
suffice, for example.
How do you propose we retrofit the existing problem that xa, gbm and opencl
expose ?
Perhaps I should re-iterate - by default I'm removing the issue. People that
know what they are doing (manually edit configure.ac) get to pick the pieces
themselves.
I'm just concerned this will lead to very strange issues that will be
difficult to diagnose.
Simple idea that just came to mind: add a compile + runtime note: You're
using an unstable and unsupported... when the pipe-drivers are used.
IMHO you're worrying too much, considering the current users and the number
of
issues that is has caused so far. Or can it be that I'm overly optimistic ?
Either way the above suggestion (apart from the force static code in
configure, and don't do it documentation) sounds reasonable imho.
-Emil
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
Sure. Can you give me a git link and a branch name?
Marek
On Tue, Jun 17, 2014 at 11:06 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 17/06/14 21:30, Marek Olšák wrote:
Sorry if this is a stupid question, but are you only talking about
gallium-gbm? What is the purpose of the gbm state tracker and how is
it different from the default one in src/gbm?
The whole of these series (in the various forms that have been on the list)
target exclusively the gallium targets.
Don't ask me about specifics but the overall picture is:
There are a couple of loaders (src/egl and src/gbm) each of which has two
_backends_ - dri (src/{egl,gbm}/backends/dri) and gallium
(src/gallium/statetracker). The former works with the *_dri.so modules while
the latter strips down layers of abstractions we have and works directly with
gallium. The dri backends are built into their loaders, while the gallium ones
are separate modules.
One can use egl_dri + gbm_dri or gallium_egl + gallium_gbm.
Would you feel like chipping in and/or testing the radeon patches ?
Emil
Thanks,
Marek
On Tue, Jun 17, 2014 at 10:25 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 17/06/14 20:25, Ilia Mirkin wrote:
On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 17/06/14 19:39, Ilia Mirkin wrote:
On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov emil.l.veli...@gmail.com
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.
This allows us to have substantial space savings as the
API(state-tracker)
is available only once. Additionally it adds support for shared
pipe-drivers via a _unstable_ interface, which saves us the duplication
across X APIs.
Given that this is an unstable API, how do you handle versioning? What
will happen when people (invariably) mix match?
Thanks for asking.
Perhaps I should mention here as well that the xa, gbm and opencl targets
currently use it. This series converts the former to to static by
default.
If one wants to use shared pipe-drivers they need to edit the configure
script :)
Once all the mayhem is done, a few explicit notes will be added to the
documentation/release notes.
About mix and match:
The api has not changed since the addition of configuration function
(commit
ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit 317be33d732
~2011). Not sure about future changes though.
The series will make things that are already broken more obvious, rather
than
introducing the issue.
Well, the API is not just the list of functions, but also how they're
used and what their arguments mean. For example I recently introduced
pipe_context-clear_buffer, which in turn would have shifted a bunch
of functions down. A state tracker with one idea of pipe_context
layout and a driver with a different idea would lead to a general lack
of happiness. I'm sure there are other similar situatoins. (Or perhaps
I'm misunderstanding the level at which these things are split up.)
I guess what I was alluding to in a passive-aggressive way was that
versioning should be handled... somehow. Not sure if versions have to
be numeric, but if not, throwing the git commit into the SONAME would
suffice, for example.
How do you propose we retrofit the existing problem that xa, gbm and opencl
expose ?
Perhaps I should re-iterate - by default I'm removing the issue. People that
know what they are doing (manually edit configure.ac) get to pick the pieces
themselves.
I'm just concerned this will lead to very strange issues that will be
difficult to diagnose.
Simple idea that just came to mind: add a compile + runtime note: You're
using an unstable and unsupported... when the pipe-drivers are used.
IMHO you're worrying too much, considering the current users and the number
of
issues that is has caused so far. Or can it be that I'm overly optimistic ?
Either way the above suggestion (apart from the force static code in
configure, and don't do it documentation) sounds reasonable imho.
-Emil
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
On 17/06/14 22:09, Marek Olšák wrote:
Sure. Can you give me a git link and a branch name?
Great, branch static-or-shared-pipe-drivers-v2 at
https://github.com/evelikov/Mesa/
Thanks
Emil
Marek
On Tue, Jun 17, 2014 at 11:06 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 17/06/14 21:30, Marek Olšák wrote:
Sorry if this is a stupid question, but are you only talking about
gallium-gbm? What is the purpose of the gbm state tracker and how is
it different from the default one in src/gbm?
The whole of these series (in the various forms that have been on the list)
target exclusively the gallium targets.
Don't ask me about specifics but the overall picture is:
There are a couple of loaders (src/egl and src/gbm) each of which has two
_backends_ - dri (src/{egl,gbm}/backends/dri) and gallium
(src/gallium/statetracker). The former works with the *_dri.so modules while
the latter strips down layers of abstractions we have and works directly with
gallium. The dri backends are built into their loaders, while the gallium
ones
are separate modules.
One can use egl_dri + gbm_dri or gallium_egl + gallium_gbm.
Would you feel like chipping in and/or testing the radeon patches ?
Emil
Thanks,
Marek
On Tue, Jun 17, 2014 at 10:25 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 17/06/14 20:25, Ilia Mirkin wrote:
On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 17/06/14 19:39, Ilia Mirkin wrote:
On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov
emil.l.veli...@gmail.com 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.
This allows us to have substantial space savings as the
API(state-tracker)
is available only once. Additionally it adds support for shared
pipe-drivers via a _unstable_ interface, which saves us the duplication
across X APIs.
Given that this is an unstable API, how do you handle versioning? What
will happen when people (invariably) mix match?
Thanks for asking.
Perhaps I should mention here as well that the xa, gbm and opencl targets
currently use it. This series converts the former to to static by
default.
If one wants to use shared pipe-drivers they need to edit the configure
script :)
Once all the mayhem is done, a few explicit notes will be added to the
documentation/release notes.
About mix and match:
The api has not changed since the addition of configuration function
(commit
ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit
317be33d732
~2011). Not sure about future changes though.
The series will make things that are already broken more obvious, rather
than
introducing the issue.
Well, the API is not just the list of functions, but also how they're
used and what their arguments mean. For example I recently introduced
pipe_context-clear_buffer, which in turn would have shifted a bunch
of functions down. A state tracker with one idea of pipe_context
layout and a driver with a different idea would lead to a general lack
of happiness. I'm sure there are other similar situatoins. (Or perhaps
I'm misunderstanding the level at which these things are split up.)
I guess what I was alluding to in a passive-aggressive way was that
versioning should be handled... somehow. Not sure if versions have to
be numeric, but if not, throwing the git commit into the SONAME would
suffice, for example.
How do you propose we retrofit the existing problem that xa, gbm and opencl
expose ?
Perhaps I should re-iterate - by default I'm removing the issue. People
that
know what they are doing (manually edit configure.ac) get to pick the
pieces
themselves.
I'm just concerned this will lead to very strange issues that will be
difficult to diagnose.
Simple idea that just came to mind: add a compile + runtime note: You're
using an unstable and unsupported... when the pipe-drivers are used.
IMHO you're worrying too much, considering the current users and the
number of
issues that is has caused so far. Or can it be that I'm overly optimistic ?
Either way the above suggestion (apart from the force static code in
configure, and don't do it documentation) sounds reasonable imho.
-Emil
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
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. This allows us to have substantial space savings as the API(state-tracker) is available only once. Additionally it adds support for shared pipe-drivers via a _unstable_ interface, which saves us the duplication across X APIs. The former method has been used by the egl-static while the latter by opencl and gbm targets since they were introduced. By default we build with static pipe-drivers. Some numbers + extra info [1] [Static] dri:(r600|radeonsi|nouveau)_dri.so - 6.5 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 3.5 MiB Total: 10MiB [Shared] Libraries: dri:(r600|radeonsi|nouveau)_dri.so - 3.9 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 633 KiB gallium-pipe: pipe_(r600|radeonsi|nouveau).so - 5.3 MiB Total: 9.8MiB [Current] dri:(r600|radeonsi|nouveau)_dri.so - 5.0+4.5+5.3 = 14.8 MiB vdpau: libvdpau_(r600|radeonsi|nouveau).so - 1.9+1.2+2.3 = 5.4 MiB Total: 20.2MiB The previous series can be found here [2] Changes since then - Convert targets individually. - OMX targets now work, and the final library is now libomx-mesa.so - Dropped the DRI targets for now - A handfull of typos thinkos and bugs fixed. My plan is to have these pushed in ~4 stages, with two stages per week. This way I will be able to crack on with the remaining bits and have all of it tested well before we branch the next release. Series is availabe at https://github.com/evelikov/Mesa/tree/static-or-shared-pipe-drivers As always comments and suggestions are greatly appreciated. Cheers, -Emil [1] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059806.html [2] http://lists.freedesktop.org/archives/mesa-dev/2014-May/059628.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
