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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
