On Fri, Mar 19, 2010 at 12:44:39PM -0500, Bridgman, John wrote: > Pulling drm back out of the kernel tree seems like a hard sell, but the > ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for > grouping. > > I guess the core question is whether we expect the X-to-ddx and > mesa-to-hw-driver interfaces to be more or less volatile than the > ddx-to-libdrm and mesa-hw-driver-to-libdrm interfaces over the next couple of > years. > > On the core-to-driver interface side we have the Gallium3D and GL 3/4 work, > and on the libdrm interface side we have ongoing improvements in memory > management and command submission. Tough call. > > I guess another option would be a "pseudo-modular" approach where the code > stays in the current trees but we adopt versioning and build/test procedures > which treat ddx/mesahw/libdrm as a single code base even if the code is still > living in multiple projects. That might be an easy first step, but > repartitioning the code does seem like a better long-term approach. > > If the drm code were omitted from the proposal and we focused only on > ddx/libdrm/mesahw would that help ?
Well, to continue down the same path: It doesn't really matter how driver developers want to scatter their own different driver bits around today. It should be up to them. It shouldn't matter, but sadly it does (as you're forced to have them into the main trees). If those developers are free to choose how they want to handle this, then it will quickly become clear for some what the best mode of working for them really is, as opposed to being forced to work one way. Then there will be pressure from users, hw and distro vendors, who might like one or another way of working better. And i guess that this is what those reasoning against this are mostly afraid of. Ideas like this can no longer be swept under the carpet with "impossible". Luc Verhaegen. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
