<div dir="ltr">Thanks for your advice!  I hadn't looked at Venus, but that seems like a very promising place to start.<div><br></div><div>The other approach feels more approachable now too; it feels like there are less "unknown unknowns", although there are plenty of known unknowns to investigate (address independence was one that was already bugging be before I wrote to this list).<br></div><div><br></div><div>It seems like Venus is the more straightforward approach, so I'm inclined to just go with it.  However, it seems like there would be a performance hit compared to only doing JIT compilation in a separate process.  Do you have a rough sense of the performance hit of serializing everything over Venus?  The answer will depend on the workload, I know.</div><div><br></div><div>Thanks again, it was very helpful!</div><div><br></div><div>Cheers,</div><div>Josh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 26, 2023 at 7:23 PM Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@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">On Thu, 27 Apr 2023 at 05:27, Josh Gargus <<a href="mailto:jjosh@google.com" target="_blank">jjosh@google.com</a>> wrote:<br>
><br>
> Hi, I'm from the Fuchsia team at Google.  We would like to provide Lavapipe as an ICD within Fuchsia.  However, our default security policy is to deny client apps the capability to map memory as writable/executable; we don't want to relax this for every client app which uses Vulkan.  Therefore, we are investigating the feasibility of splitting "Lavapipe" into two parts, one of which runs in a separate process.<br>
><br>
> "Lavapipe" is in quotes because we don't know quite where the split should be (that's what I'm here to ask you); perhaps it wouldn't be within Lavapipe per se, but instead e.g. somewhere within llvmpipe.<br>
><br>
> Another important goal is to make these changes in a way that is upstreamable to Mesa.<br>
><br>
> We considered a few different options, deeply enough to convince ourselves that none of them seems desirable.  These ranged from proxying at the Vulkan API level (so that almost everything runs in a separate process) to doing only compilation in the separate process (into shared memory that is only executable, not writable, in the client process).<br>
<br>
Have you considered using venus over a socket/pipe to do it at the<br>
vulkan layer? (just asking in case you hadn't).<br>
<br>
><br>
> This exploration was limited by our unfamiliarity with the corner cases of implementing a Vulkan driver.  For example, we're not quite clear on how much code is generated outside of vkCreateGraphics/ComputePipelines().  For example is there any code generated lazily, perhaps at draw time, to optimize texture sampling?  That's just one question we don't know the answer to, and there are surely many other questions we haven't thought to ask.<br>
><br>
> Rather than delve into such minutiae, I'll simply ask how you recommend approaching this problem.  Again, the two main constraints are:<br>
> - no JITing code in the client process<br>
> - clean enough solution to be upstreamable<br>
<br>
So code is generated in a lot of places, particularly at shader bind<br>
and at draw time depending on bound textures/samplers etc. I think<br>
your best bet would be to maybe split a client/server model in the<br>
gallivm layer. gallivm_compile_module to gallivm_jit_function are<br>
where the LLVM executions happen, so you'd have to construct enough of<br>
a standalone gallivm/LLVM environment to take an LLVM module, compile<br>
it, pass back the JITed code in shared memory like you said. I'm not<br>
sure how memory address independent the resulting binaries from llvm<br>
are, or if they have to be placed at the same address. There are also<br>
a bunch of global linkages for various things that have to be hooked<br>
up, so there would need to be some thought around those (debug printf,<br>
coroutine malloc hooks, and clock hook).<br>
<br>
Dave.<br>
</blockquote></div>