<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 25, 2024 at 5:06 PM Gert Wollny <<a href="mailto:gw.fossdev@gmail.com">gw.fossdev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, <br>
<br>
thanks, Faith, for bringing this discussion up. <br>
<br>
I think with Venus we are more interested in using utility libraries on<br>
an as-needed basis. Here, most of the time the Vulkan commands are just<br>
serialized according to the Venus protocol and this is then passed to<br>
the host because usually it wouldn't make sense to let the guest<br>
translate the Vulkan commands to something different (e.g. something<br>
that is commonly used in a runtime), only to then re-encode this in the<br>
Venus driver to satisfy the host Vulkan driver -  just think Spir-V:<br>
why would we want to have NIR only to then re-encode it to Spir-V?<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'd also like to give a +1 to the points raised by Triang3l and others<br>
about the potential of breaking other drivers. I've certainly be bitten<br>
by this on the Gallium side with r600, and unfortunately I can't set up<br>
a CI in my home office (and after watching the XDC talk about setting<br>
up your own CI I was even more discouraged to do this).<br></blockquote><div><br></div><div>That's a risk with all common code. You could raise the same risk with NIR or basically anything else. Sure, if someone wants to go write all the code themselves in an attempt to avoid bugs, I guess they're free to do that. I don't really see that as a compelling argument, though. Also, while you experienced gallium breakage with r600, having worked on i965, I can guarantee you that that's still better than maintaining a classic (non-gallium) GL driver. 🙃<br></div><div><br></div><div>At the moment, given the responses I've seen and the scope of the project as things are starting to congeal in my head, I don't think this will be an incremental thing where drivers get converted as we go anymore. If we really do want to flip the flow, I think it'll be invasive enough that we'll build gallium2 and then people can port to it if they want. I may port a driver or two myself but those will be things I own or am at least willing to deal with the bug fallout for. Others can port or not at-will.</div><div><br></div><div>This is what I meant when I said elsewhere that we're probably heading towards a gallium/classic situation again. I don't expect anyone to port until the benefits outweigh the costs but I do expect the benefits will be there eventually.</div><div><br></div><div>~Faith<br></div></div></div>