All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Vetter, Daniel" <daniel.vetter@intel.com>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"Kim, Dongwon" <dongwon.kim@intel.com>,
	"sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
Date: Wed, 10 Feb 2021 10:16:41 +0100	[thread overview]
Message-ID: <20210210091641.ahjtgcdalw7viuei@sirius.home.kraxel.org> (raw)
In-Reply-To: <2ef01dc941684a15a4f30e6239ae42df@intel.com>

> > You don't have to use the rendering pipeline.  You can let the i915 gpu
> > render into a dma-buf shared with virtio-gpu, then use virtio-gpu only for
> > buffer sharing with the host.
> [Kasireddy, Vivek] Is this the most viable path forward? I am not sure how complex or 
> feasible it would be but I'll look into it.
> Also, not using the rendering capabilities of virtio-gpu and turning it into a sharing only
> device means there would be a giant mode switch with a lot of if() conditions sprinkled
> across. Are you OK with that?

Hmm, why a big mode switch?  You should be able to do that without
modifying the virtio-gpu guest driver.  On the host side qemu needs
some work to support the most recent virtio-gpu features like the
buffer uuids (assuming you use qemu userspace), right now those
are only supported by crosvm.

It might be useful to add support for display-less virtio-gpu, i.e.
"qemu -device virtio-gpu-pci,max_outputs=0".  Right now the linux
driver throws an error in case no output (crtc) is present.  Should
be fixable without too much effort though, effectively the sanity
check would have to be moved from driver initialization to commands
like SET_SCANOUT which manage the outputs.

take care,
  Gerd


WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
Cc: "Kim, Dongwon" <dongwon.kim@intel.com>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	"Vetter, Daniel" <daniel.vetter@intel.com>,
	"sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
Date: Wed, 10 Feb 2021 10:16:41 +0100	[thread overview]
Message-ID: <20210210091641.ahjtgcdalw7viuei@sirius.home.kraxel.org> (raw)
In-Reply-To: <2ef01dc941684a15a4f30e6239ae42df@intel.com>

> > You don't have to use the rendering pipeline.  You can let the i915 gpu
> > render into a dma-buf shared with virtio-gpu, then use virtio-gpu only for
> > buffer sharing with the host.
> [Kasireddy, Vivek] Is this the most viable path forward? I am not sure how complex or 
> feasible it would be but I'll look into it.
> Also, not using the rendering capabilities of virtio-gpu and turning it into a sharing only
> device means there would be a giant mode switch with a lot of if() conditions sprinkled
> across. Are you OK with that?

Hmm, why a big mode switch?  You should be able to do that without
modifying the virtio-gpu guest driver.  On the host side qemu needs
some work to support the most recent virtio-gpu features like the
buffer uuids (assuming you use qemu userspace), right now those
are only supported by crosvm.

It might be useful to add support for display-less virtio-gpu, i.e.
"qemu -device virtio-gpu-pci,max_outputs=0".  Right now the linux
driver throws an error in case no output (crtc) is present.  Should
be fixable without too much effort though, effectively the sanity
check would have to be moved from driver initialization to commands
like SET_SCANOUT which manage the outputs.

take care,
  Gerd

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
Cc: "Kim, Dongwon" <dongwon.kim@intel.com>,
	"christian.koenig@amd.com" <christian.koenig@amd.com>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"Vetter, Daniel" <daniel.vetter@intel.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
Date: Wed, 10 Feb 2021 10:16:41 +0100	[thread overview]
Message-ID: <20210210091641.ahjtgcdalw7viuei@sirius.home.kraxel.org> (raw)
In-Reply-To: <2ef01dc941684a15a4f30e6239ae42df@intel.com>

> > You don't have to use the rendering pipeline.  You can let the i915 gpu
> > render into a dma-buf shared with virtio-gpu, then use virtio-gpu only for
> > buffer sharing with the host.
> [Kasireddy, Vivek] Is this the most viable path forward? I am not sure how complex or 
> feasible it would be but I'll look into it.
> Also, not using the rendering capabilities of virtio-gpu and turning it into a sharing only
> device means there would be a giant mode switch with a lot of if() conditions sprinkled
> across. Are you OK with that?

Hmm, why a big mode switch?  You should be able to do that without
modifying the virtio-gpu guest driver.  On the host side qemu needs
some work to support the most recent virtio-gpu features like the
buffer uuids (assuming you use qemu userspace), right now those
are only supported by crosvm.

