[Mesa-dev] Proposal to branch off old drivers

[Ilia Mirkin]

On Thu, May 25, 2017 at 9:05 PM, Rob Clark <robdclark at gmail.com> wrote:
> 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

I'd throw nv30 onto that list too...

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

The older (pre-DX10) gallium drivers require LLVM for proper
operation. So actually the main issue with deprecating any of the
older gallium drivers will be that someone will have to still maintain
gallivm for new llvm versions (and do occasional releases). Also as
winsys updates are made, they may have to be done in both repos.
However this tends to be rare.

I'd hate for this split to *reduce* the level of support we provide on
that HW. That level of support is, largely, if it worked yesterday,
it'll keep working today, along with general updates to continue to
integrate properly to the surrounding universe.

  -ilia