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

[Rob Clark]

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

Just one small annoyance to point out, that the non-pci drivers (ie.
basically the arm ones) don't have a pci-id to decide whether to load
${driver}_dri.so vs ${driver}_old_dri.so, which would be awkward if
the split was based on native-integers or not.

Other than that, Marek is probably right about not having many
contributors for the new tree (or branch).. although maybe that
doesn't matter if at least what used to work continues to work.  It
might be annoying if something new like dri4 came along..

BR,
-R