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

Jason Ekstrand jason at jlekstrand.net
Tue Mar 23 15:30:20 UTC 2021


On Tue, Mar 23, 2021 at 8:39 AM Kenneth Graunke <kenneth at whitecape.org> wrote:
>
> On Tuesday, March 23, 2021 6:28:23 AM PDT Jason Ekstrand wrote:
> > On March 23, 2021 01:46:54 Kenneth Graunke <kenneth at whitecape.org> wrote:
> [snip]
> > > 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.
>
> Point 2 is true.  I'm not sure I agree about 3, the anv execbuf handling
> is a lot more complicated than I think it needs to be.

It's not great, I'll grant.  But it's not too awful and, until we get
rid of VM_BIND, we have to at least keep BO usage tracking even if we
were able to drop relocations.

> It would be really nice to cull vec4 and MRF support from the compiler
> as well---and all of the vec4/fs code sharing and base classes.  That
> would be really nice.  But, I guess that if crocus comes into existence,
> then we need all that again.  That's unfortunate :(

Me too.  There is some stuff I think we can drop.  We can drop
shader_time, for instance, as well as the param array and all the push
constant re-arranging code.

And, yeah, I'd love to drop vec4 but yeah...  One advantage to keeping
vec4 in the tree for some stuff is that it means we have full-featured
hardware able to test vec4 NIR.  That seems like a feature.

--Jason


More information about the mesa-dev mailing list