Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
Daniel Stone <[email protected]>
| Newsgroups | gmane.comp.video.mesa3d.devel |
|---|---|
| Message-ID | <CAPj87rPNTGYLyEu3EV9d251jsaOk97=ZgJWjzEbmeKzx26vA0g@mail.gmail.com> |
On Fri, 26 Jan 2024 at 00:22, Faith Ekstrand <[email protected]> wrote: > On Thu, Jan 25, 2024 at 5:06 PM Gert Wollny <[email protected]> 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