All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: dri-devel@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
	"open list:DRM DRIVER FOR QXL VIRTUAL GPU" 
	<spice-devel@lists.freedesktop.org>,
	Dave Airlie <airlied@redhat.com>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:DRM DRIVER FOR QXL VIRTUAL GPU" 
	<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH 09/10] drm/qxl: map/unmap framebuffers in prepare_fb+cleanup_fb callbacks.
Date: Wed, 17 Feb 2021 11:02:06 +0100	[thread overview]
Message-ID: <20210217100206.fh5422uz4gnixyif@sirius.home.kraxel.org> (raw)
In-Reply-To: <ab21d782-2627-7a68-8fab-0acfba416c86@suse.de>

On Tue, Feb 16, 2021 at 02:46:21PM +0100, Thomas Zimmermann wrote:
> 
> 
> Am 16.02.21 um 14:27 schrieb Thomas Zimmermann:
> > Hi
> > 
> > this is a shadow-buffered plane. Did you consider using the new helpers
> > for shadow-buffered planes? They will map the user BO for you and
> > provide the mapping in the plane state.
> > 
> >  From there, you should implement your own plane state on top of struct
> > drm_shadow_plane_state, and also move all the other allocations and
> > vmaps into prepare_fb and cleanup_fb. Most of this is not actually
> > allowed in commit tails. All we'd have to do is to export the reset,
> > duplicate and destroy code; similar to what
> > __drm_atomic_helper_plane_reset() does.
> 
> AFAICT the cursor_bo is used to implement double buffering for the cursor
> image.
> 
> Ideally, you can do what ast does: pre-allocate/vmap 2 BOs at the end of the
> vram. Then pageflip between them in atomic_update(). Resolves all the
> allocation and mapping headaches.

Just waded through the ast patches.

It is not that simple for qxl.  You have to send a command to the
virtualization host and take care of the host accessing that memory
when processing the command, so you can't reuse the memory until the
host signals it is fine to do so.

But, yes, it should be possible to handle cursor_bo creation in
prepare_fb without too much effort.

take care,
  Gerd


WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>,
	open list <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org,
	"open list:DRM DRIVER FOR QXL VIRTUAL GPU"
	<virtualization@lists.linux-foundation.org>,
	Dave Airlie <airlied@redhat.com>,
	"open list:DRM DRIVER FOR QXL VIRTUAL GPU"
	<spice-devel@lists.freedesktop.org>
Subject: Re: [PATCH 09/10] drm/qxl: map/unmap framebuffers in prepare_fb+cleanup_fb callbacks.
Date: Wed, 17 Feb 2021 11:02:06 +0100	[thread overview]
Message-ID: <20210217100206.fh5422uz4gnixyif@sirius.home.kraxel.org> (raw)
In-Reply-To: <ab21d782-2627-7a68-8fab-0acfba416c86@suse.de>

On Tue, Feb 16, 2021 at 02:46:21PM +0100, Thomas Zimmermann wrote:
> 
> 
> Am 16.02.21 um 14:27 schrieb Thomas Zimmermann:
> > Hi
> > 
> > this is a shadow-buffered plane. Did you consider using the new helpers
> > for shadow-buffered planes? They will map the user BO for you and
> > provide the mapping in the plane state.
> > 
> >  From there, you should implement your own plane state on top of struct
> > drm_shadow_plane_state, and also move all the other allocations and
> > vmaps into prepare_fb and cleanup_fb. Most of this is not actually
> > allowed in commit tails. All we'd have to do is to export the reset,
> > duplicate and destroy code; similar to what
> > __drm_atomic_helper_plane_reset() does.
> 
> AFAICT the cursor_bo is used to implement double buffering for the cursor
> image.
> 
> Ideally, you can do what ast does: pre-allocate/vmap 2 BOs at the end of the
> vram. Then pageflip between them in atomic_update(). Resolves all the
> allocation and mapping headaches.

Just waded through the ast patches.

It is not that simple for qxl.  You have to send a command to the
virtualization host and take care of the host accessing that memory
when processing the command, so you can't reuse the memory until the
host signals it is fine to do so.

But, yes, it should be possible to handle cursor_bo creation in
prepare_fb without too much effort.

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: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>,
	open list <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org,
	"open list:DRM DRIVER FOR QXL VIRTUAL GPU"
	<virtualization@lists.linux-foundation.org>,
	Dave Airlie <airlied@redhat.com>,
	"open list:DRM DRIVER FOR QXL VIRTUAL GPU"
	<spice-devel@lists.freedesktop.org>
Subject: Re: [PATCH 09/10] drm/qxl: map/unmap framebuffers in prepare_fb+cleanup_fb callbacks.
Date: Wed, 17 Feb 2021 11:02:06 +0100	[thread overview]
Message-ID: <20210217100206.fh5422uz4gnixyif@sirius.home.kraxel.org> (raw)
In-Reply-To: <ab21d782-2627-7a68-8fab-0acfba416c86@suse.de>

