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

apinheiro apinheiro at igalia.com
Thu Dec 5 09:21:39 UTC 2019


On 5/12/19 8:48, Kenneth Graunke wrote:
> 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.
>
> - 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+.
>
> - 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.
>
>    So, I kind of wonder whether it's worth our time to go through and
>    massively clean up and rearchitecture the OpenGL drivers at this
>    point.  By the time we're finished, will anyone care?
>
> - Are there concrete things that are prohibitively expensive with
>    classic around?  Otherwise, Eric's suggestion of "so go do that!"
>    sounds like a good idea.  We've started finally merging a bunch
>    of code and I think this is a positive direction.
>
> I'd say let's shelve this for now and think about it again later.
> I suspect in a year or so the calculus will look fairly different.


Although I think that it is somewhat early to think that OpenGL is 
nearly a dead end, FWIW, I agree in general with Kenneth analysis and 
suggestions here.

BR



More information about the mesa-dev mailing list