On 18/05/17 04:23, Marek Olšák wrote:
On Wed, May 17, 2017 at 7:36 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
On Wed, May 17, 2017 at 1:26 PM, Ian Romanick <i...@freedesktop.org> wrote:
On 05/16/2017 09:04 PM, 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.
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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
