Am 13.02.2014 13:20, schrieb Emil Velikov:
On 13/02/14 11:48, Christian König wrote:
Am 13.02.2014 12:28, schrieb Maarten Lankhorst:
op 11-02-14 11:30, Christian König schreef:
Am 11.02.2014 05:26, schrieb Emil Velikov:
Hello list,
The recent patches from Rob gave me a nice kick to give another stab at
integrating the pipe-loader into the vdpau/dri targets.
What:
- With these patches one library will be created for hardware and
one for
software driven backends - eg. libvdpau_gallium_dri,
libvdpau_gallium_sw
Just drop, the software driven backends. I was about to remove them
anyway.
- Each library can use every possible pipe driver, determined at
runtime.
- To get the dri (galliumdrm_dri) or vdpau library working create
hardlink
(or symlink) to it (libvdpau_nouveau.so -> libvdpau_gallium_dri.so)
Why:
- Smaller overall size while having no extra exported symbols.
This is
a nice method of us to share most of gallium (read mesagallium and
aux/gallium) without exporting every symbol either one to those two
contain.
- Drop the multiple duplicated
- With those done, some additional symbol cleanup can be made
using the
linker. The stripped size of pipe_nouveau and pipe_swrast decreased by
~0.6MiB, downto 2.2, 1.2MiB accordingly. With similar results on other
libaries.
NAK, at least for the VDPAU drivers that doesn't sounds like such a
good idea to me.
Reducing the number of exported symbols can be archived otherwise and
giving up their self containing without any external dependencies
just to save some extra space on disk doesn't sound like a valid
reason to me.
This is a great idea. It doesn't just save diskspace, it also makes
life for packagers easier.
Please reconsider that for a moment, it means that we make the gallium
pipe screen and context a public interface of a shared library.
That means we either need to put everything into a single package, make
hard dependencies on the packages between each other or declare the pipe
interfaces as stable. Neither of those options sounds like a good idea
(ok, maybe putting everything into a single package).
Hmm the whole "declare pipe interfaces as stable" is currently implied
by it's current users - egl-static, gbm, opencl :)
But if people are not happy with that there is another solution
suggested by Jakob Bornecrantz on IRC - get all those pipe-drivers and
push them into a single blob which then we link against for each st to
create a megadriver target.
This will result in alot less space saving as the ~2MiB per driver will
be duplicated in - dri, vdpau, xvmc, younameit... but a very nice
approach to your concerns.
Yeah that sounds better, but I would still like to avoid this altogether.
Preventing symbol clashing is easy by carefully choosing which symbols
to export. And in the case of pipe-loader we would only need to export
very few, and those exports are very controlled. Even
radeon_drm_winsys_create doesn't need to be exported any more if vdpau
and dri use the same shared pipe-loader library.
Removing the unnecessary exported symbols is probably the better way to
go, the last time I checked r600 had something ~200kb of actually binary
and over 1mb of symbols.
As you've noticed I've been that path, and static linking against LLVM
gave me a subtle kick in the nuts. The day when someone fixes that with
the LLVM people I'll be a happy bunny. I'm suspecting that's the reason
for the numbers you're quoting.
Taking a closer look I would rather suspect that we have an issue with
the build system here. I've just finished building
libvdpau_radeonsi.so.1.0.0 from a complete clean checkout with the
following configure options:
./configure --with-dri-drivers= --with-gallium-drivers=radeonsi
--enable-vdpau --with-llvm-prefix=/usr/src/llvm/Debug+Asserts/
--with-llvm-shared-libs --disable-dri3 --disable-debug
The resulting binary is something like 11M in size, but applying "strip
libvdpau_radeonsi.so.1.0.0" reduces it's size to only 2.2M. Taking a
closer look it looks like even with "--disable-debug" we are building
debugging symbols into it.
That's not necessary an issue for packaging, cause distributions usually
separate the debugging symbols anyway, but it still looks odd to me.
Christian.
Btw, bringing back vdpau-softpipe was a very nice experiment to check if
I've piped all the functions correctly, than anything else.
-Emil
Christian.
~Maarten
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
