How many times do people have to say NO to this proposal until it goes away?
On 05/25/2017 05:45 PM, Timothy Arceri wrote: > Hi all, > > Following on from the discussion here: > > https://lists.freedesktop.org/archives/mesa-dev/2017-May/155971.html > > Back in 2011/12 despite various concerns old hardware would become > useless, dropping support for DRI1 drivers Mesa proved distros were up > to the challenge of packaging up the old driver branch, and since we > maintain compatibility they continue to work without issue. > > I'm currently working on uniform packing for gallium drivers which means > updates to struct gl_program_parameter_list and the assumption that > everything is padded to 4 vectors. Rather than updating and testing i915 > to work with this (or even hacking around it), I'd rather make the > proposal to branch off some older drivers. > > Why branch them off? > > 1. IMO there is a bunch of clean-up this would enable such as: > > - enabling a bunch of extensions by default and removing on the runtime > checks for these pasted all over the api. > - dropping a bunch of non asm mesa ir code paths > - dropping a bunch of driver function callbacks > - the software tnl code?? > - Likely a bunch of other bits and pieces. > > 2. They are either not in development at all, or being updated extremely > rarely. Testing is often just does this code compile. Having them in > master just opens them to the possibility of breakage. > > 3. Death by a thousand cuts. While the clean-ups above may not be huge I > would argue a more important outcome is the ability to preform > re-factors, add features, etc without needlessly updating these drivers. > > As someone who re-factored the main gl_* structs last year in the lead > up to shader cache support, I can say my job would have been much easier > if I didn't have to needlessly update the old classic drivers. > On the gallium side there is are things like adding caps to all the > drivers etc, again not huge but another cut. > > 4. As the API expands it just adds more overhead for features these > drivers will mostly never support. The drivers likely already run on > systems with much slower cpus. > > My specific proposal is: > > - Rather than just pointing distros at the last Mesa release as we did > for the DRI1 driver, we create a mesa-pre-dx9-1.0 branch (branched from > 17.1). However unlikely this will at least give us the possibility to > release updates as some dev's have shown interest in. > > - Remove the following drivers from master: > Classic: > -------- > i915, nouveau, r200, radeon, swrast (classic) > > Gallium: > -------- > r300, i915g > > Opinions? > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
