<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <body> <div dir="auto"> <div dir="auto"><span style="font-size: 12pt;">On March 23, 2021 01:46:54 Kenneth Graunke <kenneth@whitecape.org> wrote:</span></div><div id="aqm-original" style="color: black;"> <div><br></div> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"> <div dir="auto">On Monday, March 22, 2021 3:15:30 PM PDT Dylan Baker wrote:</div> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #0099CC; padding-left: 0.75ex;"> <div dir="auto">Hi list,</div> <div dir="auto"><br></div> <div dir="auto">We've talked about it a number of times, but I think it's time time to</div> <div dir="auto">discuss splitting the classic drivers off of the main development branch</div> <div dir="auto">again, although this time I have a concrete plan for how this would</div> <div dir="auto">work.</div> <div dir="auto"><br></div> <div dir="auto">First, why? Basically, all of the classic drivers are in maintanence</div> <div dir="auto">mode (even i965). Second, many of them rely on code that no one works</div> <div dir="auto">on, and very few people still understand. There is no CI for most of</div> <div dir="auto">them, and the Intel CI is not integrated with gitlab, so it's easy to</div> <div dir="auto">unintentionally break them, and this breakage usually isn't noticed</div> <div dir="auto">until just before or just after a release. 21.0 was held up (in small</div> <div dir="auto">part, also me just getting behind) because of such breakages.</div> <div dir="auto"><br></div> <div dir="auto">I konw there is some interest in getting i915g in good enough shape that</div> <div dir="auto">it could replace i915c, at least for the common case. I also am aware</div> <div dir="auto">that Dave, Ilia, and Eric (with some pointers from Ken) have been</div> <div dir="auto">working on a gallium driver to replace i965. Neither of those things are</div> <div dir="auto">ready yet, but I've taken them into account.</div> <div dir="auto"><br></div> <div dir="auto">Here's the plan:</div> <div dir="auto"><br></div> <div dir="auto">1) 21.1 release happens</div> <div dir="auto">2) we remove classic from master</div> <div dir="auto">3) 21.1 reaches EOL because of 21.2</div> <div dir="auto">4) we fork the 21.1 branch into a "classic-lts"¹ branch</div> <div dir="auto">5) we disable all vulkan and gallium drivers in said branch, at least at</div> <div dir="auto">the Meson level</div> <div dir="auto">6) We change the name and precidence of the glvnd loader file</div> <div dir="auto">7) apply any build fixups (turn of intel generators for versions >= 7.5,</div> <div dir="auto">for example</div> <div dir="auto">8) maintain that branch with build and critical bug fixes only</div> <div dir="auto"><br></div> <div dir="auto">This gives ditros and end users two options.</div> <div dir="auto">1) then can build *only* the legacy branch in the a normal Mesa provides</div> <div dir="auto">libGL interfaces fashion</div> <div dir="auto">2) They can use glvnd and install current mesa and the legacy branch in</div> <div dir="auto">parallel</div> <div dir="auto"><br></div> <div dir="auto">Because of glvnd, we can control which driver will get loaded first, and</div> <div dir="auto">thus if we decide i915g or the i965 replacement is ready and turn it on</div> <div dir="auto">by default it will be loaded by default. An end user who doesn't like</div> <div dir="auto">this can add a new glvnd loader file that makes the classic drivers</div> <div dir="auto">higher precident and continue to use them.</div> <div dir="auto"><br></div> <div dir="auto">Why fork from 21.1 instead of master?</div> <div dir="auto"><br></div> <div dir="auto">First, it allows us to delete classic immediately, which will allow</div> <div dir="auto">refactoring to happen earlier in the cycle, and for any fallout to be</div> <div dir="auto">caught and hopefully fixed before the release. Second, it means that</div> <div dir="auto">when a user is switched from 21.1 to the new classic-lts branch, there</div> <div dir="auto">will be no regressions, and no one has to spend time figuring out what</div> <div dir="auto">broke and fixing the lts branch.</div> <div dir="auto"><br></div> <div dir="auto">When you say "build and critical bug fixes", what do you mean?</div> <div dir="auto"><br></div> <div dir="auto">I mean update Meson if we rely on something that in the future is</div> <div dir="auto">deprecated and removed, and would prevent building the branch or an</div> <div dir="auto">relying on some compiler behavior that changes, gaping exploitable</div> <div dir="auto">security holes, that kind of thing.</div> <div dir="auto"><br></div> <div dir="auto">footnotes</div> <div dir="auto">¹Or whatever color you like your bikeshed</div> </blockquote> <div dir="auto"><br></div> <div dir="auto">Hi Dylan,</div> <div dir="auto"><br></div> <div dir="auto">I largely like this plan. i915 and r200 and novueau_vieux definitely</div> <div dir="auto">need to be forked off, to keep them working as we do core refactors.</div> <div dir="auto"><br></div> <div dir="auto">In the past, we weren't working on core much, and so they largely kept</div> <div dir="auto">working with some pain, but not -too- much effort. But these days,</div> <div dir="auto">we're seeing a lot of work from Marek and others to clean up and rework</div> <div dir="auto">a lot of core drawing code, state upload code, and so on. I remember</div> <div dir="auto">all the work Tim did to rework uniform handling and ancient classic was</div> <div dir="auto">a pain point for him as well. I had to track down like 5 overlapping</div> <div dir="auto">Piglit regressions on i915 this release cycle, just to get the driver</div> <div dir="auto">working...no worse than it was before. And i915 is tested regularly</div> <div dir="auto">in the Intel CI. r200 isn't tested regularly. Doubtful about vieux.</div> <div dir="auto"><br></div> <div dir="auto">I had thought about also forking other old drivers like i915g or r300g.</div> <div dir="auto">But it sounds like there's still some interest in i915g, and those</div> <div dir="auto">tend to get fixed up as the Gallium infrastructure is still actively</div> <div dir="auto">being maintained (unlike things like swrast and tnl). So I guess we</div> <div dir="auto">can leave those in mainline.</div> <div dir="auto"><br></div> <div dir="auto">I'm hesitant about i965. One thing I will say is that, if i965 is</div> <div dir="auto">included in the plan, there would probably be more interest in working</div> <div dir="auto">on that branch than mere "critical bug fixes" as you defined. We might</div> <div dir="auto">discover new games that don't work; people might write bug fixes for</div> <div dir="auto">i965, at which point we should merge and ship them. But we could still</div> <div dir="auto">do on-demand releases when enough interesting bug fixes have piled up,</div> <div dir="auto">rather than doing them on a schedule. That should hopefully not be</div> <div dir="auto">too burdensome.</div> <div dir="auto"><br></div> <div dir="auto">While a part of me hates the idea of forking i965 off, I think it may</div> <div dir="auto">actually be the best call. We haven't done any new interesting feature</div> <div dir="auto">development on those platforms in ages, and they're complete in terms of</div> <div dir="auto">OpenGL spec support. We aren't spending any time optimizing performance</div> <div dir="auto">on those platforms. They're pretty much in bug-fix-only mode already.</div> <div dir="auto">Whether that bug fixing happens on master or on a "classic-lts" branch</div> <div dir="auto">doesn't matter; it should be basically the same for our users.</div> <div dir="auto"><br></div> <div dir="auto">I think the best thing for users of those platforms would be for us to</div> <div dir="auto">finish the new Gallium driver and re-add support to mainline. The new</div> <div dir="auto">Gallium driver would have massively better CPU overhead, gain all the</div> <div dir="auto">new core infrastructure improvements we're making, and also add OpenGL</div> <div dir="auto">compatibility profile support. i965...isn't ever going to get most of</div> <div dir="auto">those, even if it stays in tree. Your glvnd plan already handles this</div> <div dir="auto">nicely - when crocus is ready, it can use that instead.</div> <div dir="auto"><br></div> <div dir="auto">Removing classic and i965 would be great for the other active driver</div> <div dir="auto">developers, as radeonsi/nouveau/panfrost/freedreno/etnaviv/lima/...</div> <div dir="auto">could receive new optimizations as we remove extra layers that add</div> <div dir="auto">overhead. That's great for users of those newer GPUs.</div> <div dir="auto"><br></div> <div dir="auto">...</div> <div dir="auto"><br></div> <div dir="auto">One extra thought: can we also fork off anv Gen7.x support at the same</div> <div dir="auto">time? If distros are already going to be building i965 for Gen7.x from</div> <div dir="auto">that branch, building Vulkan from there should be easy as well.</div></blockquote></div><div dir="auto"><br></div><div dir="auto">I'm not sure how I feel about that one. Here are some thoughts:</div><div dir="auto"><br></div><div dir="auto"> 1. I'd love to have it out of the way</div><div dir="auto"> 2. Unlike i965, it is still picking up features. Part of what makes dropping i965 a reasonable idea is that OpenGL is also in maintenance mode. Vulkan isn't.</div><div dir="auto"> 3. Generally, things are architected well enough that relocations aren't a problem.</div><div dir="auto"> 4. Being able to always do batch chaining would be nice.</div><div dir="auto"> 5. The only new feature still in development for i965 is GL_EXT_external_objects. That would be more reliable if Gen7 ANV and i965 were in the same branch.</div><div dir="auto"> 6. If crocus gets <span style="font-family: sans-serif; font-size: 12pt;">GL_EXT_external_objects, it'll be better if Gen7 ANV is in the master branch.</span></div><div dir="auto"> 7. I'd love to stop caring about vec4.</div><div dir="auto"><br></div><div dir="auto">Where does that leave us? 🤷 On the balance, I think we should leave it in master for now. We can always forklift latest Gen7 ANV into the LTS branch later if we want to. There isn't nearly as much shared infrastructure that's likely to diverge problematically. There's also always the option of forking ANV in-tree if we want to get Gen7 out of the way.</div><div dir="auto"><br></div><div dir="auto">They one thing I could see happening that would make dropping Gen7 substantially more attractive is if Vulkan moves in such a direction that bindless becomes a hard requirement. But that would drop Gen8 as well.</div><div dir="auto"><br></div><div dir="auto">--Jason</div><div dir="auto"><br></div><div dir="auto"><br></div><div id="aqm-original" style="color: black;" dir="auto"><blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"><div dir="auto"></div> <div dir="auto">Jason and I have been talking about requiring softpin on Gen8+ in MR</div> <div dir="auto">!4431. I have absolutely no regrets about making iris softpin-only;</div> <div dir="auto">it's been so much simpler and easier to work with. anv still has a ton</div> <div dir="auto">of leftover complexity from supporting relocations for Gen7.x - and IMO</div> <div dir="auto">it's actually more complex than the support in i965 ever was. We could</div> <div dir="auto">clean up a lot of cruft---and reduce the CPU overhead of the driver---if</div> <div dir="auto">we split it off. The timeframes align---we were going to drop relocs</div> <div dir="auto">on Gen8+ after 21.1 forked. If we forked Gen 7.x, we could just drop</div> <div dir="auto">them altogether. It would be so nice.</div> <div dir="auto"><br></div> <div dir="auto">--Ken</div> <div dir="auto"><br></div> <div dir="auto"><br></div> <div dir="auto"><br></div> <div dir="auto">----------</div> <div dir="auto">_______________________________________________</div> <div dir="auto">mesa-dev mailing list</div> <div dir="auto">mesa-dev@lists.freedesktop.org</div> <div dir="auto">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</div> </blockquote> </div><div dir="auto"><br></div> </div></body> </html>