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

Wed Dec 4 16:58:15 UTC 2019

On Wed, Dec 4, 2019 at 5:51 AM Timothy Arceri <tarceri at itsqueeze.com> wrote:

>
>
> On 4/12/19 3:45 pm, Jason Ekstrand wrote:
> > On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie <airlied at gmail.com
> > <mailto:airlied at gmail.com>> wrote:
> >
> >     On Wed, 4 Dec 2019 at 10:39, Marek Olšák <maraeo at gmail.com
> >     <mailto: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)
>
> Is already done and enabled for compat profile.
>

Nice!  I thought there was still work left to do there.

> >   - GL_EXT_gpu_shader4
>
> Core mesa parts are done for this also.
>

Nice!  Somehow we didn't notice this happen.  I've pushed a MR for Gen6+ on
i965: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2963

> >   - Compat context support
>
> radeonsi, nouveau and iris all fully enable this. At this point its just
> a driver/classic issue to add support. So as with the two other features
> above options 1 or 2 will not change the fate of this support.
>

Yeah, it's mostly debug work not core mesa work.  So maybe not a blocker.

> >
> > 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.
>
> As per above its only GL_ARB_gl_spirv that would maybe be impacted by
> any fork, but that doesn't change between now and a year so delaying a
> decision for a year based on this is doesn't seem necessary.
>

I think you've calmed most of my fears of SW-only features that are
desperately missing on Gen4-7 not happening.  However, that's not the only
reason why I suggest waiting a year.  i965 is still the primary driver on
Gen8-11 today and we should support it for at least another year while
distros make the transition to iris.  Once we've switched to iris by
default in all the distros and everyone is happy, then I think we can
consider moving i965 into maintenance mode.

Could we make the jump now and maintain i965 in the stable branch?  Maybe.
However, my understanding is that libglvnd isn't quite ready yet (it's
close!) and I'm not sure how it would work to have i965 and iris both
selectable via libglvnd for Gen8-11.  We do want to have an overlap period
and if that's not possible without them living together in-tree, I have a
hard time justifying a split just yet.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20191204/423fd439/attachment-0001.html>