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. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
