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