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

[Timothy Arceri]

On 4/12/19 3:45 pm, Jason Ekstrand wrote:
> On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie <airlied at gmail.com 
> <mailto:airlied at gmail.com>> wrote:
> 
>     On Wed, 4 Dec 2019 at 10:39, Marek Olšák <maraeo at gmail.com
>     <mailto:maraeo at gmail.com>> 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.
> 
> 
> I'm usually the first person to tell people to stop mucking about with 
> old hardware and I fear even I think this would be a bit premature.  
> We've not turned iris on by default yet and I'd really like it to bake 
> as the default distro driver for a while (maybe a year) before we put 
> i965 on life-support.  If we were having this discussion in another 
> year's time, I might be in favor of this but, as it currently stands, 
> I'm not sure this is a good idea.
> 
>      > 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.
> 
> 
> I really don't like this option.  For one thing, this means two copies 
> of code that will get out-of-sync.  If we had the classic drivers in 
> their own branch, we could at least cherry-pick bugfixes back to the 
> classic branch.  However, if we have two copies of everything, our 
> version control tool can't help us.
> 
> The bigger problem is headers.  Currently, the GLSL compiler includes 
> mtypes.h so we would need to somehow separate the GLSL compiler out from 
> src/mesa/main because we'll have two mtypes.h files.  Unfortunately, 
> GLSL isn't the only thing that includes stuff from src/mesa/main.  Our 
> header situation has been a disaster for years and I'm afraid it hasn't 
> gotten any better with the addition of src/util.  Most people who move 
> stuff don't actually do due diligence to keep the includes clean and the 
> result is that I'm pretty sure even the Vulkan drivers are including 
> src/mesa/main/imports.h.  If we have two copies of src/mesa/main and the 
> headers begin to diverge, it's going to be a total disaster.  I would 
> love to see someone clean this all up properly and I think Mesa would be 
> better for it.  However, it is a LOT of work.
> 
> If we did the above cleaning, would I be ok with this approach?  
> Possibly.  However, I suspect it'd end up being the worst of both 
> worlds.  We still have maintenance of effectively two branches and 
> bugfixes have to be ported.  At the same time, we'd still have core 
> changes to things like the GLSL compiler breaking old drivers so we 
> wouldn't lighten any of the maintenance burden.
> 
>      > Option 2 is more acceptable to people who want to keep classic
>     drivers in the tree and it can be done right now.
> 
>     These both seem pretty horrible to me right now. Like i965 still
>     supports a lot of hardware that exists right now even if we move to
>     iris.
> 
> 
> I'm less concerned about the support burden.  When it comes to bugfixes, 
> I feel like most of the bugs on gen7 and earlier hardware at this point 
> are due to churn in the core and if it lives in a maintenance branch, 
> we'll stop breaking it.  The biggest thing we'd loose would be 
> additional features that we might get thanks to core changes.  The major 
> ones that come to mind are:
> 
>   - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we 
> haven't due to a lack of testing) >   - GL_EXT_direct_state_access (still underway last I knew)

Is already done and enabled for compat profile.

>   - GL_EXT_gpu_shader4

Core mesa parts are done for this also.

>   - Compat context support

radeonsi, nouveau and iris all fully enable this. At this point its just 
a driver/classic issue to add support. So as with the two other features 
above options 1 or 2 will not change the fate of this support.

> 
> All four of those are more-or-less software-only features that older 
> intel drivers could pick up as the core advances.  Compat support likely 
> requires a bit of driver work but it should be doable.
> 
> The real question is, "How much do we care?"  I can't say I like the 
> idea of leaving Gen4-7 out in the cold.  Again, in a year's time, we 
> might have most of the above implemented and then it'd be less of a concern.

As per above its only GL_ARB_gl_spirv that would maybe be impacted by 
any fork, but that doesn't change between now and a year so delaying a 
decision for a year based on this is doesn't seem necessary.

> 
>     I sorta feel there should be a
>     3) make life harder for classic drivers and optimise things more for
>     gallium add more dd.h entrypoints, force the classic drivers to jump
>     through hoops to degallium.
> 
> 
> I'd be interested to see what that would look like.  I'm not actually 
> convinced that it would work if I'm honest.  Part of gluing them 
> together in my mind is deleting dd.h entirely and making the GL state 
> tracker just call gallium stuff.
> 
> There may be a 4th option here: Write a gallium driver for Intel 
> Gen4-7.  Unfortunately, it would be a really hard sell to convince 
> anyone (myself included) that this is worth anyone's time.  Sure, it 
> might be a fun project, but the engineering effort required to get it to 
> be as good as i965 is very non-trivial.  I think it's tractable and 
> someone who knows what they're doing would probably be able to get 
> something working in less than a year if they steal heavily from i965 
> and iris.  However, getting it to the point where performance is no 
> worse may take longer.  While it'd probably be a fun project for 
> someone, I can't in good conscience say that the mesa/main refactoring 
> possibilities are enough to justify the effort.
> 
> I'm not saying that's a good option. :-)  I just thought we should 
> enumerate it so that it can be shot down.
> 
> --Jason
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>