From: Gerd Hoffmann <kraxel@redhat.com>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: dri-devel@lists.freedesktop.org, gurchetansingh@chromium.org
Subject: Re: [PATCH 2/2] drm/virtio: Include modifier as part of set_scanout_blob
Date: Wed, 31 Mar 2021 09:59:58 +0200 [thread overview]
Message-ID: <20210331075958.ax4rqedbebnoad6x@sirius.home.kraxel.org> (raw)
In-Reply-To: <20210331030439.1564032-2-vivek.kasireddy@intel.com>
Hi,
> -#define MAX_INLINE_CMD_SIZE 96
> +#define MAX_INLINE_CMD_SIZE 112
Separate patch please.
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -409,6 +409,7 @@ struct virtio_gpu_set_scanout_blob {
> __le32 width;
> __le32 height;
> __le32 format;
> + __le64 modifier;
> __le32 padding;
> __le32 strides[4];
> __le32 offsets[4];
Nope. This breaks the virtio protocol.
We'll need a virtio feature flag to negotiate modifier support between
guest and host. When supported by both sides it can be used. The new
field should be appended, not inserted in the middle. Or we create a
new virtio_gpu_set_scanout_blob2 struct with new command for this.
Also: I guess the device should provide a list of supported modifiers,
maybe as capset?
Note: I think it is already possible to create resources with modifiers
when using virgl commands for that. Allowing modifiers with virgl=off
too makes sense given your use case, but we should not use diverging
approaches for virgl=on vs. virgl=off. Specifically I'm not sure
virtio_gpu_set_scanout_blob is the right place, I think with virgl=on
the modifier is linked to the resource not the scanout ...
Cc'ing Gurchetan Singh for comments.
take care,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-03-31 8:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-31 3:04 [PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs Vivek Kasireddy
2021-03-31 3:04 ` [PATCH 2/2] drm/virtio: Include modifier as part of set_scanout_blob Vivek Kasireddy
2021-03-31 7:59 ` Gerd Hoffmann [this message]
2021-04-02 7:55 ` Zhang, Tina
2021-04-02 16:07 ` Gurchetan Singh
2021-03-31 7:41 ` [PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs Gerd Hoffmann
2021-04-01 3:51 ` Kasireddy, Vivek
2021-04-01 6:53 ` Gerd Hoffmann
2021-04-06 20:36 ` [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v2) Vivek Kasireddy
2021-04-07 0:34 ` Gurchetan Singh
2021-04-08 9:27 ` Gerd Hoffmann
2021-04-09 0:31 ` Gurchetan Singh
2021-04-09 7:48 ` Gerd Hoffmann
2021-04-13 0:58 ` Gurchetan Singh
[not found] ` <BN7PR11MB2786499E7902CE53326ACE97894F9@BN7PR11MB2786.namprd11.prod.outlook.com>
2021-04-13 4:57 ` Zhang, Tina
2021-04-13 5:26 ` [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v3) Vivek Kasireddy
2021-04-14 6:36 ` Zhang, Tina
2021-04-14 9:29 ` Gerd Hoffmann
2021-04-14 23:31 ` Gurchetan Singh
2021-04-15 9:07 ` Gerd Hoffmann
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=20210331075958.ax4rqedbebnoad6x@sirius.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=vivek.kasireddy@intel.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).