On Mon, Mar 14, 2011 at 2:18 PM, José Fonseca <jfons...@vmware.com> wrote: > On Mon, 2011-03-14 at 10:06 -0700, Matt Turner wrote: >> On Mon, Mar 14, 2011 at 4:52 PM, José Fonseca <jfons...@vmware.com> wrote: >> > If we want a cleaner / more agile code base, then we could fork off the >> > old mesa drivers which aren't being actively maintained/tested into a >> > separate branch, put them in just-bugfixes/no-new-features life support >> > mode; therefore allowing greater freedom to refactor support for the >> > active/maintained drivers, without the hassle of updating old drivers >> > and its associated risks. >> >> What drivers are you talking about? > > I'm talking about drivers that: > - have no fragment shader > - haven't active maintainers > > Perhaps these: > > dri/tdfx > dri/mga > dri/i810 > dri/sis > dri/unichrome > dri/mach64 > dri/r128 > dri/r200 > dri/savage > windows/icd > windows/gldirect > windows/gldirect/mesasw > windows/gldirect/dx9 > windows/gldirect/dx7 > windows/gldirect/dx8 > windows/gdi > windows/fx > > I'm not sure about the status of these: > - dri/radeon > - dri/nouveau >
dri/r200 and dri/radeon are more or less maintained, but modulo some bugs, they are feature complete, so there's not much more to do. As you suggest a time-vault might be a good idea for these old chips. We basically just want to keep them working with minimal effort. Alex >> A quick glance tells me that old drivers like tdfx and savage were >> only modified 7 and 8 times respectively in 2010, so I don't see old >> drivers slowing any development down. > > I see that as a clear indicative of trouble: > - probably nobody is testing those drivers as we change Mesa common code > - we can't remove old features from Mesa DDI because those drivers need > it > >> What would splitting these drivers out of the Mesa codebase allow? >> Intel's still using the classic infrastructure, so. > > Suppose we want to: > - eliminate fixed function from Mesa DDI > - replace Mesa IR and TGSI from Mesa classic driver interface and > Gallium respectively, with GLSL2 IR. > > Is there point in writing a reverse shader -> fixed function for older > drivers, or rewrite the shader translations for those drivers? > > Basically, I'm arguing that support for old fashioned hardware be done > in a separate tree, that acts as a time vault. > > I think it is a disservice both for developers and users trying to cover > for so many generations of hardware, some very different from anothers, > in a single source tree. > > > This is a mere suggestion -- I think we could continue the current > approach of adding layers (some very old, others newer, with some doing > the translation in between) indefinitely -- I'm simply arguing that it > would be probably easier if we could shed out some of the legacy stuff > and keep the code a bit leaner. > > > Jose > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
