<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 17, 2017 at 10:36 AM, Ilia Mirkin <span dir="ltr"><<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, May 17, 2017 at 1:26 PM, Ian Romanick <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>> wrote:<br>
> On 05/16/2017 09:04 PM, Jason Ekstrand wrote:<br>
>> On May 16, 2017 18:30:00 Timothy Arceri <<a href="mailto:tarceri@itsqueeze.com">tarceri@itsqueeze.com</a>> wrote:<br>
>><br>
>>> On 17/05/17 02:38, Ian Romanick wrote:<br>
>>>> 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>
>><br>
>> I think that's a fair question<br>
>><br>
>>> 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>
>><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>
><br>
> r300 and r400 in Gallium do not have native integers.  I don't know<br>
> about NV30.<br>
<br>
</div></div>NV30 does not have native integers. Neither does a2xx. Not sure about etnaviv.<br>
<span class=""><br>
> 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>
<br>
</span>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></blockquote><div><br></div><div>I didn't say they couldn't be maintained on the "ancient" branch but it would mean bugfix-only which it sounds like is already the current status.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<span class="HOEnZb"><font color="#888888"><br>
  -ilia<br>
</font></span></blockquote></div><br></div></div>