[Mesa-dev] Proposal to branch off old drivers

[Timothy Arceri]

On 26/05/17 21:38, Marek Olšák wrote:
> On May 26, 2017 2:45 AM, "Timothy Arceri" <tarceri at itsqueeze.com 
> <mailto:tarceri at itsqueeze.com>> wrote:
> 
>     Hi all,
> 
>     Following on from the discussion here:
> 
>     https://lists.freedesktop.org/archives/mesa-dev/2017-May/155971.html
>     <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
> 
> 
> No matter how hard you are trying, there is no real benefit in removing 
> any Gallium drivers. Come on, is the PIPE_CAP thing your only argument? 
> I can add a new PIPE_CAP case to all gallium drivers in 15 seconds. If 
> you can't do that, you need a better editor.

No the reason was the same as all the other drivers. To stop 
untested/unmaintained drivers breaking, and to remove various legacy 
OpenGL 2.1 < checks from Mesa core.

> 
> The only reason for removing a Gallium driver would be if the driver was 
> broken or inferior in some way. That might be i915g, but even that is 
> kinda a shaky ground.
> 
> I thought you'd only ask about removing pre-i915 classic drivers (i.e. 
> keeping i915). That would have a higher chance of success.

The pre-i915 drivers are actually not a big deal since they don't 
implement many features. In my experience its i915 that gets in the way 
a lot of the time.

It seemed like there was more support for this work last week. So I 
withdraw my proposal. I'll just hack around the i915 driver like we 
always do.

> 
> Speaking of those, I think the deprecation branch could be 17.1 itself.
> 
> Marek
> 
> 
>     Opinions?
>     _______________________________________________
>     mesa-dev mailing list
>     mesa-dev at lists.freedesktop.org <mailto:mesa-dev at lists.freedesktop.org>
>     https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>     <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>
> 
>