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

[Jason Ekstrand]

On Wed, May 17, 2017 at 10:36 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> 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.
>

I didn't say they couldn't be maintained on the "ancient" branch but it
would mean bugfix-only which it sounds like is already the current status.


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170517/73607de1/attachment.html>