On 18/06/14 15:07, Chia-I Wu wrote: > On Wed, Jun 18, 2014 at 8:14 PM, Emil Velikov <emil.l.veli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
