[Mesa3d-dev] DRI SDK and modularized drivers.
libv at skynet.be
Sun Mar 21 18:37:02 PDT 2010
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".
More information about the xorg