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

Marek Olšák maraeo at gmail.com
Wed Mar 25 23:31:20 UTC 2020

On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke <kenneth at whitecape.org>

> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák 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.
> >
> > 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.
> >
> > Option 2 is more acceptable to people who want to keep classic drivers in
> > the tree and it can be done right now.
> >
> > Opinions?
> >
> > Thanks,
> > Marek
> FWIW, I am not in favor of either plan for the time being.
> - I agree with Eric that we're finally starting to clean up and
>   de-duplicate things, and pay off technical debt we've put off for
>   a long time.  I think forking everything in-tree would just be a
>   giant mess.
> - I agree with Dave that this seems to be a giant hassle for our
>   downstreams with little benefit for them in the short term.

If classic drivers were moved to src/mesa_classic, nothing would change for

> - Shuffling r100/r200/i915/nouveau_vieux off to a legacy fork seems
>   like a fine plan.  They're ancient hardware that can't (or barely
>   can) do GL 2.x.  Nothing much has happened with them in years,
>   and I'm not sure all of them even really have maintainers.
>   The main blocker here I think would be ironing out all the glvnd
>   issues and making sure that is working solidly for everyone.
>   (FWIW, glvnd is not even enabled by default in our build system!)
> - Shuffling i965 off to legacy is really premature I think.  Iris
>   isn't even shipping in distros yet (hopefully soon!), and even
>   then, we have a _ton_ of Haswell users.  Check the Phoronix
>   comments if you want to see how pissed off people are about even
>   bringing up this topic.  (Or better yet, don't...basic human
>   decency toward others seems to be lacking.  Hooray, internet...)
> - Writing a Gallium driver for Intel Gen4-7.5 would be interesting.
>   I've been thinking about this some, and it might be possible to
>   retain some of the niceties of the iris memory model even on older
>   hardware, by relying on a modern kernel and possibly making some
>   (hopefully minor) improvements.  Even if we didn't, going back to
>   the i965 model wouldn't be the worst thing.  The new driver would
>   almost certainly be faster than i965, if not as good as iris.
>   ajax and I were planning to call it crocus, if I wrote one.  I don't
>   think it would take nearly as long.  But it's still a bunch of time
>   that I don't think I can justify spending.  The new hardware can do
>   so much more, and is so much faster, and much lower power.  I think
>   it would be better for me to spend my time on Gen11+.

There is also "ilo", which supports gen6-7, but not GL 4.x and NIR, and
probably isn't as fast as i965 (that might be fixable with NIR):

> - Vulkan has really taken off, and OpenGL feels increasingly like a
>   dead end.  DXVK has brought more games than we had with native ports.
>   Feral is even reworking some native OpenGL ports to use Vulkan.  New
>   graphics features are happening in the Vulkan space.

There are markets like workstation where OpenGL is the main API. OpenGL is
also still relevant in some other markets. New games have transitioned to
Vulkan but not good old games.

I don't think Zink can outperform an optimized Gallium driver across all
legacy features, so it will only be useful in a small subset of use cases.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20200325/cb244365/attachment.htm>

More information about the mesa-dev mailing list