[virglrenderer-devel] coherent memory access for virgl

[Tomeu Vizoso]

Hi there,

it's maybe not just me who finds this thread a bit overwhelming, so I 
thought I'd try to summarize what has been discussed to date about the 
presentation of Wayland clients in the host (leaving out coherent buffers 
and texture upload optimization).

* Presentation protocol data is passed between the guest and host with 
VSOCK (which doesn't support FD passing).

* There's a Wayland proxy in the guest and another in the host (probably 
in the same process that implements the virtio-gpu device).

* wl_shm doesn't _need_ to be bridged across domains. Instead, the proxy 
in the guest can intercept wl_shm messages and implement it in terms of 
wl_dmabuf. Data would be copied from the SHM buffer to the dmabuf at the 
appropriate times. In many scenarios this is a worthy trade-off.

* dmabufs for presentation refer to virtio-gpu resources in the guest, 
and in the host to BOs created by whatever graphics driver is used there 
(i915, amdgpu, etc).

* virtio-gpu resource IDs are placed by the guest proxy in the wl_dmabuf 
protocol stream instead of (guest) dmabuf FDs. The proxy in the host 
replaces those to the corresponding (host) dmabuf FD.

* When the guest maps one of such dmabufs (with gbm_bo_map), the VMM will 
map the host dmabuf (with gbm_bo_map again) and make that buffer 
available to the guest via a PCI BAR. virtio-gpu will be able to relate 
the new PCI BAR to an existing resource. Guest userspace gets an address 
where the PCI BAR was mapped and also a stride, as that's sometimes only 
known after the actual mapping has happened.

* There's a tradeoff to be made between allocating a PCI BAR per 
presentation buffer, or allocating big ones upfront and managing 
individual buffers within it.

* Some extension to the wl_dmabuf protocol may be needed to allow guests 
know what's the best way of allocating a buffer that the whole pipeline 
supports. An event will be probably needed because this information 
changes over time.

* For pipe FDs in protocols such as  wl_data_offer, the proxy in the side 
that created the pipe can splice the data with new VSOCK sockets.

What have I got wrong or missed?

Thanks,

Tomeu



On 10/3/18 5:56 AM, Gurchetan Singh wrote:
> On Mon, Oct 1, 2018 at 10:38 PM Gerd Hoffmann <kraxel at redhat.com> wrote:
>>
>>    Hi,
>>
>>>>> For example, on some ARM devices, AFBC can be only used on the (host)
>>>>> primary KMS plane.
>>>>
>>>> What is AFBC?  Some drm format modifier?
>>>
>>> Yes, it stands for ARM frame buffer compression and it's widely used
>>> on that architecture.
>>
>> Speaking of compression:  How does buffer size calculation and buffer
>> allocation work in case compression is used?
> 
> There's a header + compressed data or an auxiliary buffer.  Here are
> some examples:
> 
> https://chromium.googlesource.com/chromiumos/platform/minigbm/+/master/rockchip.c#33
> https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/intel_screen.c#n735
> 
>>
>>> Speaking of reallocation, the current Linux modifier API
>>> (gbm_bo_create_with_modifiers) passes in a list of supported modifiers
>>> for gbm to allocate from.  Assuming we do think of a way to notify the
>>> guest about the available KMS-supported modifiers, any new allocation
>>> ioctl will probably need to pass the modifier list to the host.
>>
>> How does mesa handle modifiers?  Does it use the drm modifiers directly?
>> Or has mesa/gallium its own naming scheme?
>>
>> Right now the format specification used by virtio is based on gallium
>> formats ...
> 
> The modifiers are from DRM, and drm_fourcc.h is considered the source
> of truth (I guess that's where some of the problems with v4l2
> integration arise).
> 
> Anyways, here are the conclusions that I can discern from this discussion:
> 
> 1) Host mapped memory should be fine, as long it's optional for the VMM
> 2) Texture uploads can be improved.  BTW, what's the benefit of
> udmabuf over an iov with one element for say a 5-level texture?
> 3) Coherent memory ioctl needed for Vulkan/gl4.5
> 4) The new ioctl should take into account format modifiers
> 5) The DRM_VIRTGPU_RESOURCE_INFO needs to be fixed and expanded for
> (1), (3) and (4)
> 6) There's no clear path forward on how to pipe host display
> information to the guest, such that the guest can know which modifier
> is the best.  Hopefully, the wayland proxying Collabora is working on
> can clear this up..
> 
> Let me know if anything is incorrect, since we may start implementing
> (1) and (2) for performance reasons ;-)
> 
>>
>> cheers,
>>    Gerd
>>
> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>