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

[Marek Olšák]

On May 17, 2017 11:13 PM, "Timothy Arceri" <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> 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.
>>
>> 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.

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