[Mesa-dev] Proposal to branch off old drivers

[Rob Clark]

On Thu, May 25, 2017 at 8:45 PM, Timothy Arceri <tarceri at itsqueeze.com> wrote:
>
> 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?

The arguments about not breaking old/stable drivers that aren't
getting much testing on mesa/master is valid..

I'm not sure I would call it "pre-dx9".. part of that might be not
being sure what dx feature level maps to in opengl(es).. on the mobile
side, we have some newer hw and drivers that see a lot of development
which could only support gl2/gles2, and I wouldn't want to cut those
off.  Especially when they might share a lot of code w/ drivers for
newer hw which could support gl3/gles3+.. ie. etnaviv/freedreno (and
maybe someday vc4?).

Otoh if we can count on libglvnd to be a stable API so distros could
let drivers from legacy tree/branch easily coexist w/ drivers from a
master branch.. that might be a win-win.  The downsides are porting
changes related to dependencies (I guess most of what we can drop
doesn't care about llvm version, so the dependencies are not much?),
new gcc versions (I guess mostly solved by compiler flags in distro
packaging?), and CVEs (I guess not much?).  The upside is drivers for
old hw doesn't get repeatedly broken by refactoring and new features
that can't easily be tested on old hw.  The rest is just sorting out
which side of those choices out-weighs the other.

BR,
-R