[Mesa-dev] GSoC : Thoughts about an OpenGL 4.1 state tracker
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:
> 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.
>> 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
>> 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.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev