All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: "Jason Ekstrand" <jason@jlekstrand.net>,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	dri-devel@lists.freedesktop.org,
	"Steven Price" <steven.price@arm.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Alyssa Rosenzweig" <alyssa.rosenzweig@collabora.com>,
	"Robin Murphy" <robin.murphy@arm.com>
Subject: Re: [PATCH v4 5/7] drm/panfrost: Add a new ioctl to submit batches
Date: Tue, 27 Jul 2021 11:17:38 +0200	[thread overview]
Message-ID: <YP/PMvbsMS7H/5Sy@phenom.ffwll.local> (raw)
In-Reply-To: <20210726122706.7fb3a8d5@collabora.com>

On Mon, Jul 26, 2021 at 12:27:06PM +0200, Boris Brezillon wrote:
> On Thu, 8 Jul 2021 14:10:45 +0200
> Christian König <ckoenig.leichtzumerken@gmail.com> wrote:
> 
> > >> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> > >> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> > >> @@ -254,6 +254,9 @@ static int panfrost_acquire_object_fences(struct panfrost_job *job)
> > >>   				return ret;
> > >>   		}
> > >>   
> > >> +		if (job->bo_flags[i] & PANFROST_BO_REF_NO_IMPLICIT_DEP)
> > >> +			continue;  
> > > This breaks dma_resv rules. I'll send out patch set fixing this pattern in
> > > other drivers, I'll ping you on that for what you need to change. Should
> > > go out today or so.
> 
> I guess you're talking about [1]. TBH, I don't quite see the point of
> exposing a 'no-implicit' flag if we end up forcing this implicit dep
> anyway, but I'm probably missing something.

Yeah that's the patch set.

Note that there's better ways to do this, it's just that these better ways
take more typing and need some actual testing (and ideally igts and
everything).

The NO_IMPLICIT flag is still useful even with the hacky solution, as long
as you don't set a write fence too. For that it might be better to look
into the dma_fence import patch from Jason:

https://lore.kernel.org/dri-devel/20210610210925.642582-7-jason@jlekstrand.net/

> > I'm really wondering if the behavior that the exclusive fences replaces 
> > all the shared fences was such a good idea.
> 
> Is that what's done in [1], or are you talking about a different
> patchset/approach?

That's just how dma_resv works for the exclusive slot.
-Daniel

> 
> > 
> > It just allows drivers to mess up things in a way which can be easily 
> > used to compromise the system.
> 
> I must admit I'm a bit lost, so I'm tempted to drop that flag for now
> :-).
> 
> [1]https://patchwork.freedesktop.org/patch/443711/?series=92334&rev=3

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2021-07-27  9:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05  8:29 [PATCH v4 0/7] drm/panfrost: drm/panfrost: Add a new submit ioctl Boris Brezillon
2021-07-05  8:29 ` [PATCH v4 1/7] drm/panfrost: Pass a job to panfrost_{acquire, attach}_object_fences() Boris Brezillon
2021-07-05  8:29 ` [PATCH v4 2/7] drm/panfrost: Move the mappings collection out of panfrost_lookup_bos() Boris Brezillon
2021-07-05  8:29 ` [PATCH v4 3/7] drm/panfrost: Add BO access flags to relax dependencies between jobs Boris Brezillon
2021-07-05  8:29 ` [PATCH v4 4/7] drm/panfrost: Add the ability to create submit queues Boris Brezillon
2021-07-05  8:56   ` Steven Price
2021-07-05  8:29 ` [PATCH v4 5/7] drm/panfrost: Add a new ioctl to submit batches Boris Brezillon
2021-07-05  9:32   ` Daniel Vetter
2021-07-08 12:10     ` Christian König
2021-07-26 10:27       ` Boris Brezillon
2021-07-27  9:17         ` Daniel Vetter [this message]
2021-07-05  9:42   ` Steven Price
2021-07-05  8:29 ` [PATCH v4 6/7] drm/panfrost: Advertise the SYNCOBJ_TIMELINE feature Boris Brezillon
2021-07-05  8:29 ` [PATCH v4 7/7] drm/panfrost: Bump minor version to reflect the feature additions Boris Brezillon

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=YP/PMvbsMS7H/5Sy@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=boris.brezillon@collabora.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=steven.price@arm.com \
    --cc=tomeu.vizoso@collabora.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.