[Mesa-dev] Proposal to branch off old drivers

[Timothy Arceri]

On 26/05/17 10:45, 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.

A point from the dri1 proposal:

5. The hardware is so old that it doesn't support a lot of features that
have been common for 13 years (OpenGL 2.0).
Note: That some of the later hardware supported by (r300, NV30) does 
include OpenGL 2.{0,1}.


> 
> 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


Forgot NV30 here.


> 
> Opinions?
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev