From: Zack Rusin <zackr@vmware.com>
To: Daniel Vetter <daniel@ffwll.ch>,
Sumera Priyadarsini <sylphrenadin@gmail.com>,
Gerd Hoffmann <kraxel@redhat.com>
Cc: Melissa Wen <melissa.srw@gmail.com>,
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>,
Haneen Mohammed <hamohammed.sa@gmail.com>,
Dave Airlie <airlied@linux.ie>,
dri-devel <dri-devel@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] drm/vkms: Add support for virtual hardware mode
Date: Thu, 25 Feb 2021 11:25:24 -0500 [thread overview]
Message-ID: <9b1b55a6-dcea-db17-03ca-1dc52f4a8083@vmware.com> (raw)
In-Reply-To: <CAKMK7uFwdHaaGs8BPSAah1Vp5pJWTzxoruLgOWxQu1aDAyCKLQ@mail.gmail.com>
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
prev parent reply other threads:[~2021-02-25 16:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 10:55 [RFC PATCH] drm/vkms: Add support for virtual hardware mode Sumera Priyadarsini
2021-02-25 9:09 ` Daniel Vetter
2021-02-25 10:25 ` Gerd Hoffmann
2021-02-25 10:32 ` Daniel Vetter
2021-02-25 13:27 ` Gerd Hoffmann
2021-02-25 15:06 ` Daniel Vetter
2021-02-25 16:25 ` Zack Rusin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b1b55a6-dcea-db17-03ca-1dc52f4a8083@vmware.com \
--to=zackr@vmware.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamohammed.sa@gmail.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=melissa.srw@gmail.com \
--cc=rodrigosiqueiramelo@gmail.com \
--cc=sylphrenadin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).