[Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)

[Emil Velikov]

On 18/06/14 15:07, Chia-I Wu wrote:
> On Wed, Jun 18, 2014 at 8:14 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
[...]
>> Interesting, I do not see this as an attempt to define an API, but to
>> cleanup all the mayhem that our targets currently are:
>>  * Cleanup the build system - drop symlinks, including the same source
>> files from different locations.
>>  * Make targets less error prone by using static pipe-drivers by
>> default. Shared ones we lack versioning and ... are a big can of
>> worms.
>>  * Minimize all the target.c duplication across each target. Makefiles
>> are in similar boat.
> The reason that the state trackers can manage statically linked pipe
> drivers, or the duplications in target.c can be killed is because of
> the introduction of an API (inline_drm_helper.h), or if you prefer,
> helper functions.
> 
Seems like my definition of "API" slightly differs :)
/me drops down the EE books and picks up a CS one.

> Either way, a set of functions are defined to help manage statically
> linked pipe drivers.  State trackers tend to do
> 
> #ifdef GALLIUM_STATIC_TARGETS
> /* use inline_drm_helper.h */
> ...
> #else
> /* use pipe_loader.h */
> ...
> #endif
> 
> IMHO, we should be able to define a single API, or a single set of
> helper functions, to manage pipe drivers, no matter they are
> statically linked or dynamically loaded.  Note that
> inline_drm_helper.h is not stateless: dd_create_screen must be called
> first to initialize a static variable.  It may even be possible to
> extend pipe loader for the statically linked case.
> 
I.e. move the "static or shared pipe-drivers" decision to the pipe-loader ?
Currently we need the latter due to the opencl target, although with that
sorted it sounds doable.

>>  * Allow people to use the unstable pipe-drivers if they are really
>> short on size and know what they are doing.
>>
>>> The lack of such API previously led us to "targets", where each target
>>> knows how to load a specific driver.  With your changes, state
>>> trackers that need to work with pipe drivers have a way to do so.  As
>>> a result, files such as
>>>
>>>   dri/target.c,
>>>   xa/target.c,
>>>   xvmc/target.c,
>>>   vdpau/target.c, and
>>>   omx/target.c
>>>
>>> become quite dummy and redundant.  Do you see a way to get rid of
>>> "targets" entirely?
>>>
>> Indeed if/when an API comes around these targets may become redundant.
> Well, with inline_drm_helper.h and the like, there is already
> basically nothing in those target.c.  I do not even get why we need
> those #include's in them :)  As things are right now, for most state
> trackers (dri, gbm, omx, vdpau, xa, and xvmc), there is a matching
> target, and the only things in the target are rules to build it.
> 
> I am not suggesting you should update the series to kill the targets.
> As I said, I believe it takes a lot of time to get things to where
> they are now, and I am fine to see any of this resolved later.
> 
Cheers, I just wanted to have a clear picture what you have in mind before I
start working on it.

-Emil