On 18/05/17 07:34, Marek Olšák wrote:
On May 17, 2017 11:13 PM, "Timothy Arceri" <tarc...@itsqueeze.com
<mailto:tarc...@itsqueeze.com>> wrote:
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 <mailto:imir...@alum.mit.edu>> wrote:
On Wed, May 17, 2017 at 1:26 PM, Ian Romanick
<i...@freedesktop.org <mailto: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
<mailto: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.
Where can I find the contributors? As far as I know, there are none. It
would be a dead repo from the beginning.
As I said below it's probably wishful thinking. But if it is definitely
going to be a dead repo from the beginning there is no reason not to
break off these drivers :)
Marek
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
