On Wed, Jan 24, 2024 at 12:26 PM Zack Rusin <zack.ru...@broadcom.com> wrote: > > 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.
Well, I've built my entire career out of doing things that others said were a terrible idea until after I'd done them and proved they were actually a good idea, so... Not too worried about that one. 😉 ~Faith
