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