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

Sun Mar 29 16:45:44 UTC 2020

As for loading, doesn't glvnd solve that?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20200329/ddbd7bc2/attachment.htm>