On Wed, May 17, 2017 at 10:36 AM, Ilia Mirkin <[email protected]> wrote:
> On Wed, May 17, 2017 at 1:26 PM, Ian Romanick <[email protected]> wrote: > > On 05/16/2017 09:04 PM, Jason Ekstrand wrote: > >> On May 16, 2017 18:30:00 Timothy Arceri <[email protected]> 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. > 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. > 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. > > -ilia >
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
