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 <robdcl...@gmail.com> wrote: > From: Rob Clark <robcl...@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. > 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. > 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 ;-) > 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 ? Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