On Tue, Feb 16, 2021 at 02:46:21PM +0100, Thomas Zimmermann wrote:
> 
> 
> Am 16.02.21 um 14:27 schrieb Thomas Zimmermann:
> > Hi
> > 
> > this is a shadow-buffered plane. Did you consider using the new helpers
> > for shadow-buffered planes? They will map the user BO for you and
> > provide the mapping in the plane state.
> > 
> >  From there, you should implement your own plane state on top of struct
> > drm_shadow_plane_state, and also move all the other allocations and
> > vmaps into prepare_fb and cleanup_fb. Most of this is not actually
> > allowed in commit tails. All we'd have to do is to export the reset,
> > duplicate and destroy code; similar to what
> > __drm_atomic_helper_plane_reset() does.
> 
> AFAICT the cursor_bo is used to implement double buffering for the cursor
> image.
> 
> Ideally, you can do what ast does: pre-allocate/vmap 2 BOs at the end of the
> vram. Then pageflip between them in atomic_update(). Resolves all the
> allocation and mapping headaches.

Just waded through the ast patches.

It is not that simple for qxl.  You have to send a command to the
virtualization host and take care of the host accessing that memory
when processing the command, so you can't reuse the memory until the
host signals it is fine to do so.

But, yes, it should be possible to handle cursor_bo creation in
prepare_fb without too much effort.

take care,
  Gerd

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

  reply	other threads:[~2021-02-17 10:04 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-16 11:37 [PATCH 00/10] drm/qxl: a collection of fixes Gerd Hoffmann
2021-02-16 11:37 ` [PATCH 01/10] drm/qxl: properly handle device init failures Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 13:08   ` Thomas Zimmermann
2021-02-16 13:08     ` Thomas Zimmermann
2021-02-16 13:08     ` Thomas Zimmermann
2021-02-16 11:37 ` [PATCH 02/10] drm/qxl: more fence wait rework Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37 ` [PATCH 03/10] drm/qxl: use ttm bo priorities Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37 ` [PATCH 04/10] drm/qxl: fix lockdep issue in qxl_alloc_release_reserved Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37 ` [PATCH 05/10] drm/qxl: rename qxl_bo_kmap -> qxl_bo_kmap_locked Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 13:14   ` Thomas Zimmermann
2021-02-16 13:14     ` Thomas Zimmermann
2021-02-16 13:14     ` Thomas Zimmermann
2021-02-16 11:37 ` [PATCH 06/10] drm/qxl: add qxl_bo_kmap/qxl_bo_kunmap Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 13:17   ` Thomas Zimmermann
2021-02-16 13:17     ` Thomas Zimmermann
2021-02-16 13:17     ` Thomas Zimmermann
2021-02-16 11:37 ` [PATCH 07/10] drm/qxl: fix prime kmap Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 13:16   ` Thomas Zimmermann
2021-02-16 13:16     ` Thomas Zimmermann
2021-02-16 13:16     ` Thomas Zimmermann
2021-02-16 11:37 ` [PATCH 08/10] drm/qxl: fix monitors object kmap Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 13:18   ` Thomas Zimmermann
2021-02-16 13:18     ` Thomas Zimmermann
2021-02-16 13:18     ` Thomas Zimmermann
2021-02-16 11:37 ` [PATCH 09/10] drm/qxl: map/unmap framebuffers in prepare_fb+cleanup_fb callbacks Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 13:27   ` Thomas Zimmermann
2021-02-16 13:27     ` Thomas Zimmermann
2021-02-16 13:27     ` Thomas Zimmermann
2021-02-16 13:46     ` Thomas Zimmermann
2021-02-16 13:46       ` Thomas Zimmermann
2021-02-16 13:46       ` Thomas Zimmermann
2021-02-17 10:02       ` Gerd Hoffmann [this message]
2021-02-17 10:02         ` Gerd Hoffmann
2021-02-17 10:02         ` Gerd Hoffmann
2021-02-17 10:23         ` Thomas Zimmermann
2021-02-17 10:23           ` Thomas Zimmermann
2021-02-17 10:23           ` Thomas Zimmermann
2021-02-16 11:37 ` [PATCH 10/10] drm/qxl: add lock asserts to qxl_bo_kmap_locked + qxl_bo_kunmap_locked Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 11:37   ` Gerd Hoffmann
2021-02-16 13:30   ` Thomas Zimmermann
2021-02-16 13:30     ` Thomas Zimmermann
2021-02-16 13:30     ` Thomas Zimmermann

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=20210217100206.fh5422uz4gnixyif@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=airlied@linux.ie \
    --cc=airlied@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spice-devel@lists.freedesktop.org \
    --cc=tzimmermann@suse.de \
    --cc=virtualization@lists.linux-foundation.org \
    /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.