[Mesa-dev] [RFC] pipe-loader: abstract GALLIUM_STATIC_TARGETS behind pipe_loader API

[Rob Clark]

On Thu, Oct 1, 2015 at 10:30 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi Rob,
>
> I believe that Marek managed to nicely explain how things work.
> Ideally you'll be able to get on the same boat (i.e. the Android C
> runtime/linker won't give you the finger). Regardless some comments
> inline.
>
> On 30 September 2015 at 21:43, Rob Clark <robdclark at gmail.com> wrote:
>> From: Rob Clark <robclark at freedesktop.org>
>>
>> Not actually working yet, ie. doesn't even compile yet, but an idea.
>>
>> Initial motivation was for drm_gralloc/pipe, which is essentially a sort
>> of mini state-tracker, that needs to be able to share pipe_screen with
>> libGL linked into the same process (to ensure we didn't end up with
>> duplicate pipe_resource's, etc).  I think same situation happens with
>> vdpau+gl interop.
>>
>> Currently drm_gralloc/pipe (and other state trackers??) statically link
>> the winsys code, which completely defeats the purpose magic in the
>> winsys code to detect when the same device is opened multiple times and
>> return the same pipe_screen (since you end up w/ multiple copies of the
>> hashtable in the same process).  See for example:
>>
>>   5bb41d9094b3c9bdf0669fd55418981ed83347e3
>>   fee0686c21c631d96d6042741267a3c218c23ffc
>>
>> Rough idea is that we should have something like libgallium.so which
>> contains the pipe-loader API, and then optionally (depending on
>> GALLIUM_STATIC_TARGETS) all of the gallium pipe drivers.  The various
>> different state trackers would link against (or dlopen()) libgallium.so
>> and use the pipe-loader API to get themselves a pipe_screen (and config
>> params, etc).  And then you end up with:
>>
>>                 +---+
>>                 | l |
>>     clover  --> | i |
>>                 | b |
>>     mesa-st --> | g |
>>                 | a |--> pipe driver
>>     vdapau  --> | l |
>>                 | l |
>>     gralloc --> | i |
>>                 | u |
>>     xa      --> | m |
>>                 |   |
>>                 +---+
>> or:
>>                 +---+-------------+
>>                 | l |             |
>>     clover  --> | i |             |
>>                 | b |             |
>>     mesa-st --> | g |             |
>>                 | a | pipe driver |
>>     vdapau  --> | l |             |
>>                 | l |             |
>>     gralloc --> | i |             |
>>                 | u |             |
>>     xa      --> | m |             |
>>                 |   |             |
>>                 +---+-------------+
>>
>> depending on GALLIUM_STATIC_TARGETS.  Either way, all the state trackers
>> in the same process share a single copy of the hashtable in the winsys
>> code which allows them to share the same pipe_screen.
>>
> As others I'm not too excited about adding new library/ies. Amongst
> others, It boils down to people mix'n'matching things, causing all
> sorts of problems.

hmm, sounds like a distro issue, doesn't it?  I mean in
non-GALLIUM_STATIC_TARGETS build configuration (which, afaict doesn't
even work these days) you couldn't mix and match state tracker .so's
and pipe-driver .so's..

If really needed we could stuff module version symbols all around and
refuse to load with nice error msg if mismatch..  seems like a
relatively solvable problem..

>> I think that ends up being an extra level of library indirection vs
>> current state w/ pipe drivers, ie. with mesa dri loader stuff directly
>> loading gallium_dri.so which contains all the drivers plus mesa state
>> tracker.  If this was concerning to someone, what I'd suggest would be
>> to, for all the state trackers that already have some sort of loader
>> sitting between them and the user, just pull them directly into the
>> mega-mega libgallium.so, ie. something like:
>>
>>       +---------+---+-------------+
>>       |         |   |             |
>>       | clover  | l |             |
>>       |         | i |             |
>>       | mesa-st | b |             |
>>       |         | g | pipe driver |
>>       | vdapau  | a |             |
>>       |         | l |             |
>>       +---------| l |             |
>>                 | i |             |
>>     gralloc --> | u |             |
>>                 | m |             |
>>     xa      --> |   |             |
>>                 |   |             |
>>                 +---+-------------+
>>
> This won't work due to funny dependencies. I.e. you don't want to
> force xcb and friends onto the dri module, clover etc, just because
> vdpau needs it.

Hmm, perhaps.. although I thought dri already was converted to use
xcb..  otherwise I'd guess vdpau and mesa-st would have roughly the
same sorts of dependencies.  Although perhaps it would be funny for
clover to have those dep's..


>> Anyways, I'm far from an expert in the build architecture of things so
>> I might have some facts wrong or be a bit confused.  And I'll probably
>> regret bringing the subject up.  But somehow or another it seems like
>> it would be good to (a) clean up all the GALLIUM_STATIC_TARGETS
>> ifdeffery spread throughout all the different state trackers,
> Sure that's always great, yet it is somewhat orthogonal to the
> original issue ;-)

original issue grew as I realized the problems with which .so ended up
with which code ;-)

it started out as trying to come up with a cleaner version of
https://github.com/freedreno/mesa/commit/1dabf1f20dc6644892e06dd1458983f2b50850bb

And it seemed like pipe-loader would be a better place for it to live.
(Then I realized pipe_loader_drm.c didn't actually seem to get built
anywhere anymore and so I figured if I was going to get into build
system hell, I might as well consider how this should actually look..
and having pipe driver + winsys only once per process regardless of #
of state trackers used seemed like a clean solution..)

I guess I could do the simpler point-solution of not really changing
the library structure, but just doing the pipe-loader refactor.  Then
drm_gralloc could dlopen() gallium_dri.so and coexist peacefully w/
GL..  doesn't really help if some day down the road someone wanted to
use clover or omx state trackers (renderscript st anyone?  :-P).
Maybe the easy thing would be to give libdrm a simple device->void*
cache thing so we can push the hashtable into libdrm..


>> and (b)
>> have the pipe driver[*] only exist once per process rather than once per
>> state-tracker.  Especially for android where each process using GL will
>> have both gralloc and mesa-st.. and perhaps even clover/omx/etc.
>>
> Speaking of Android, have you tried the dynamic-list approach ?

I did try it, and couldn't seem to get it working..  I guess it was
possible that I bodged up the android makefiles or something didn't
rebuild properly... I did eventually figured out that modifying
Android.mk's doesn't actually trigger anything to recompile :-/

otoh hand, I don't feel so trusting of that bionic stuff, so even it
if worked today will it break in next android release?  I'm not sure
how well advanced fancy linker features that no one else uses get
tested..

BR,
-R

> Thanks
> Emil