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

[Dave Airlie]

Realised you might not be reading the list, or I asked too hard a question :-P

On Tue, 25 Feb 2020 at 12:59, Dave Airlie <airlied at gmail.com> wrote:
>
> 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.