[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mesa3d-dev
Subject:    Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
From:       Daniel Stone <daniel () fooishbar ! org>
Date:       2024-01-26 9:23:50
Message-ID: CAPj87rPNTGYLyEu3EV9d251jsaOk97=ZgJWjzEbmeKzx26vA0g () mail ! gmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]