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

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

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