On Tue, Mar 23, 2021 at 8:39 AM Kenneth Graunke <kenn...@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 <kenn...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
