Advice on modifying Lavapipe to isolate JIT compilation in separate process

[Josh Gargus]

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.

"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.

Another important goal is to make these changes in a way that is
upstreamable to Mesa.

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).

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.

Rather than delve into such minutiae, I'll simply ask how you recommend
approaching this problem.  Again, the two main constraints are:
- no JITing code in the client process
- clean enough solution to be upstreamable

Thanks in advance,
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20230426/0ce0c6b9/attachment.htm>