On 21/05/14 00:32, Marek Olšák wrote:
> Thanks, that makes sense. I think the static approach is better, but I
> don't have a strong opinion about that.
>
> Did you also consider merging the API libraries?
>
> For DRI, we need to export __driDriverExtensions.
> For VDPAU, we need to export vdp_imp_device_create_x11.
> Etc.
>
+ $hw_winsys_screen_create for vdpau-gl interop.
Thanks for the reminder of the exported symbol hunt. I will still need to case
people in order to get the final patches reviewed :\
> However, having a single blob for multiple APIs should work, right?
>
In theory - it should work, in practise - never tried. Not at all keen on the
idea though:
- No benefit wrt the space saved (compared to shared/pipe-loader).
- Pulling more lib deps into the dri modules. Currently we're linking against
libgcc_s and libstdc++ which is causing enough issues as some people ship
their own version of the libraries. Adding X11/xcb lib deps will make things
even worse.
AFAICS the proprietary drivers fix this by static linking although every
reference I have seen says that it's a bad idea, with little to no
justification.
Note: I'm not saying that shipping the above libraries is a bad idea when
distributing binaries, but it's _slightly_ annoying for users.
-Emil
> Marek
>
> On Tue, May 20, 2014 at 10:04 PM, Emil Velikov <emil.l.veli...@gmail.com>
> wrote:
>> On 20/05/14 16:21, Marek Olšák wrote:
>>> Well, I have never studied the build system, so I don't know exactly
>>> what this series does and how it affects the size of the drivers.
>>>
>>> Could you please summarize what binaries are created, how big they
>>> are, and compare the shared vs static approach vs the current way? And
>>> what is the role of the pipe loader?
>>>
>> Seems like I jumped into too many presumptions in the introductory email :\
>>
>> Pipe-driver - gallium/drivers/$hw and its respective winsys built into a
>> standalone loadable module. Installed as
>> gallium-pipe/pipe_(r600|radeonsi|nouveau).so
>>
>> Pipe-loader - aux module (linked into the final library) that loads the
>> appropriate pipe-driver.
>>
>> Static("megadriver") - identical to what you did with megaradeon. All the
>> drivers selected at configure are linked into the same blob.
>> Hardlink for each target for compatibility reasons.
>>
>> Libraries:
>> dri: (r600|radeonsi|nouveau)_dri.so -> 6.5 MiB
>> vdpau: libvdpau_(r600|radeonsi|nouveau).so -> 3.5 MiB
>>
>> Total: 10MiB
>>
>> Shared("pipe-loader") - create individual pipe-drivers and standalone
>> state-tracker libraries (think of them as bla_dri + libGL). The pipe-driver
>> is
>> used by all ST. Note: the interface is not stable, unlike the dri modules.
>> Hardlink for each target for compatibility reasons.
>>
>> Libraries:
>> dri: (r600|radeonsi|nouveau)_dri.so -> 3.9 MiB
>> vdpau: libvdpau_(r600|radeonsi|nouveau).so -> 633 KiB
>> gallium-pipe: pipe_(r600|radeonsi|nouveau).so -> 5.3 MiB
>>
>> Total: 9.8MiB
>>
>> Current approach - at final link time, most state-trackers pull the
>> gallium/drivers/$hw, via the above mentioned DRM_DESCRIPTOR, to create a
>> independent HW specific library. Resulting in some duplication.
>>
>> dri: (r600|radeonsi|nouveau)_dri.so -> 5.0+4.5+5.3 = 14.8
>> MiB
>> vdpau: libvdpau_(r600|radeonsi|nouveau).so -> 1.9+1.2+2.3 = 5.4 MiB
>>
>> Total: 20.2MiB
>>
>> Note: currently egl-static and opencl are hardcoded to static and shared
>> respectively. Both of which are will be converted with the next series.
>>
>>
>> Summary:
>> Static - savings scale with number of hardware (gallium/drivers).
>> Shared - savings scale with number of state-trackers (gallium/state-tracker).
>>
>>
>> -Emil
>>
>>> Marek
>>>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
