On 26/05/17 11:13, Ilia Mirkin wrote:
On Thu, May 25, 2017 at 9:05 PM, Rob Clark <robdcl...@gmail.com> wrote:
On Thu, May 25, 2017 at 8:45 PM, Timothy Arceri <tarc...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
