On May 17, 2017 11:13 PM, "Timothy Arceri" <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> 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. > > 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. 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
