[virglrenderer-devel] multiprocess model and GL

[Frank Yang]

What's been decided or host coherent non-exportable Vulkan memory then? I
was imagining this sequence of events:

1. vkAllocateMemory in guest -> a corresponding (maybe not 1:1)
vkAllocateMemory on host
2. the host virtual address is now known (as opposed to the fd or host OS
handle for exportables)
3. run ioctl resource_create_v2 with some fields to name that the memory is
on host and already allocated along with its address
4. the guest then maps that HVA into PCI, and mmaps it into the userspace
process

I'd like to see if the the new ioctls can interop w/ the android emulator
vk host coherent memory impl (
https://android.googlesource.com/device/generic/goldfish-opengl/+/refs/heads/master/system/vulkan_enc/ResourceTracker.cpp#2036);
once we have that then we can run the android emulator vulkan
implementation as a normal virtio-gpu sub-device


On Mon, Jan 27, 2020 at 4:36 PM Gurchetan Singh <gurchetansingh at chromium.org>
wrote:

> On Mon, Jan 27, 2020 at 1:54 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
> >
> >   Hi,
> >
> > > > And, no, "just pass though an args blob" isn't an valid answer.
> > >
> > > Can you be a bit more specific here?
> > >
> > > I feel like this is a stylistic issue rather than a technical one.
> > > Given the range of host allocator capabilities and the fact the
> > > kernel/QEMU just needs to know the size + caching properties + memory
> > > type (guest storage, host storage), it seemed reasonable not to expose
> > > such details.
> >
> > Those details still need to be defined, and "an args blob" clearly isn't
> > that.
> >
> > Not including the details in the virtio specification is fine, but we
> > need a *reference* to the details then.
> >
> > We basically do the same with the execbuffer format.  That is defined by
> > mesa and virglrenderer instead of being written down as part of the
> > virtio-gpu spec.
> >
> > In case you want keep the door open to change the format/content of the
> > allocator args blob we also need some plan for backward compatibility,
> > using a capset for example.
>
> Yes, of course.  That's what the demo implementation does:
>
>
> https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/303/diffs?commit_id=0a2461e33a3b9c40339a6fdc09da29d5ba358850
>
> The source of truth of the resource creation/sharing protocol will
> live inside virglrenderer, just like EXECBUFFER.  Obviously, lots of
> clean-ups need to be done and it needs to be reviewed by virglrenderer
> devs.
>
> Note: Moving the header to virtgpu_drm.h/virtio_gpu.h interface could
> be done, if you think that's warranted.  It'll make versioning/struct
> chaining a little tougher though...
>
> >
> > cheers,
> >   Gerd
> >
> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/virglrenderer-devel/attachments/20200127/e040c6c0/attachment.htm>