Quoting Jason Ekstrand (2019-12-03 20:45:33) > On Tue, Dec 3, 2019 at 8:19 PM Dave Airlie <airl...@gmail.com> wrote: > > On Wed, 4 Dec 2019 at 10:39, Marek Olšák <mar...@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
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
