[Mesa-dev] Proposal to branch off old drivers

[Timothy Arceri]

On 26/05/17 11:13, Ilia Mirkin wrote:
> 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.

This is a little unfortunate ... not something I foresaw.

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