[Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
maraeo at gmail.com
Sun Mar 29 04:41:08 UTC 2020
The #include spaghetti will be resolved before the split. I don't care
about including gallium, but no code will include src/mesa outside of that.
The biggest part is to make src/compiler completely independent and that's
a worthy goal by itself.
- make src/compiler a standalone lib
- don't include src/mesa in other places
- split classic drivers into src/mesa_classic
On Sun., Mar. 29, 2020, 00:08 Jason Ekstrand, <jason at jlekstrand.net> wrote:
> On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák <maraeo at gmail.com> wrote:
> > 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
> >> > 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/vbo, mesa/program, and drivers/dri/common need to be forked and
> >> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the
> >> > 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 downstream.
> I'm concerned that doing that is just asking for more maintenance
> problems than we have today. One of the problems we currently have is
> that our #includes are still spaghetti. We've got stuff in src/util
> which inclues stuff in gallium as well as stuff in mesa/main. If we
> even have one cross-wired include, it could lead to bezar and nearly
> impossible to trace bugs due to ABI incompatibility between the two
> copies of src/mesa the moment we start changing structs or function
> prototypes. The obvious answer to this is "we'll sort out the
> spaghetti mess". However, that also means serious changes to
> src/compiler/glsl because it includes mtypes.h. Do we clone that too?
> I honestly think that this particular cure is likely far worse than
> the disease of having to do careful testing of src/mesa changes.
> IMO, a far better plan would be to give it one more year so that
> distros and users get experience with iris and then fork off an LTS
> branch and delete all the legacy stuff from master. We can continue
> to do maintenance in the LTS branch as needed but I honestly don't
> expect much work to happen there. The most difficult thing will be
> deciding what to remove from master but I don't want to make that
> decision today. However, doing a clean fork means we don't have to
> worry about cross-contamination in shared code causing weird issues
> because they're in separate branches. We will have to figure out a
> few loader issues to ensure that the master drivers get preferred over
> the LTS ones or somehow disable all master drivers in the LTS branch.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev