Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")

Faith Ekstrand faith at gfxstrand.net
Fri Jan 26 00:20:54 UTC 2024


On Thu, Jan 25, 2024 at 5:06 PM Gert Wollny <gw.fossdev at gmail.com> wrote:

> Hi,
>
> thanks, Faith, for bringing this discussion up.
>
> I think with Venus we are more interested in using utility libraries on
> an as-needed basis. Here, most of the time the Vulkan commands are just
> serialized according to the Venus protocol and this is then passed to
> the host because usually it wouldn't make sense to let the guest
> translate the Vulkan commands to something different (e.g. something
> that is commonly used in a runtime), only to then re-encode this in the
> Venus driver to satisfy the host Vulkan driver -  just think Spir-V:
> why would we want to have NIR only to then re-encode it to Spir-V?
>

I think Venus is an entirely different class of driver. It's not even
really a driver. It's more of a Vulkan layer that has a VM boundary in the
middle. It's attempting to be as thin of a Vulkan -> Vulkan pass-through as
possible. As such, it doesn't use most of the shared stuff anyway. It uses
the dispatch framework and that's really about it. As long as that code
stays in-tree roughly as-is, I think Venus will be fine.


> I'd also like to give a +1 to the points raised by Triang3l and others
> about the potential of breaking other drivers. I've certainly be bitten
> by this on the Gallium side with r600, and unfortunately I can't set up
> a CI in my home office (and after watching the XDC talk about setting
> up your own CI I was even more discouraged to do this).
>

That's a risk with all common code. You could raise the same risk with NIR
or basically anything else. Sure, if someone wants to go write all the code
themselves in an attempt to avoid bugs, I guess they're free to do that. I
don't really see that as a compelling argument, though. Also, while you
experienced gallium breakage with r600, having worked on i965, I can
guarantee you that that's still better than maintaining a classic
(non-gallium) GL driver. 🙃

At the moment, given the responses I've seen and the scope of the project
as things are starting to congeal in my head, I don't think this will be an
incremental thing where drivers get converted as we go anymore. If we
really do want to flip the flow, I think it'll be invasive enough that
we'll build gallium2 and then people can port to it if they want. I may
port a driver or two myself but those will be things I own or am at least
willing to deal with the bug fallout for. Others can port or not at-will.

This is what I meant when I said elsewhere that we're probably heading
towards a gallium/classic situation again. I don't expect anyone to port
until the benefits outweigh the costs but I do expect the benefits will be
there eventually.

~Faith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20240125/62ad911c/attachment.htm>


More information about the mesa-dev mailing list