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

Daniel Stone daniel at fooishbar.org
Fri Jan 26 09:23:50 UTC 2024


On Fri, 26 Jan 2024 at 00:22, Faith Ekstrand <faith at gfxstrand.net> wrote:
> On Thu, Jan 25, 2024 at 5:06 PM Gert Wollny <gw.fossdev at gmail.com> wrote:
>> 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.

The eternal response: you forgot WSI!

Cheers,
Daniel


More information about the mesa-dev mailing list