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

Sun Mar 29 18:58:41 UTC 2020

On Sun, Mar 29, 2020 at 11:45 AM Kristian Høgsberg <hoegsberg at gmail.com> wrote:
>
> As for loading, doesn't glvnd solve that?

Not really.  There are still problems if you have HW drivers from both
repos on the same system and someone has to decide which one to use.
We would either have to come up with a good solution to that problem
or we would have to delete/disable all of the drivers still in master
in the LTS branch.  In any case, there are real problems to solve
there.

--Jason

> On Sun, Mar 29, 2020, 1:19 AM Marek Olšák <maraeo at gmail.com> wrote:
>>
>> If you want a complete fork or removal, that's fine with me. It's technically more challenging for driver loaders and packaging though.
>>
>> Marek
>>
>> On Sun., Mar. 29, 2020, 02:51 Jason Ekstrand, <jason at jlekstrand.net> wrote:
>>>
>>> On Sat, Mar 28, 2020 at 11:41 PM Marek Olšák <maraeo at gmail.com> wrote:
>>> >
>>> > 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.
>>>
>>> If we make sure that we modify the #include guards on every header in
>>> src/mesa_classic so that any accidental cross-includes lead to double
>>> definitions and therefore compile errors, that would probably help.
>>> It'd certainly give me a lot more confidence that we've done it right.
>>>
>>> > The biggest part is to make src/compiler completely independent and that's a worthy goal by itself.
>>>
>>> Yeah, I've wanted to see that happen since we started splitting stuff
>>> out to make Vulkan a possibility.
>>>
>>> > Milestones:
>>> > - make src/compiler a standalone lib
>>> > - don't include src/mesa in other places
>>> > - split classic drivers into src/mesa_classic
>>>
>>> If you're willing to do the work, I guess I'm not opposed for now.
>>>
>>> That said, I also have some somewhat selfish reasons for wanting to do
>>> a fork.  In particular, I'd like to freeze i965 and possibly Gen7
>>> Vulkan in time so that we can stop maintaining the i965 and the old
>>> vec4 back-end compiler.  Even though we're not adding features, I
>>> still find myself having to fix those up from time to time due to
>>> reworks elsewhere.  Maybe the answer is to copy and isolate them too
>>> but, at that point, why not just put them in a branch?
>>>
>>> --Jason
>>>
>>>
>>> > Marek
>>> >
>>> > 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> 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.
>>> >> >
>>> >> >
>>> >> > 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.
>>> >>
>>> >> --Jason
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev