[virglrenderer-devel] vulkan + virgl ioctl vs command submission

[Dave Airlie]

Okay I think I'm following along the mutiprocess model, and the object
id stuff, and I'm mostly coming around to the ideas presented.

One question I have is how do we envisage the userspace vulkan driver
using things.

I kinda feel I'm missing the difference between APIs that access
things on the CPU side and command for accessing things on the GPU
side in the proposal. In the gallium world the "screen" allocates
resources (memory + properties) synchronously on the API being
accessed, the context is then for operating on GPU side things where
we batch up a command stream and it is processed async.

>From the Vulkan API POV the application API is multi-thread safe, and
we should avoid if we can taking too many locks under the covers, esp
in common paths. Vulkan applications are also encouraged to allocate
memory in large chunks and subdivide them between resources.

I'm concerned that we are thinking of batching allocations in the
userspace driver (or in the kernel) and how to flush those to the host
side etc. If we have two threads in userspace allocate memory from the
vulkan API, and one then does a transfer into the memory, how do we
envisage that being flushed to the host side? Like if I allocate
memory in one thread, then create images from that memory in another,
how does that work out?

I don't see what having a command stream for allocating memory is a
good thing here, apart from batching up things that Vulkan really
wants the app to batch up itself anyways.

Hopefully I'm missing something in the previous discussions.

Dave.