[virglrenderer-devel] coherent memory access for virgl
Tomeu Vizoso
tomeu.vizoso at collabora.com
Fri Oct 5 13:57:01 UTC 2018
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
>
More information about the virglrenderer-devel
mailing list