<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On May 17, 2017 11:13 PM, "Timothy Arceri" <<a href="mailto:tarceri@itsqueeze.com">tarceri@itsqueeze.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On 18/05/17 04:23, Marek Olšák wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, May 17, 2017 at 7:36 PM, Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, May 17, 2017 at 1:26 PM, Ian Romanick <<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/16/2017 09:04 PM, Jason Ekstrand wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On May 16, 2017 18:30:00 Timothy Arceri <<a href="mailto:tarceri@itsqueeze.com" target="_blank">tarceri@itsqueeze.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 17/05/17 02:38, Ian Romanick wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What *actual* problem are you trying to solve?  Honestly, it seems like<br>
you're just trying to find stuff to do.  We have a mechanism to make<br>
this work, and it's not that hard.  Introducing a deprecation period and<br>
everything that involves will make it more work, not less.<br>
</blockquote></blockquote>
<br>
I think that's a fair question<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To be fair aren't we in a stage in Mesa's life-cycle where the focus is<br>
on tidying-up / optimisations. It's not like there are large spec<br>
updates in the pipeline.<br>
</blockquote>
<br>
If we are genuinely making things more maintainable, then maybe<br>
deprecation is reasonable.  However, of it's just churn, then it may<br>
just be a source of new bugs to fix.  I think asking "why?" is perfectly<br>
reasonable.<br>
<br>
On the other side, perhaps we should consider instead taking advantage<br>
of the backwards comparability and dropping some of the old and<br>
unmaintained drivers from the tree, put them on a critical-bugfix-only<br>
branch, and recommend that distros build two mesas and only install the<br>
loader from the newer one.  Dropping i915, r200, and other effectively<br>
unmaintained drivers from the tree would make it much easier to do core<br>
state tracker cleanups since there would effectively only be two state<br>
trackers: gallium and i915. For example, there's a lot of code floating<br>
around for dealing with hardware that doesn't have native integers.<br>
</blockquote>
<br>
r300 and r400 in Gallium do not have native integers.  I don't know<br>
about NV30.<br>
</blockquote>
<br>
NV30 does not have native integers. Neither does a2xx. Not sure about etnaviv.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I wanted to remove support for NV04 and NV05 last year because they are<br>
unused, unmaintained, and demonstrably *broken*, and I could not even<br>
get consensus on that.<br>
</blockquote>
<br>
For the record, they work and are maintained (although imperfect, with<br>
some known breakage). Maintained, to me, means "if someone comes with<br>
an issue, there will be an attempt to address it". But they're rarely<br>
tested, and questionably used by anyone other than the tester (me),<br>
and only on NV5, as I don't have a NV4.<br>
<br>
Separately, I'd definitely consider a discussion about cleaving off<br>
the post-modern-times drivers (DX10+ hardware) from the<br>
pre-modern-times hardware (DX9 and older), and moving those off into a<br>
mesa-pre-dx9 repository. I doubt there are too many bugs/features for<br>
those that would greatly benefit from a shared repository. And mesa<br>
could shed a ton of support code in the process. On both sides.<br>
</blockquote>
<br>
This is the boldest proposal I've seen so far. I have some sentimental<br>
feelings about gallium/r300, but if it were the only driver without<br>
native integer support blocking some major Mesa cleanup, I would let<br>
it go. If we wanna discuss driver removal, the most likely candidates<br>
are i915g (completely broken currently) and maybe some classic<br>
drivers. I guess some people have feelings about their classic drivers<br>
too, but at the end of the day we have to decide what's best for the<br>
future.<br>
<br>
</blockquote>
<br></div>
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.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Where can I find the contributors? As far as I know, there are none. It would be a dead repo from the beginning.</div><div dir="auto"><br></div><div dir="auto">Marek</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote></div></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br></div></div></div>