Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko <dmitry.osipenko@collabora.com>]

On 2/17/25 18:22, Alex Bennée wrote:
...
>> This VK_KHR_display problem is only reproducible with your rootfs that
>> you shared with me. It could be a trouble with your build configs or a
>> buggy package version used by your rootfs build, more likely the
>> former.
> So you have built that latest vkmark? This is a recent addition to
> vkmark for the 2025.1 release.

Yes, latest 2025.1 from git/master.

> Does vulkaninfo --summary show the extension available for you? It is
> certainly available on the host side:
> 
> VK_KHR_display                         : extension revision 23
> 

Have it on guest with my rootfs, not with yours. I'd suspect problem is
with the your Mesa build flags, maybe you haven't enabled necessary
flags related to WSI.

..
>>> With drm_native I get a lot of stutter while running and barely 100FPS
>>> (compared to ~8000 on pure venus). IMHO we need to figure out why there
>>> is such a discrepancy before merging because currently it makes more
>>> sense to use 
>> If you'd run with Xorg/Wayland directly without a DE, then it should
>> work okay. This should be a problem with unmapping performance that I'm
>> thinking about.
>>
>> That unmapping problem is partially understood. Unmapping code works
>> correctly, but we'll need to optimize the flatview code to perform
>> unmapping immediately.
> Why immediately? Surely if we are unmapping we can defer it. Or is this
> a case of having stale mappings making the life of new allocations
> harder?

Unmapping currently works synchronously for virtio-gpu in QEMU, hence
deferring it blocks whole virtio-gpu up to 100+ ms. And if multiple
unmappings are done in a row, then it's 100ms multiplied by the number
of unmappings.

-- 
Best regards,
Dmitry