<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 7, 2020 at 9:46 AM Chia-I Wu <<a href="mailto:olvaffe@gmail.com">olvaffe@gmail.com</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 Fri, Feb 7, 2020 at 12:14 AM Gerd Hoffmann <<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>> wrote:<br>
><br>
> On Thu, Feb 06, 2020 at 02:13:41PM -0800, Chia-I Wu wrote:<br>
> > I pushed minimal<br>
> ><br>
> > <a href="https://gitlab.freedesktop.org/virgl/drm-misc-next/commits/olv/resource-v4" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/virgl/drm-misc-next/commits/olv/resource-v4</a><br>
> ><br>
> > based on kraxel/memory-v4 that demonstrates only capset and resource<br>
> > creation. The highlights are<br>
> ><br>
> > 1) add VIRTIO_GPU_F_MULTI_RENDERER as a generalization of VIRTIO_GPU_F_VIRGL<br>
><br>
> Why this? I'd prefer F_VULKAN<br>
><br>
> <a href="https://git.kraxel.org/cgit/linux/commit/?h=drm-virtio-memory-v4&id=28f9d1cb04ffe54121202ed9d09352cf4dad27ca" rel="noreferrer" target="_blank">https://git.kraxel.org/cgit/linux/commit/?h=drm-virtio-memory-v4&id=28f9d1cb04ffe54121202ed9d09352cf4dad27ca</a><br>
><br>
> (we probably also want a VIRTIO_GPU_CAPSET_VULKAN)<br>
><br>
> The host then can advertise VIRGL or VULKAN or both ...<br>
The idea is for the feature to provide a set of new commands, which is<br>
the same set of commands provided by F_VIRGL plus blob-related<br>
commands. Then have capsets to define the capabilities for those<br>
commands. This way, it can replace F_VIRGL, F_VULKAN,<br>
F_STORAGE_SHARED, F_STORAGE_HOSTMEM by a single F_MULTI_RENDERER and<br>
three capsets (one for virgl, one for vulkan, and one for itself).<br>
F_VIRGL is kept only for backward compatibility.<br>
<br></blockquote><div><br></div><div>Side note: we recently got resource create v2 + hostmem working with Android Emulator's flavor of vk/gl virtualization. Would it be appropriate/helpful to add another F_<capset> to capture that use case?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Similar to classic resource allocation validation, the kernel does not<br>
validate for blob resource allocation. The userspace uses capsets to<br>
know, for example, if HOSTMEM is supported. The host validates.<br>
<br>
><br>
> > 2) VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB is made more extensible (to the<br>
> > degree that it can support Gurchetan's args[] if we choose to)<br>
><br>
> /me wonders what the point of virtio_gpu_resource_create_blob.virgl is.<br>
> Why not simply continue using CREATE_3D for these use cases? We have to<br>
> keep that anyway for backward compatibility reasons ...<br>
<br>
I think it can be removed. It is more a migration/convenience thingy.<br>
The kernel can internally switch classic resource allocations to use<br>
CREATE_BLOB instead of CREATE_3D. I also planned to use it in mesa<br>
virgl because it provides a migration path and, additionally, it can<br>
do SHARED or HOSTMEM. But I now feel that we should send mesa virgl a<br>
strong signal to migrate to execbuffer instead.<br>
<br>
Two questions. Can 2d and 3d transfers work on blob resources? What<br>
is the plan for guest GBM?<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></div>