Dmitry Osipenko <dmitry.osipe...@collabora.com> writes: > 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.
I can't see any reference in the buildroot recipes. What is your mesa's build flags? > > .. >>>> 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. -- Alex Bennée Virtualisation Tech Lead @ Linaro