It might be useful to add support for display-less virtio-gpu, i.e.
"qemu -device virtio-gpu-pci,max_outputs=0".  Right now the linux
driver throws an error in case no output (crtc) is present.  Should
be fixable without too much effort though, effectively the sanity
check would have to be moved from driver initialization to commands
like SET_SCANOUT which manage the outputs.

take care,
  Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2021-02-10  9:20 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-03  7:35 [RFC v3 0/3] Introduce Virtio based Dmabuf driver Vivek Kasireddy
2021-02-03  7:35 ` Vivek Kasireddy
2021-02-03  7:35 ` Vivek Kasireddy
2021-02-03  7:35 ` [RFC v3 1/3] kvm: Add a notifier for create and destroy VM events Vivek Kasireddy
2021-02-03  7:35   ` Vivek Kasireddy
2021-02-03  7:35   ` Vivek Kasireddy
2021-02-03  7:35 ` [RFC v3 2/3] virtio: Introduce Vdmabuf driver Vivek Kasireddy
2021-02-03  7:35   ` Vivek Kasireddy
2021-02-03  7:35   ` Vivek Kasireddy
2021-02-03  9:15   ` kernel test robot
2021-02-05 16:03   ` Daniel Vetter
2021-02-05 16:03     ` Daniel Vetter
2021-02-05 16:03     ` Daniel Vetter
2021-02-08  7:57     ` Gerd Hoffmann
2021-02-08  7:57       ` Gerd Hoffmann
2021-02-08  7:57       ` Gerd Hoffmann
2021-02-08  9:38       ` Daniel Vetter
2021-02-08  9:38         ` Daniel Vetter
2021-02-08  9:38         ` Daniel Vetter
2021-02-09  0:25         ` Kasireddy, Vivek
2021-02-09  0:25           ` Kasireddy, Vivek
2021-02-09  0:25           ` Kasireddy, Vivek
2021-02-09  8:44           ` Gerd Hoffmann
2021-02-09  8:44             ` Gerd Hoffmann
2021-02-10  4:47             ` Kasireddy, Vivek
2021-02-10  4:47               ` Kasireddy, Vivek
2021-02-10  4:47               ` Kasireddy, Vivek
2021-02-10  8:05               ` Christian König
2021-02-10  8:05                 ` Christian König
2021-02-10  8:05                 ` Christian König
2021-02-12  8:36                 ` Kasireddy, Vivek
2021-02-12  8:36                   ` Kasireddy, Vivek
2021-02-12  8:36                   ` Kasireddy, Vivek
2021-02-12  8:47                   ` Christian König
2021-02-12  8:47                     ` Christian König
2021-02-12  8:47                     ` Christian König
2021-02-12 10:14                     ` Gerd Hoffmann
2021-02-12 10:14                       ` Gerd Hoffmann
2021-02-12 10:14                       ` Gerd Hoffmann
2021-02-10  9:16               ` Gerd Hoffmann [this message]
2021-02-10  9:16                 ` Gerd Hoffmann
2021-02-10  9:16                 ` Gerd Hoffmann
2021-02-12  8:15                 ` Kasireddy, Vivek
2021-02-12  8:15                   ` Kasireddy, Vivek
2021-02-12  8:15                   ` Kasireddy, Vivek
2021-02-12 11:01                   ` Gerd Hoffmann
2021-02-12 11:01                     ` Gerd Hoffmann
2021-02-12 11:01                     ` Gerd Hoffmann
2021-02-22  8:52                     ` Kasireddy, Vivek
2021-02-22  8:52                       ` Kasireddy, Vivek
2021-02-22  8:52                       ` Kasireddy, Vivek
2021-03-15  2:27                     ` Zhang, Tina
2021-03-15  2:27                       ` Zhang, Tina
2021-03-15  2:27                       ` Zhang, Tina
2021-02-03  7:35 ` [RFC v3 3/3] vhost: Add Vdmabuf backend Vivek Kasireddy
2021-02-03  7:35   ` Vivek Kasireddy
2021-02-03  7:35   ` Vivek Kasireddy

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=20210210091641.ahjtgcdalw7viuei@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dongwon.kim@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-media@vger.kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=virtualization@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.