[Mesa-dev] Remove classic drivers or fork src/mesa for gallium?

[Jason Ekstrand]

On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie <airlied at gmail.com> wrote:

> On Wed, 4 Dec 2019 at 10:39, Marek Olšák <maraeo at gmail.com> wrote:
> >
> > Hi,
> >
> > Here are 2 proposals to simplify and better optimize the GL->Gallium
> translation.
> >
> > 1) Move classic drivers to a fork of Mesa, and remove them from master.
> Classic drivers won't share any code with master. glvnd will load them, but
> glvnd is not ready for this yet.
>

I'm usually the first person to tell people to stop mucking about with old
hardware and I fear even I think this would be a bit premature.  We've not
turned iris on by default yet and I'd really like it to bake as the default
distro driver for a while (maybe a year) before we put i965 on
life-support.  If we were having this discussion in another year's time, I
might be in favor of this but, as it currently stands, I'm not sure this is
a good idea.


> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only
> mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be forked
> and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the
> target location.
>

I really don't like this option.  For one thing, this means two copies of
code that will get out-of-sync.  If we had the classic drivers in their own
branch, we could at least cherry-pick bugfixes back to the classic branch.
However, if we have two copies of everything, our version control tool
can't help us.

The bigger problem is headers.  Currently, the GLSL compiler includes
mtypes.h so we would need to somehow separate the GLSL compiler out from
src/mesa/main because we'll have two mtypes.h files.  Unfortunately, GLSL
isn't the only thing that includes stuff from src/mesa/main.  Our header
situation has been a disaster for years and I'm afraid it hasn't gotten any
better with the addition of src/util.  Most people who move stuff don't
actually do due diligence to keep the includes clean and the result is that
I'm pretty sure even the Vulkan drivers are including
src/mesa/main/imports.h.  If we have two copies of src/mesa/main and the
headers begin to diverge, it's going to be a total disaster.  I would love
to see someone clean this all up properly and I think Mesa would be better
for it.  However, it is a LOT of work.

If we did the above cleaning, would I be ok with this approach?  Possibly.
However, I suspect it'd end up being the worst of both worlds.  We still
have maintenance of effectively two branches and bugfixes have to be
ported.  At the same time, we'd still have core changes to things like the
GLSL compiler breaking old drivers so we wouldn't lighten any of the
maintenance burden.


> > Option 2 is more acceptable to people who want to keep classic drivers
> in the tree and it can be done right now.
>
> These both seem pretty horrible to me right now. Like i965 still
> supports a lot of hardware that exists right now even if we move to
> iris.
>

I'm less concerned about the support burden.  When it comes to bugfixes, I
feel like most of the bugs on gen7 and earlier hardware at this point are
due to churn in the core and if it lives in a maintenance branch, we'll
stop breaking it.  The biggest thing we'd loose would be additional
features that we might get thanks to core changes.  The major ones that
come to mind are:

 - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we haven't
due to a lack of testing)
 - GL_EXT_direct_state_access (still underway last I knew)
 - GL_EXT_gpu_shader4
 - Compat context support

All four of those are more-or-less software-only features that older intel
drivers could pick up as the core advances.  Compat support likely requires
a bit of driver work but it should be doable.

The real question is, "How much do we care?"  I can't say I like the idea
of leaving Gen4-7 out in the cold.  Again, in a year's time, we might have
most of the above implemented and then it'd be less of a concern.


> I sorta feel there should be a
> 3) make life harder for classic drivers and optimise things more for
> gallium add more dd.h entrypoints, force the classic drivers to jump
> through hoops to degallium.
>

I'd be interested to see what that would look like.  I'm not actually
convinced that it would work if I'm honest.  Part of gluing them together
in my mind is deleting dd.h entirely and making the GL state tracker just
call gallium stuff.

There may be a 4th option here: Write a gallium driver for Intel Gen4-7.
Unfortunately, it would be a really hard sell to convince anyone (myself
included) that this is worth anyone's time.  Sure, it might be a fun
project, but the engineering effort required to get it to be as good as
i965 is very non-trivial.  I think it's tractable and someone who knows
what they're doing would probably be able to get something working in less
than a year if they steal heavily from i965 and iris.  However, getting it
to the point where performance is no worse may take longer.  While it'd
probably be a fun project for someone, I can't in good conscience say that
the mesa/main refactoring possibilities are enough to justify the effort.

I'm not saying that's a good option. :-)  I just thought we should
enumerate it so that it can be shot down.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20191203/3729690b/attachment.html>