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

[Jason Ekstrand]

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.

--Jason

>>
>> On 05/16/2017 06:05 AM, Emil Velikov wrote:
>>> Hi all,
>>>
>>> As many of you know the current DRI interface provides backwards
>>> compatibility between old loaders and new drivers, and vice-versa.
>>>
>>> Sometimes issues cannot be addressed with the existing extensions and
>>> we need to bump the version or provide an alternative extension.
>>> In such cases we still preserve the old buggy code path.
>>>
>>> Even when that's not the case, we still end up with highly divergent
>>> code, as some features are exposed only when the extension criteria is
>>> met.
>>>
>>>
>>> At the moment we claim to support any loader <> driver combination in
>>> existence, while in reality components from different Mesa versions
>>> are rarely tested.
>>> One noticeable exception is the legacy DRI1 drivers. Therefore this
>>> proposal does _not_ cover any DRI1 specific changes.
>>>
>>> To straighten the code flow and remove much of the unused code, I'm
>>> proposing the following:
>>>
>>> 1) Establish deprecation period - keep in mind the DRI loader in Xserver.
>>> 2) Any extension that is supported on both driver and loader gets deprecated.
>>>    A) Drivers and loaders are annotated to emit a warning when used
>>> with 'too old' counterpart.
>>>    B) If applicable extensions are moved out of dri_interface.h to
>>> another header.
>>> 3) At the end of deprecation period:
>>>    A) Cleanup all the dead code.
>>>
>>> Personally, 1 year sounds reasonable, as that constitutes of four Mesa
>>> major releases.
>>> For the other actions, I have patches around that I could polish and
>>> sending to the list.
>>>
>>> I would greatly appreciate any input, esp. from distribution maintainers.
>>>
>>> Should my proposal seem unsuitable, I would strongly encourage people
>>> to provide brief action plan alongside the obstacles they see.
>>>
>>> Thanks
>>> Emil
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev