On 27/05/17 08:11, Rob Clark wrote:
On Fri, May 26, 2017 at 10:16 AM, Brian Paul <bri...@vmware.com> wrote:
On 05/25/2017 06:45 PM, Timothy Arceri wrote:
Hi all,
Following on from the discussion here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_mesa-2Ddev_2017-2DMay_155971.html&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=gm5GImkP-Ydr8Pd1vhXbWJvFSmS_MUND5KGjOHQpVOU&s=2xNPkqm6U5phLP1RHR5BfKOC5fpPplnj9U1FAZvCuAM&e=
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
Opinions?
I think a key point is what do the distro vendors think/want? That is, do
vendors such as Fedora, Ubuntu, etc. perceive a need to keep supporting the
older GPUs? It would be extra work for them to build/package/ship ToT Mesa
plus drivers from a deprecated driver branch.
I guess the "one extra package to build" is probably greatly offset by
the "not having to debug broken old hw because of new mesa features"
aspect.. although in practice I don't end up doing much of either.
I'm much less excited about the "drop pre-dx9 parts of
gallium+mesa/st" part of the idea, since that is needed by a bunch of
the smaller arm gpus that are seeing active development. But if
libglvnd let us partition things so we never/rarely had to touch the
legacy tree, and it therefore reduced the risk of breakage for someone
with old hw upgrading to newer distro to get security fixes or
unrelated new features, that seems pretty useful.
It seems removing the Gallium drivers would be more trouble than its
worth. On the classic side unless everything but i965 is dropped I don't
see much point of branching the other driver off.
Marek made an interesting suggestion to drop i915c and keep i915g, not
sure how well that suggestion would go down with the Intel devs.
BR,
-R
This is an instance where I'd love to be able to poll the user community to
see what GPUs people still care about. I don't know if the distro vendors
have such data about their user's hardware.
Though, I have a feeling that if someone's still using i915, r200, radeon,
etc. (and want to use the latest distros) they're not too concerned about 3D
performance and just want reasonable desktop performance. Would they be
happy with llvmpipe?
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
