On Thu, 2009-07-02 at 08:29 -0700, Jakob Bornecrantz wrote: > On 2 jul 2009, at 16.25, José Fonseca wrote: > > The trace driver integration should be done in state tracker, so > > that it > > automatically works for all existing and future pipe drivers, and not > > for individual winsyses... > > That is a valid point. > > There is the counter argument that since its the winsys that decides > the composition of the final binary it should also decide which > features to use.
I'll chime in on this: the practice of having the winsys determine the final nature of the driver is a historical oddity and not something we want to wed ourselves going forward. We've done a good job of pulling all the various roles of the winsys apart and moving them to locations which improve reuse. Currently we're down to only a couple unrelated things left in that bucket -- and one of them is this notion of the overall build target. So where should the build targets live? Wherever it is, it should be pretty minimal - no real code should be required, just a makefile with a number of targets, each of which links the components required - and possibly a single tiny .c file to glue everything together. I'd be quite happy to see a piece of shared code that was called at initialization to look at what gallium components are available, what environment variables are set, etc, and build the whole driver stack by plugging layers together in a sensible way. In terms of tracing, it may be neither the state-tracker nor the driver/winsys that should be responsible -- the trace code could be injected in a uniform way by this driver-constructor code. Keith ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
