<div dir="auto">Gallium looks like it was just a copy of DX10, and likely many things were known from DX10 in advance before anything started. Vulkanium doesn't have anything to draw inspiration from. It's a completely unexplored idea.<div dir="auto"><br></div><div dir="auto">AMD's PAL is the same idea as Gallium. It's used to implement Vulkan, DX, Mantle, Metal, etc.<div dir="auto"><br></div><div dir="auto">Marek</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 24, 2024, 13:40 Faith Ekstrand <<a href="mailto:faith@gfxstrand.net" target="_blank" rel="noreferrer">faith@gfxstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Wed, Jan 24, 2024 at 12:26 PM Zack Rusin <<a href="mailto:zack.rusin@broadcom.com" rel="noreferrer noreferrer" target="_blank">zack.rusin@broadcom.com</a>> wrote:<br>><br>> On Wed, Jan 24, 2024 at 10:27 AM Faith Ekstrand <<a href="mailto:faith@gfxstrand.net" rel="noreferrer noreferrer" target="_blank">faith@gfxstrand.net</a>> wrote:<br>> ><br>> > Jose,<br>> ><br>> > Thanks for your thoughts!<br>> ><br>> > On Wed, Jan 24, 2024 at 4:30 AM Jose Fonseca <<a href="mailto:jose.fonseca@broadcom.com" rel="noreferrer noreferrer" target="_blank">jose.fonseca@broadcom.com</a>> wrote:<br>> > ><br>> > > 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.<br>> > ><br>> > > Looking back, Gallium was two things effectively:<br>> > > (1) an abstraction layer, that's watertight (as in upper layers shouldn't reach through to lower layers)<br>> > > (2) an ecosystem of reusable components (draw, util, tgsi, etc.)<br>> > ><br>> > > (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.<br>> > ><br>> > > 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<br>> > ><br>> > > 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.<br>> ><br>> > There is a third thing that isn't really recognized in your description:<br>> ><br>> > (3) A common "language" to talk about GPUs and data structures that<br>> > represent that language<br>> ><br>> > This is precisely what the Vulkan runtime today doesn't have. Classic<br>> > meta sucked because we were trying to implement GL in GL. u_blitter,<br>> > on the other hand, is pretty fantastic because Gallium provides a much<br>> > more sane interface to write those common components in terms of.<br>> ><br>> > So far, we've been trying to build those components in terms of the<br>> > Vulkan API itself with calls jumping back into the dispatch table to<br>> > try and get inside the driver. This is working but it's getting more<br>> > and more fragile the more tools we add to that box. A lot of what I<br>> > want to do with gallium2 or whatever we're calling it is to fix our<br>> > layering problems so that calls go in one direction and we can<br>> > untangle the jumble. I'm still not sure what I want that to look like<br>> > but I think I want it to look a lot like Vulkan, just with a handier<br>> > interface.<br>><br>> Yes, that makes sense. When we were writing the initial components for<br>> gallium (draw and cso) I really liked the general concept and thought<br>> about trying to reuse them in the old, non-gallium Mesa drivers but<br>> the obstacle was that there was no common interface to lay them on.<br>> Using GL to implement GL was silly and using Vulkan to implement<br>> Vulkan is not much better.<br>><br>> Having said that my general thoughts on GPU abstractions largely match<br>> what Jose has said. To me it's a question of whether a clean<br>> abstraction:<br>> - on top of which you can build an entire GPU driver toolkit (i.e. all<br>> the components and helpers)<br>> - that makes it trivial to figure up what needs to be done to write a<br>> new driver and makes bootstrapping a new driver a lot simpler<br>> - that makes it easier to reason about cross hardware concepts (it's a<br>> lot easier to understand the entirety of the ecosystem if every driver<br>> is not doing something unique to implement similar functionality)<br>> is worth more than almost exponentially increasing the difficulty of:<br>> - advancing the ecosystem (i.e. it might be easier to understand but<br>> it's way harder to create clean abstractions across such different<br>> hardware).<br>> - driver maintenance (i.e. there will be a constant stream of<br>> regressions hitting your driver as a result of other people working on<br>> their drivers)<br>> - general development (i.e. bug fixes/new features being held back<br>> because they break some other driver)<br>><br>> Some of those can certainly be titled one way or the other, e.g. the<br>> driver maintenance con be somewhat eased by requiring that every<br>> driver working on top of the new abstraction has to have a stable<br>> Mesa-CI setup (be it lava or ci-tron, or whatever) but all of those<br>> things need to be reasoned about. In my experience abstractions never<br>> have uniform support because some people will value cons of them more<br>> than they value the pros. So the entire process requires some very<br>> steadfast individuals to keep going despite hearing that the effort is<br>> dumb, at least until the benefits of the new approach are impossible<br>> to deny. So you know... "how much do you believe in this approach<br>> because some days will suck and you can't give up" ;) is probably the<br>> question.<br><div><br></div><div>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. 😉</div><div><br></div><div>~Faith<br></div></div>
</blockquote></div>