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

[Jason Ekstrand]

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