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

[Timothy Arceri]

On 17/05/17 14:04, 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.

Sure I agree. But there wasn't any real question or discussion there. To 
me there was just some sarcasm followed by a do as I say. Why not wait 
for some patches or at least genuinely ask for some justification before 
deciding if it just churn.

> 
> 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.

Yes please! I would like to see something like this happen. As I just 
mentioned in another thread [1] I was hoping libglvnd might allow us to 
do something like this (but it seems not). I agree that if we are going 
to keep backwards compatibility it would be good to use it to do this.

There is a bunch of stuff we can clean up if we do this, such as 
enabling a bunch of extensions by default and removing on the runtime 
checks for these pasted all over the api, dropping a bunch of mesa ir 
code paths, dropping some driver function callbacks, the software tnl 
code?, etc.

[1] https://lists.freedesktop.org/archives/mesa-dev/2017-May/155899.html

> 
> --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
> 
>