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

[Timothy Arceri]

On 18/05/17 07:34, Marek Olšák wrote:
> On May 17, 2017 11:13 PM, "Timothy Arceri" <tarceri at itsqueeze.com 
> <mailto:tarceri at itsqueeze.com>> wrote:
> 
>     On 18/05/17 04:23, Marek Olšák wrote:
> 
>         On Wed, May 17, 2017 at 7:36 PM, Ilia Mirkin
>         <imirkin at alum.mit.edu <mailto:imirkin at alum.mit.edu>> wrote:
> 
>             On Wed, May 17, 2017 at 1:26 PM, Ian Romanick
>             <idr at freedesktop.org <mailto: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
>                     <mailto: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.
> 
> 
>         This is the boldest proposal I've seen so far. I have some
>         sentimental
>         feelings about gallium/r300, but if it were the only driver without
>         native integer support blocking some major Mesa cleanup, I would let
>         it go. If we wanna discuss driver removal, the most likely
>         candidates
>         are i915g (completely broken currently) and maybe some classic
>         drivers. I guess some people have feelings about their classic
>         drivers
>         too, but at the end of the day we have to decide what's best for the
>         future.
> 
> 
>     My thinking was that we would use a separate repository as Ilia is
>     suggesting and it would essentially be a separate project from Mesa
>     that evolves on its own i.e. the drivers wouldn't just be dropped in
>     a branch like the dri1 drivers were and contributors would be free
>     to clean-up all the unrelated code that is only used by the new
>     drivers etc.
> 
> 
> Where can I find the contributors? As far as I know, there are none. It 
> would be a dead repo from the beginning.

As I said below it's probably wishful thinking. But if it is definitely 
going to be a dead repo from the beginning there is no reason not to 
break off these drivers :)

> 
> Marek
> 
> 
>     In this scenario there would be no reason to feel sentimental as the
>     drivers would live on and potentially in a better state than staying
>     in Mesa, but maybe it's wishful thinking that such a project would
>     gain much support.
> 
> 
>