On May 16, 2017 18:30:00 Timothy Arceri <tarc...@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
