Add VIRTIO_GPU_FLAG_FENCE to resource flush command header

[z0Kng]

Problem: Upstream QEMU display corruption
Using the Display-Virtualization-for-Windows-OS with the current upstream QEMU causes display issues as seen in this picture:

I tracked it down to this commit in QEMU: virtio-gpu: Support suspension of commands processing

Proposed Fix
Set the VIRTIO_GPU_FLAG_FENCE in the VIRTIO_GPU_CMD_RESOURCE_FLUSH command, since it already has a fence_id. I am not sure if it was intended to not set this flag or an oversight.

[downor]

Yeah, we know about the commit you mentioned here. This is one of reasons why we recommend to use customized QEMU for our windows use-cases at https://github.com/intel/Intel-distribution-of-QEMU/. This qemu is based off v9.1 (meaning this doesn't contain the commit you mentioned above) + many fixes we added for smoother experiences with our windows VM solution. Please try the branch "9.1.0-gfx-sriov-etm" if you want to try it out.

[z0Kng]

Thanks for pointing out the repo, I'll give it a try. However, we generally want to use upstream for our project. I saw there is a fix for the blackscreen flickering: intel/Intel-distribution-of-QEMU@b1d9d8f but it seems like it will not be upstream soon i guess. In my fork, I fixxed the issue with implementing double buffering in the idd. Is anything similar planned? Should I make a pr for it or are pr even wanted in this project? Either speaking, is it planned to make this upstream compatible or are you trying to get those patches upstream?

[malayaku]

@z0Kng
We’re also working on implementing double buffering. If you’ve already completed it, please share your changes — we’ll verify them to ensure all use cases work as expected or identify if any updates are needed. Based on the results, we’ll decide on the next steps.

[z0Kng]

That's my prototype implementation to test if it works: opensourcevdi@b3dc882, which it did. But if you wan't I can also polish it and make a pr.