[Mesa-dev] Proposal to branch off old drivers

Ian Romanick idr at freedesktop.org
Wed May 31 00:38:04 UTC 2017


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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 



More information about the mesa-dev mailing list