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

[Timothy Arceri]

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.