[Mesa-dev] GSoC : Thoughts about an OpenGL 4.1 state tracker

[José Fonseca]

On Mon, 2011-03-14 at 10:06 -0700, Matt Turner wrote:
> On Mon, Mar 14, 2011 at 4:52 PM, José Fonseca <jfonseca at 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

> 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