[Mesa-dev] [RFC] Concrete proposal to split classic

Tue Mar 23 13:28:23 UTC 2021

On March 23, 2021 01:46:54 Kenneth Graunke <kenneth at whitecape.org> wrote:

> On Monday, March 22, 2021 3:15:30 PM PDT Dylan Baker wrote:
>> Hi list,
>>
>> We've talked about it a number of times, but I think it's time time to
>> discuss splitting the classic drivers off of the main development branch
>> again, although this time I have a concrete plan for how this would
>> work.
>>
>> First, why? Basically, all of the classic drivers are in maintanence
>> mode (even i965). Second, many of them rely on code that no one works
>> on, and very few people still understand. There is no CI for most of
>> them, and the Intel CI is not integrated with gitlab, so it's easy to
>> unintentionally break them, and this breakage usually isn't noticed
>> until just before or just after a release. 21.0 was held up (in small
>> part, also me just getting behind) because of such breakages.
>>
>> I konw there is some interest in getting i915g in good enough shape that
>> it could replace i915c, at least for the common case. I also am aware
>> that Dave, Ilia, and Eric (with some pointers from Ken) have been
>> working on a gallium driver to replace i965. Neither of those things are
>> ready yet, but I've taken them into account.
>>
>> Here's the plan:
>>
>> 1) 21.1 release happens
>> 2) we remove classic from master
>> 3) 21.1 reaches EOL because of 21.2
>> 4) we fork the 21.1 branch into a "classic-lts"¹ branch
>> 5) we disable all vulkan and gallium drivers in said branch, at least at
>> the Meson level
>> 6) We change the name and precidence of the glvnd loader file
>> 7) apply any build fixups (turn of intel generators for versions >= 7.5,
>> for example
>> 8) maintain that branch with build and critical bug fixes only
>>
>> This gives ditros and end users two options.
>> 1) then can build *only* the legacy branch in the a normal Mesa provides
>> libGL interfaces fashion
>> 2) They can use glvnd and install current mesa and the legacy branch in
>> parallel
>>
>> Because of glvnd, we can control which driver will get loaded first, and
>> thus if we decide i915g or the i965 replacement is ready and turn it on
>> by default it will be loaded by default. An end user who doesn't like
>> this can add a new glvnd loader file that makes the classic drivers
>> higher precident and continue to use them.
>>
>> Why fork from 21.1 instead of master?
>>
>> First, it allows us to delete classic immediately, which will allow
>> refactoring to happen earlier in the cycle, and for any fallout to be
>> caught and hopefully fixed before the release. Second, it means that
>> when a user is switched from 21.1 to the new classic-lts branch, there
>> will be no regressions, and no one has to spend time figuring out what
>> broke and fixing the lts branch.
>>
>> When you say "build and critical bug fixes", what do you mean?
>>
>> I mean update Meson if we rely on something that in the future is
>> deprecated and removed, and would prevent building the branch or an
>> relying on some compiler behavior that changes, gaping exploitable
>> security holes, that kind of thing.
>>
>> footnotes
>> ¹Or whatever color you like your bikeshed
>
> Hi Dylan,
>
> I largely like this plan.  i915 and r200 and novueau_vieux definitely
> need to be forked off, to keep them working as we do core refactors.
>
> In the past, we weren't working on core much, and so they largely kept
> working with some pain, but not -too- much effort.  But these days,
> we're seeing a lot of work from Marek and others to clean up and rework
> a lot of core drawing code, state upload code, and so on.  I remember
> all the work Tim did to rework uniform handling and ancient classic was
> a pain point for him as well.  I had to track down like 5 overlapping
> Piglit regressions on i915 this release cycle, just to get the driver
> working...no worse than it was before.  And i915 is tested regularly
> in the Intel CI.  r200 isn't tested regularly.  Doubtful about vieux.
>
> I had thought about also forking other old drivers like i915g or r300g.
> But it sounds like there's still some interest in i915g, and those
> tend to get fixed up as the Gallium infrastructure is still actively
> being maintained (unlike things like swrast and tnl).  So I guess we
> can leave those in mainline.
>
> I'm hesitant about i965.  One thing I will say is that, if i965 is
> included in the plan, there would probably be more interest in working
> on that branch than mere "critical bug fixes" as you defined.  We might
> discover new games that don't work; people might write bug fixes for
> i965, at which point we should merge and ship them.  But we could still
> do on-demand releases when enough interesting bug fixes have piled up,
> rather than doing them on a schedule.  That should hopefully not be
> too burdensome.
>
> While a part of me hates the idea of forking i965 off, I think it may
> actually be the best call.  We haven't done any new interesting feature
> development on those platforms in ages, and they're complete in terms of
> OpenGL spec support.  We aren't spending any time optimizing performance
> on those platforms.  They're pretty much in bug-fix-only mode already.
> Whether that bug fixing happens on master or on a "classic-lts" branch
> doesn't matter; it should be basically the same for our users.
>
> I think the best thing for users of those platforms would be for us to
> finish the new Gallium driver and re-add support to mainline.  The new
> Gallium driver would have massively better CPU overhead, gain all the
> new core infrastructure improvements we're making, and also add OpenGL
> compatibility profile support.  i965...isn't ever going to get most of
> those, even if it stays in tree.  Your glvnd plan already handles this
> nicely - when crocus is ready, it can use that instead.
>
> Removing classic and i965 would be great for the other active driver
> developers, as radeonsi/nouveau/panfrost/freedreno/etnaviv/lima/...
> could receive new optimizations as we remove extra layers that add
> overhead.  That's great for users of those newer GPUs.
>
> ...
>
> One extra thought: can we also fork off anv Gen7.x support at the same
> time?  If distros are already going to be building i965 for Gen7.x from
> that branch, building Vulkan from there should be easy as well.

I'm not sure how I feel about that one. Here are some thoughts:

 1. I'd love to have it out of the way
 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.
 3. Generally, things are architected well enough that relocations aren't a 
problem.
 4. Being able to always do batch chaining would be nice.
 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.
 6. If crocus gets GL_EXT_external_objects, it'll be better if Gen7 ANV is 
in the master branch.
 7. I'd love to stop caring about vec4.

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.

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.

--Jason

> Jason and I have been talking about requiring softpin on Gen8+ in MR
> !4431.  I have absolutely no regrets about making iris softpin-only;
> it's been so much simpler and easier to work with.  anv still has a ton
> of leftover complexity from supporting relocations for Gen7.x - and IMO
> it's actually more complex than the support in i965 ever was.  We could
> clean up a lot of cruft---and reduce the CPU overhead of the driver---if
> we split it off.  The timeframes align---we were going to drop relocs
> on Gen8+ after 21.1 forked.  If we forked Gen 7.x, we could just drop
> them altogether.  It would be so nice.
>
> --Ken
>
>
>
> ----------
> _______________________________________________
> 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/20210323/93eda45b/attachment.htm>