[Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)
emil.l.velikov at gmail.com
Wed Jun 18 11:09:44 PDT 2014
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
>> * 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 */
> /* use pipe_loader.h */
> 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
>>> vdpau/target.c, and
>>> 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.
More information about the mesa-dev