On Fri, Apr 12, 2019 at 04:34:20PM -0700, Chia-I Wu wrote: > Hi, > > I am still new to virgl, and missed the last round of discussion about > resource_create_v2. > > From the discussion below, semantically resource_create_v2 creates a host > resource object _without_ any storage; memory_create creates a host memory > object which provides the storage. Is that correct?
Right now all resource_create_* variants create a resource object with host storage. memory_create creates guest storage, and resource_attach_memory binds things together. Then you have to transfer the data. Hmm, maybe we need a flag indicating that host storage is not needed, for resources where we want establish some kind of shared mapping later on. > Do we expect these new commands to be supported by OpenGL, which does not > separate resources and memories? Well, for opengl you need a 1:1 relationship between memory region and resource. > > Yes, even though it is not clear yet how we are going to handle > > host-allocated buffers in the vhost-user case ... > > This might be another dumb question, but is this only an issue for > vhost-user(-gpu) case? What mechanisms are used to map host dma-buf into > the guest address space? qemu can change the address space, that includes mmap()ing stuff there. An external vhost-user process can't do this, it can only read the address space layout, and read/write from/to guest memory. > But one needs to create the resource first to know which memory types can > be attached to it. I think the metadata needs to be returned with > resource_create_v2. There is a resource_info reply for that. > That should be good enough. But by returning alignments, we can minimize > the gaps when attaching multiple resources, especially when the resources > are only used by GPU. We can add alignments to the resource_info reply. cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
