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

[Rob Clark]

On Wed, May 17, 2017 at 1:36 PM, 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.

It doesn't look like etnaviv currently supports native integers.  But
I guess some variants do (since some support gles3/gles31).  There are
also still folks who want to use a2xx (although not sure that I've
seen any patches posted yet).

I think dropping support for gallium drivers that don't support
integers would be rather unfortunate.  The older classic drivers might
be a different story.

BR,
-R

>> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev