<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 4 Dec 2019 at 10:39, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Here are 2 proposals to simplify and better optimize the GL->Gallium translation.<br>
><br>
> 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.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Option 2 is more acceptable to people who want to keep classic drivers in the tree and it can be done right now.<br>
<br>
These both seem pretty horrible to me right now. Like i965 still<br>
supports a lot of hardware that exists right now even if we move to<br>
iris.<br></blockquote><div><br></div><div>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:</div><div><br></div><div> - GL_ARB_gl_spirv (It could be enabled on gen7 in theory but we haven't due to a lack of testing)<br></div><div> - GL_EXT_direct_state_access (still underway last I knew)</div><div> - GL_EXT_gpu_shader4</div><div> - Compat context support<br></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I sorta feel there should be a<br>
3) make life harder for classic drivers and optimise things more for<br>
gallium add more dd.h entrypoints, force the classic drivers to jump<br>
through hoops to degallium.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I'm not saying that's a good option. :-) I just thought we should enumerate it so that it can be shot down.</div><div><br></div><div>--Jason<br></div></div></div>