<div dir="ltr">What's been decided or host coherent non-exportable Vulkan memory then? I was imagining this sequence of events:<div><br></div><div>1. vkAllocateMemory in guest -> a corresponding (maybe not 1:1) vkAllocateMemory on host</div><div>2. the host virtual address is now known (as opposed to the fd or host OS handle for exportables)</div><div>3. run ioctl resource_create_v2 with some fields to name that the memory is on host and already allocated along with its address</div><div>4. the guest then maps that HVA into PCI, and mmaps it into the userspace process</div><div><br></div><div>I'd like to see if the the new ioctls can interop w/ the android emulator vk host coherent memory impl (<a href="https://android.googlesource.com/device/generic/goldfish-opengl/+/refs/heads/master/system/vulkan_enc/ResourceTracker.cpp#2036">https://android.googlesource.com/device/generic/goldfish-opengl/+/refs/heads/master/system/vulkan_enc/ResourceTracker.cpp#2036</a>); once we have that then we can run the android emulator vulkan implementation as a normal virtio-gpu sub-device<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 27, 2020 at 4:36 PM Gurchetan Singh <<a href="mailto:gurchetansingh@chromium.org">gurchetansingh@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jan 27, 2020 at 1:54 AM Gerd Hoffmann <<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>> wrote:<br>
><br>
>   Hi,<br>
><br>
> > > And, no, "just pass though an args blob" isn't an valid answer.<br>
> ><br>
> > Can you be a bit more specific here?<br>
> ><br>
> > I feel like this is a stylistic issue rather than a technical one.<br>
> > Given the range of host allocator capabilities and the fact the<br>
> > kernel/QEMU just needs to know the size + caching properties + memory<br>
> > type (guest storage, host storage), it seemed reasonable not to expose<br>
> > such details.<br>
><br>
> Those details still need to be defined, and "an args blob" clearly isn't<br>
> that.<br>
><br>
> Not including the details in the virtio specification is fine, but we<br>
> need a *reference* to the details then.<br>
><br>
> We basically do the same with the execbuffer format.  That is defined by<br>
> mesa and virglrenderer instead of being written down as part of the<br>
> virtio-gpu spec.<br>
><br>
> In case you want keep the door open to change the format/content of the<br>
> allocator args blob we also need some plan for backward compatibility,<br>
> using a capset for example.<br>
<br>
Yes, of course.  That's what the demo implementation does:<br>
<br>
<a href="https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/303/diffs?commit_id=0a2461e33a3b9c40339a6fdc09da29d5ba358850" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/303/diffs?commit_id=0a2461e33a3b9c40339a6fdc09da29d5ba358850</a><br>
<br>
The source of truth of the resource creation/sharing protocol will<br>
live inside virglrenderer, just like EXECBUFFER.  Obviously, lots of<br>
clean-ups need to be done and it needs to be reviewed by virglrenderer<br>
devs.<br>
<br>
Note: Moving the header to virtgpu_drm.h/virtio_gpu.h interface could<br>
be done, if you think that's warranted.  It'll make versioning/struct<br>
chaining a little tougher though...<br>
<br>
><br>
> cheers,<br>
>   Gerd<br>
><br>
_______________________________________________<br>
virglrenderer-devel mailing list<br>
<a href="mailto:virglrenderer-devel@lists.freedesktop.org" target="_blank">virglrenderer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel</a><br>
</blockquote></div>