On Wed, Jan 24, 2024 at 10:27 AM Faith Ekstrand <fa...@gfxstrand.net> wrote: > > Jose, > > Thanks for your thoughts! > > On Wed, Jan 24, 2024 at 4:30 AM Jose Fonseca <jose.fons...@broadcom.com> > wrote: > > > > I don't know much about the current Vulkan driver internals to have or > > provide an informed opinion on the path forward, but I'd like to share my > > backwards looking perspective. > > > > Looking back, Gallium was two things effectively: > > (1) an abstraction layer, that's watertight (as in upper layers shouldn't > > reach through to lower layers) > > (2) an ecosystem of reusable components (draw, util, tgsi, etc.) > > > > (1) was of course important -- and the discipline it imposed is what > > enabled to great simplifications -- but it also became a straight-jacket, > > as GPUs didn't stand still, and sooner or later the > > see-every-hardware-as-the-same lenses stop reflecting reality. > > > > If I had to pick one, I'd say that (2) is far more useful and practical. > > Take components like gallium's draw and other util modules. A driver can > > choose to use them or not. One could fork them within Mesa source tree, > > and only the drivers that opt-in into the fork would need to be > > tested/adapted/etc > > > > On the flip side, Vulkan API is already a pretty low level HW abstraction. > > It's also very flexible and extensible, so it's hard to provide a > > watertight abstraction underneath it without either taking the lowest > > common denominator, or having lots of optional bits of functionality > > governed by a myriad of caps like you alluded to. > > There is a third thing that isn't really recognized in your description: > > (3) A common "language" to talk about GPUs and data structures that > represent that language > > This is precisely what the Vulkan runtime today doesn't have. Classic > meta sucked because we were trying to implement GL in GL. u_blitter, > on the other hand, is pretty fantastic because Gallium provides a much > more sane interface to write those common components in terms of. > > So far, we've been trying to build those components in terms of the > Vulkan API itself with calls jumping back into the dispatch table to > try and get inside the driver. This is working but it's getting more > and more fragile the more tools we add to that box. A lot of what I > want to do with gallium2 or whatever we're calling it is to fix our > layering problems so that calls go in one direction and we can > untangle the jumble. I'm still not sure what I want that to look like > but I think I want it to look a lot like Vulkan, just with a handier > interface.
Yes, that makes sense. When we were writing the initial components for gallium (draw and cso) I really liked the general concept and thought about trying to reuse them in the old, non-gallium Mesa drivers but the obstacle was that there was no common interface to lay them on. Using GL to implement GL was silly and using Vulkan to implement Vulkan is not much better. Having said that my general thoughts on GPU abstractions largely match what Jose has said. To me it's a question of whether a clean abstraction: - on top of which you can build an entire GPU driver toolkit (i.e. all the components and helpers) - that makes it trivial to figure up what needs to be done to write a new driver and makes bootstrapping a new driver a lot simpler - that makes it easier to reason about cross hardware concepts (it's a lot easier to understand the entirety of the ecosystem if every driver is not doing something unique to implement similar functionality) is worth more than almost exponentially increasing the difficulty of: - advancing the ecosystem (i.e. it might be easier to understand but it's way harder to create clean abstractions across such different hardware). - driver maintenance (i.e. there will be a constant stream of regressions hitting your driver as a result of other people working on their drivers) - general development (i.e. bug fixes/new features being held back because they break some other driver) Some of those can certainly be titled one way or the other, e.g. the driver maintenance con be somewhat eased by requiring that every driver working on top of the new abstraction has to have a stable Mesa-CI setup (be it lava or ci-tron, or whatever) but all of those things need to be reasoned about. In my experience abstractions never have uniform support because some people will value cons of them more than they value the pros. So the entire process requires some very steadfast individuals to keep going despite hearing that the effort is dumb, at least until the benefits of the new approach are impossible to deny. So you know... "how much do you believe in this approach because some days will suck and you can't give up" ;) is probably the question. z
