On Thu, Feb 25, 2021 at 11:32:08AM +0100, Daniel Vetter wrote: > On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote: > > On Thu, Feb 25, 2021 at 10:09:42AM +0100, 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. > > > > Disclaimer: Not knowing much about the crc thing beside having noticed > > it exists and seems to be used for display content checking. > > > > > 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. > > > > igt runs inside the guest, right? > > Yup. There's some debugfs files for capture crc on a specific CRTC. So > supporting this would mean some virtio-gpu revision so you could ask the > host side for a crc when you do a screen update, and the host side would > send that back to you on a virtio channel as some kind of message. Waded through the source code a bit. So, the vkms crc code merges all planes (specifically the cursor plane) before calculating the crc. Which is a bit of a problem, we try to avoid that and rarely actually merge the planes anywhere in the virtualization stack. Instead we prefer to pass through the cursor plane separately, so we can -- for example -- use that to simply set the cursor sprite of the qemu gtk window. It's much more snappy because moving+rendering the pointer doesn't need a round-trip to the guest then. So, it would be quite some effort on the host side, we would have to merge planes just for crc calculation. > > You can ask qemu to write out a screen dump. Hmm, the (hardware) cursor is not in the screen dump either. A software cursor (when using for example cirrus which has no cursor plane) would be there. > > Another option to access the screen would be vnc. vnc clients can get the cursor sprite. They can't get the position though, only set it (it's a one-way ticket in the vnc protocol). Typically not a problem because desktops set the position in response to the pointer events so guest + host position match nevertheless. But for test cases which don't look at input events and set the cursor to a fixed place this is a problem ... > > On-demand crc via debugfs or ioctl would work too, but yes that wouldn't > > verify the host-side. At least not without virtio protocol extensions. > > We could add a new command asking the host to crc the display and return > > the result for on-demand crc. Or add a crc request flag to an existing > > command (VIRTIO_GPU_CMD_RESOURCE_FLUSH probably). > > Yup, I think that's what would be needed. The question here is, what do > you think would be the most natural way for virtio host side stack to > support this? virtio has feature flags, so we can easily introduce an extension in a backward compatible way. Each command sends a reply, with optional payload, so it would make sense to send the crc with the VIRTIO_GPU_CMD_RESOURCE_FLUSH reply. Alternatively introduce a communication channel independent of the gpu, using for example virtio-serial or vsock, let the guest send crc requests to qemu that way. Which would work with all qemu display devices, not only virtio-gpu. take care, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
