[virglrenderer-devel] multiprocess model and GL

[Gurchetan Singh]

On Mon, Jan 27, 2020 at 4:51 PM Frank Yang <lfy at google.com> wrote:
>
> 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

We definitely want to support that case.  In V2 model, I think you'd
use the MAP_DIRECTLY_BIT | HOST_VISIBLE_BIT (but not the
HOST_SHAREABLE_BIT).  Your args would contain something like
VIRTGPU_STRUCTURE_TYPE_BIND_CLIENT_ID since you allocated the resource
before hand.

Latest UAPI:

https://gitlab.freedesktop.org/virgl/drm-misc-next/blob/virtio-gpu-next/include/uapi/drm/virtgpu_drm.h#L186

Highlights:

* cache flags on RESOURCE_MAP for validation, as kraxel suggested
* exportable bit renamed shareable bit, as olv suggested
* MAP_DIRECTLY bit added, so we can do INIT + ALLOC + MAP.  I think
this is valid virtualization, since GEM drivers remap their PCI bar on
creation as well.

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