On 26/05/17 21:38, Marek Olšák wrote:
On May 26, 2017 2:45 AM, "Timothy Arceri" <tarc...@itsqueeze.com
<mailto:tarc...@itsqueeze.com>> wrote:
Hi all,
Following on from the discussion here:
https://lists.freedesktop.org/archives/mesa-dev/2017-May/155971.html
<https://lists.freedesktop.org/archives/mesa-dev/2017-May/155971.html>
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
No matter how hard you are trying, there is no real benefit in removing
any Gallium drivers. Come on, is the PIPE_CAP thing your only argument?
I can add a new PIPE_CAP case to all gallium drivers in 15 seconds. If
you can't do that, you need a better editor.
No the reason was the same as all the other drivers. To stop
untested/unmaintained drivers breaking, and to remove various legacy
OpenGL 2.1 < checks from Mesa core.
The only reason for removing a Gallium driver would be if the driver was
broken or inferior in some way. That might be i915g, but even that is
kinda a shaky ground.
I thought you'd only ask about removing pre-i915 classic drivers (i.e.
keeping i915). That would have a higher chance of success.
The pre-i915 drivers are actually not a big deal since they don't
implement many features. In my experience its i915 that gets in the way
a lot of the time.
It seemed like there was more support for this work last week. So I
withdraw my proposal. I'll just hack around the i915 driver like we
always do.
Speaking of those, I think the deprecation branch could be 17.1 itself.
Marek
Opinions?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org <mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
<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
