[Mesa-dev] Convert vdpau and dri targets to the pipe-loader

[Maarten Lankhorst]

op 13-02-14 14:14, Christian König schreef:
> 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.
I already did the megablob approach, it works but it's nasty. :-)

Disabling the megablob resulted in even bigger binaries if linking statically,
or nasty makefile hacks to handle building the !megablob case.
If we go down this path I would rather not support !megablob building any more.

>>>> 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.
--disable-debug is used by distro builds, so having the debug symbols still available is still required. I would rather have --enable-debug stop fiddling with CFLAGS, so it doesn't revert to -g -O0, that is weirder to be honest. :-)

~Maarten