Re: [RFC PATCH] drm/vkms: Add support for virtual hardware mode

[Zack Rusin]

On 2/25/21 4:09 AM, Daniel Vetter wrote:
> On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini
> <sylphrenadin@xxxxxxxxx> 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