On 2/25/21 4:09 AM, Daniel Vetter wrote:
On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini sylphrenadin@gmail.com wrote:
Add a virtual hardware or vblank-less mode as a module to enable VKMS to emulate virtual graphic drivers. This mode can be enabled by setting enable_virtual_hw=1 at the time of loading VKMS.
A new function vkms_crtc_composer() has been added to bypass the vblank mode and is called directly in the atomic hook in vkms_atomic_begin(). However, some crc captures still use vblanks which causes the crc-based igt tests to crash. Currently, I am unsure about how to approach one-shot implementation of crc reads so I am still working on that.
Gerd, Zack: For virtual hw like virtio-gpu or vmwgfx that does one-shot upload and damage tracking, what do you think is the best way to capture crc for validation? Assuming that's even on the plans anywhere ...
Ideally it'd be a crc that the host side captures, so that we really have end-to-end validation, including the damage uploads and all that.
For vkms we're going for now with one-shot crc generation after each atomic flip (or DIRTYFB ioctl call). Will need a pile of igt changes, but seems like the most fitting model. Other option would be that we'd wire up something on the kernel side that generates a crc on-demand every time igt reads a new crc value (maybe with some rate limiting). But that's not really how virtual hw works when everything is pushed explicitly to the host side.
Well, this is a bit tricky. With virtual gpu's the presentation is not necessarily well defined. Technically the presentation might not even happen (i.e. someone disconnected the screen to a running vm), or it could happen on a completely different machine (i.e. someone is remotely running a vm), etc. With recent vmwgfx the guest owns the presentation surface (i.e. screen targets), it's not a big deal to set software cursors and get the host to generate CRC but it's not too different from doing it inside the guest. Realistically we could provide anything, generating CRC's out of some block of memory is trivial and so is putting it in either some register or any dedicated guest memory. It's more about what kind of guarantees we could reasonable provide, or more precisely "what kind of presentation testing could we do for a GL/Vulkan/DX12 app that could be potentially running over vnc".
For us the response to that has basically been "if the screen target memory in guest matches what the app thought it should be then we're done", but one of my pet peeves in our stack has been the difficulty of testing presentation fully so I'd be very excited to hear other ideas.
My guess is that without GL/Vulkan/DX12 extensions which actually expose the underlying CRC info from the display engines we can't really provide very strong guarantees and we won't be able to provide much better support than just sharing the CRC of the in guest screen target memory. With that model in mind the design you mention above is basically as good as it gets for what we have.
z