[Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Ilia Mirkin]

On Wed, May 17, 2017 at 1:26 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 05/16/2017 09:04 PM, Jason Ekstrand wrote:
>> On May 16, 2017 18:30:00 Timothy Arceri <tarceri at itsqueeze.com> wrote:
>>
>>> On 17/05/17 02:38, Ian Romanick wrote:
>>>> What *actual* problem are you trying to solve?  Honestly, it seems like
>>>> you're just trying to find stuff to do.  We have a mechanism to make
>>>> this work, and it's not that hard.  Introducing a deprecation period and
>>>> everything that involves will make it more work, not less.
>>
>> I think that's a fair question
>>
>>> To be fair aren't we in a stage in Mesa's life-cycle where the focus is
>>> on tidying-up / optimisations. It's not like there are large spec
>>> updates in the pipeline.
>>
>> If we are genuinely making things more maintainable, then maybe
>> deprecation is reasonable.  However, of it's just churn, then it may
>> just be a source of new bugs to fix.  I think asking "why?" is perfectly
>> reasonable.
>>
>> On the other side, perhaps we should consider instead taking advantage
>> of the backwards comparability and dropping some of the old and
>> unmaintained drivers from the tree, put them on a critical-bugfix-only
>> branch, and recommend that distros build two mesas and only install the
>> loader from the newer one.  Dropping i915, r200, and other effectively
>> unmaintained drivers from the tree would make it much easier to do core
>> state tracker cleanups since there would effectively only be two state
>> trackers: gallium and i915. For example, there's a lot of code floating
>> around for dealing with hardware that doesn't have native integers.
>
> r300 and r400 in Gallium do not have native integers.  I don't know
> about NV30.

NV30 does not have native integers. Neither does a2xx. Not sure about etnaviv.

> I wanted to remove support for NV04 and NV05 last year because they are
> unused, unmaintained, and demonstrably *broken*, and I could not even
> get consensus on that.

For the record, they work and are maintained (although imperfect, with
some known breakage). Maintained, to me, means "if someone comes with
an issue, there will be an attempt to address it". But they're rarely
tested, and questionably used by anyone other than the tester (me),
and only on NV5, as I don't have a NV4.

Separately, I'd definitely consider a discussion about cleaving off
the post-modern-times drivers (DX10+ hardware) from the
pre-modern-times hardware (DX9 and older), and moving those off into a
mesa-pre-dx9 repository. I doubt there are too many bugs/features for
those that would greatly benefit from a shared repository. And mesa
could shed a ton of support code in the process. On both sides.

  -ilia