[Mesa-dev] DEATH to old drivers!

[Kenneth Graunke]

On 08/25/2011 07:03 AM, Ian Romanick wrote:
> On 08/24/2011 05:07 PM, Jakob Bornecrantz wrote:
>> On Thu, Aug 25, 2011 at 1:46 AM, Ian Romanick <idr at freedesktop.org> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 08/24/2011 12:11 PM, Ian Romanick wrote:
>>>> I'd like to propose giving the ax to a bunch of old, unmaintained
>>>> drivers.  I've been doing a bunch of refactoring and reworking of core
>>>> Mesa code, and these drivers have been causing me problems for a number
>>>> of reasons.
>>>>
>>>> 1. The hardware is so old that it doesn't support a lot of features that
>>>> have been common for 12+ years.
>>>>
>>>> 2. The drivers are so unmaintained that even hacking in new features
>>>> with dummy implementations is painful.
>>>>
>>>> 3. The drivers are so buggy that many piglit tests hang the GPU.  I
>>>> tried doing a piglit run on a Rage128 Pro that I have, but I gave up
>>>> after having to blacklist 15 tests.
>>>>
>>>> It also seems that at least some distros (e.g., Fedora) have stopped
>>>> shipping non-DRI2 drivers.  If nobody is shipping it, nobody is using it.
>>>>
>>>> My specific proposal is:
>>>>
>>>>  - Remove all DRI1 drivers: i810, mach64, mga, r128, savage, sis, tdfx,
>>>> and unichrome.
>>>>
>>>>  - Remove all unmaintained Windows drivers: gldirect, icd.
>>>>
>>>>  - Remove beos.
>>>>
>>>>  - Remove fbdev (this is swrast on raw fbdev).
>>>>
>>>> Opinions?
>>>
>>> I've put up an initial branch at
>>>
>>>        git://people.freedesktop.org:~idr/mesa kill-old-drivers
>>>
>>> The only thing that isn't deleted yet is BeOS.  There are a bunch of
>>> stray BeOS bits here and there, so I want to extract it carefully.
> 
>> If you actually kept the DRI1 stuff in glx you would be able to install
>> old DRI1 drivers from a old mesa release alongside DRI2 drivers and
>> libGL from a newer one, since we have been pretty good (AFAIK) at
>> keeping the backwards compatibility in the DRI and libGL interfaces.*

Forgive my ignorance, but...doesn't changing dd_function_table break the
old libGL/new DRI driver API/ABI?  Or, is that different?  In
particular, the following functions have been dropped since 7.11:
- CopyTexImage1D
- CopyTexImage2D
- MapBuffer

And these driver functions have changed:
- MapBufferRange
- FlushMappedBufferRange
- GetBufferSubData
- BufferSubdata
- UnmapBuffer
- ChooseTextureFormat

If so, you couldn't build a 7.11 or 7.10 driver and use it with
master/7.12/8.0.  I suppose people could grab a snapshot right before
the removal, but we'll certainly change this again...

> That's a fair point.  Since we have a clean mechanism to improve those
> interfaces (e.g., DRI2!), there's relatively little cost in keeping that
> code around.
> 
> I'd usually be pretty stoked about deleting 842 lines of code, but it
> feels pretty insignificant right after deleting 85,811 lines of code!  I
> may have now out ajaxed ajax. :)

It may be insignificant in size, but it _does_ make it harder for people
trying to get up to speed with the DRI code.  There are a lot of
structures, tokens, and functions which _look_ relevant for a DRI2
driver, but are actually DRI1.  It's not entirely clear, for example,
that dri_context and dri_screen are DRI1-only.  I imagine Chad has an
opinion on this.

So I'm still in favor of removing DRI1 entirely.  People can just stick
with 7.11.

>> This would of course depend on that somebody actually tested that
>> it still worked for every release and fixed any bugs, hopefully we won't
>> have that much churn in the glx code. Then again if nobody tests and
>> nobody have the time to get involved with fixing one or two bugs in
>> this little bit of code (diff said less then 1K loc), nobody really cares
>> and it wont be missed. Somebody who actually uses the hardware
>> needs to step and actually do something**.
> 
>> That said I don't mind the drivers going, but I would like to see the
>> DRI1 interface staying as long as somebody can do some testing.