On Thu, Jan 25, 2024 at 5:06 PM Gert Wollny 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 pr
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 w
On 24/01/2024 18:26, Faith Ekstrand wrote:
> So far, we've been trying to build those components in terms of the
> Vulkan API itself with calls jumping back into the dispatch table to
> try and get inside the driver.
To me, it looks like the "opt-in" approach would still be well-applicable
to th
On Thu, Jan 25, 2024 at 8:57 AM Jose Fonseca
wrote:
> > So far, we've been trying to build those components in terms of the
> Vulkan API itself with calls jumping back into the dispatch table to try
> and get inside the driver. This is working but it's getting more and more
> fragile the more too
What is the most proper way to re-route output from a rendering card
(which can have it's output disconnected or don't have it at all) to a
displaying card (weak one, iGPU etc)?
For example, a laptop with an external card in an ExpressCard riser (no
external display is connected to the card), or
> So far, we've been trying to build those components in terms of the
Vulkan API itself with calls jumping back into the dispatch table to try
and get inside the driver. This is working but it's getting more and more
fragile the more tools we add to that box. A lot of what I want to do with
gallium
