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

[Dylan Baker]

Quoting Jason Ekstrand (2019-12-03 20:45:33)
> On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie <airlied at gmail.com> wrote:
> 
>     On Wed, 4 Dec 2019 at 10:39, Marek Olšák <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.

I have an MR that's been sitting on the list for over a year that remove
imports.h completely. I can rebase that today.

> 
> 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)
>  - GL_EXT_gpu_shader4
>  - Compat context 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.
>  
> 
>     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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20191204/4ad61544/attachment.sig>