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

Alex Deucher alexdeucher at gmail.com
Mon Mar 14 11:23:50 PDT 2011


On Mon, Mar 14, 2011 at 2:18 PM, José Fonseca <jfonseca at 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 <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
>

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


More information about the mesa-dev mailing list