[Mesa-dev] DEATH to old drivers!

[Dave Airlie]

On Thu, Aug 25, 2011 at 3:38 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> 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.

Makes it hard for distros though.

Since you'd have to ship two libGLs, and then really we are condoning
what the binary drivers do.

Dave.