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
