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

[Christian König]

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
>>>