<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">Milestones:</div><div dir="auto">- make src/compiler a standalone lib</div><div dir="auto">- don't include src/mesa in other places</div><div dir="auto">- split classic drivers into src/mesa_classic</div><div dir="auto"><br></div><div dir="auto">Marek</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun., Mar. 29, 2020, 00:08 Jason Ekstrand, <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Mar 25, 2020 at 6:32 PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank" rel="noreferrer">maraeo@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Dec 5, 2019 at 2:58 AM Kenneth Graunke <<a href="mailto:kenneth@whitecape.org" target="_blank" rel="noreferrer">kenneth@whitecape.org</a>> wrote:<br>
>><br>
>> On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote:<br>
>> > Hi,<br>
>> ><br>
>> > Here are 2 proposals to simplify and better optimize the GL->Gallium<br>
>> > translation.<br>
>> ><br>
>> > 1) Move classic drivers to a fork of Mesa, and remove them from master.<br>
>> > Classic drivers won't share any code with master. glvnd will load them, but<br>
>> > glvnd is not ready for this yet.<br>
>> ><br>
>> > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,<br>
>> > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and<br>
>> > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target<br>
>> > location.<br>
>> ><br>
>> > Option 2 is more acceptable to people who want to keep classic drivers in<br>
>> > the tree and it can be done right now.<br>
>> ><br>
>> > Opinions?<br>
>> ><br>
>> > Thanks,<br>
>> > Marek<br>
>><br>
>> FWIW, I am not in favor of either plan for the time being.<br>
>><br>
>> - I agree with Eric that we're finally starting to clean up and<br>
>>   de-duplicate things, and pay off technical debt we've put off for<br>
>>   a long time.  I think forking everything in-tree would just be a<br>
>>   giant mess.<br>
>><br>
>> - I agree with Dave that this seems to be a giant hassle for our<br>
>>   downstreams with little benefit for them in the short term.<br>
><br>
><br>
> If classic drivers were moved to src/mesa_classic, nothing would change for downstream.<br>
<br>
I'm concerned that doing that is just asking for more maintenance<br>
problems than we have today.  One of the problems we currently have is<br>
that our #includes are still spaghetti.  We've got stuff in src/util<br>
which inclues stuff in gallium as well as stuff in mesa/main.  If we<br>
even have one cross-wired include, it could lead to bezar and nearly<br>
impossible to trace bugs due to ABI incompatibility between the two<br>
copies of src/mesa the moment we start changing structs or function<br>
prototypes.  The obvious answer to this is "we'll sort out the<br>
spaghetti mess".  However, that also means serious changes to<br>
src/compiler/glsl because it includes mtypes.h.  Do we clone that too?<br>
 I honestly think that this particular cure is likely far worse than<br>
the disease of having to do careful testing of src/mesa changes.<br>
<br>
IMO, a far better plan would be to give it one more year so that<br>
distros and users get experience with iris and then fork off an LTS<br>
branch and delete all the legacy stuff from master.  We can continue<br>
to do maintenance in the LTS branch as needed but I honestly don't<br>
expect much work to happen there.  The most difficult thing will be<br>
deciding what to remove from master but I don't want to make that<br>
decision today.  However, doing a clean fork means we don't have to<br>
worry about cross-contamination in shared code causing weird issues<br>
because they're in separate branches.  We will have to figure out a<br>
few loader issues to ensure that the master drivers get preferred over<br>
the LTS ones or somehow disable all master drivers in the LTS branch.<br>
<br>
--Jason<br>
</blockquote></div>