All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
To: "Kim, Dongwon" <dongwon.kim@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>, lkp <lkp@intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Gurchetan Singh <gurchetansingh@chromium.org>
Subject: RE: [PATCH v2 2/2] drm/virtio: fence created per cursor/plane update
Date: Wed, 15 Jun 2022 06:09:07 +0000	[thread overview]
Message-ID: <2132139f4e104a018ca929d3f39a5503@intel.com> (raw)
In-Reply-To: <20220614191737.GA67@dongwonk-MOBL.amr.corp.intel.com>

Hi DW,

> 
> On Thu, Jun 09, 2022 at 06:24:43AM +0200, Gerd Hoffmann wrote:
> > On Fri, Jun 03, 2022 at 02:18:49PM -0700, Dongwon Kim wrote:
> > > Having one fence for a vgfb would cause conflict in case there are
> > > multiple planes referencing the same vgfb (e.g. Xorg screen covering
> > > two displays in extended mode) being flushed simultaneously. So it makes
> > > sence to use a separated fence for each plane update to prevent this.
> > >
> > > vgfb->fence is not required anymore with the suggested code change so
> > > both prepare_fb and cleanup_fb are removed since only fence creation/
> > > freeing are done in there.
> >
> > The fences are allocated and released in prepare_fb + cleanup_fb for a
> > reason: atomic_update must not fail.
> 
> In case fence allocation fails, it falls back to non-fence path so it
> won't fail for primary-plane-update.
> 
> For cursor plane update, it returns if fence is NULL but we could change
> it to just proceed and just make it skip waiting like,
[Kasireddy, Vivek] But cursor plane update is always tied to a fence based on the
way it works now and we have to fail if there is no fence.

> 
> if (fence) {
>     dma_fence_wait(&fence->f, true);
>     dma_fence_put(&fence->f);
> }
> 
> Or maybe I can limit my suggested changes to primary-plane-update only.
> 
> What do you think about these?
> 
> >
> > I guess virtio-gpu must be fixed to use drm_plane_state->fence
> > correctly ...
> 
> I was thinking about this too but current functions (e.g.
> virtio_gpu_cmd_transfer_to_host_2d) takes "struct virtio_gpu_fence".
> Not sure what is the best way to connect drm_plane_state->fence to
> virtio_gpu_fence without changing major function interfaces.
[Kasireddy, Vivek] FWIU, we cannot use drm_plane_state->fence as it is used
by drm core to handle explicit fences. So, I think a cleaner way is to subclass
base drm_plane_state and move the fence from virtio_gpu_framebuffer to a
new struct virtio_gpu_plane_state. This way, we can create the fence in
prepare_fb() and use it for synchronization in resource_flush.

Thanks,
Vivek

> 
> >
> > take care,
> >   Gerd
> >

      reply	other threads:[~2022-06-15  6:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03 21:18 [PATCH v2 0/2] drm/virtio: fence handling in case of multi scanouts Dongwon Kim
2022-06-03 21:18 ` [PATCH v2 1/2] drm/virtio: .release ops for virtgpu fence release Dongwon Kim
2022-06-06 23:54   ` Kasireddy, Vivek
2022-06-03 21:18 ` [PATCH v2 2/2] drm/virtio: fence created per cursor/plane update Dongwon Kim
2022-06-07  0:23   ` Kasireddy, Vivek
2022-06-09  4:24   ` Gerd Hoffmann
2022-06-14 19:17     ` Dongwon Kim
2022-06-15  6:09       ` Kasireddy, Vivek [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=2132139f4e104a018ca929d3f39a5503@intel.com \
    --to=vivek.kasireddy@intel.com \
    --cc=dan.carpenter@oracle.com \
    --cc=dongwon.kim@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gurchetansingh@chromium.org \
    --cc=kraxel@redhat.com \
    --cc=lkp@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.