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. >> Right now I'm not packaging vdpau in ubuntu because of the extra disk >> space involved. >> Not everyone can download packages with 10 mbit connections. >> >> I really dislike building libgallium shared, so getting rid of that >> hack while keeping the size reduction is great. :-) >> > > Yeah, agree. > Seconded >> 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. 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
