All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	amd-gfx mailing list <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes
Date: Tue, 1 Sep 2020 09:20:39 +0200	[thread overview]
Message-ID: <20200901072039.GQ2352366@phenom.ffwll.local> (raw)
In-Reply-To: <CAAxE2A7TC14u9_kkJnpG7-_rLG-q_vkyjhh6=pCDmL0NcfBWaQ@mail.gmail.com>

On Mon, Aug 17, 2020 at 02:23:47AM -0400, Marek Olšák wrote:
> On Wed, Aug 12, 2020 at 9:54 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Tue, Aug 11, 2020 at 09:42:11AM -0400, Marek Olšák wrote:
> > > There are a few cases when the flags can change, for example DCC can be
> > > disabled due to a hw limitation in the 3d engine. Modifiers give the
> > > misleading impression that they help with that, but they don't. They
> > don't
> > > really help with anything.
> >
> > But if that happens, how do you tell the other side that it needs to
> > sample new flags? Does that just happen all the time?
> >
> > Also do the DDC state changes happen for shared buffers too?
> >
> 
> I thought we were only talking about shared buffers.
> 
> If the other side is only a consumer and the producer must disable DCC, the
> producer decompresses DCC and then disables it and updates the BO flags.
> The consumer doesn't need the new flags, because even if DCC stays enabled
> in the consumer, it's in a decompressed state (it has no effect). Only the
> producer knows it's disabled, and any new consumer will also know it when
> it queries the latest BO flags.
> 
> It doesn't work if both sides use writes, because it's not communicated
> that DCC is disabled (BO flags are queried only once). This hasn't been a
> problem so far.
> 
> Is there a way to disable DCC correctly and safely across processes? Yes.
> So why don't we do it? Because it would add more GPU overhead.

Yeah but in this case you can get away with just sampling the bo flags
once (which is what you're doing), so doing that at addfb time should be
perfectly fine. Ofc you might waste a bit of $something also scanning out
the compression metadata (which tells the hw that it's all uncompressed),
but that doesn't seem to be a problem for you.

So treating the legacy bo flags as invariant for shared buffers should be
perfectly fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	amd-gfx mailing list <amd-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes
Date: Tue, 1 Sep 2020 09:20:39 +0200	[thread overview]
Message-ID: <20200901072039.GQ2352366@phenom.ffwll.local> (raw)
In-Reply-To: <CAAxE2A7TC14u9_kkJnpG7-_rLG-q_vkyjhh6=pCDmL0NcfBWaQ@mail.gmail.com>

On Mon, Aug 17, 2020 at 02:23:47AM -0400, Marek Olšák wrote:
> On Wed, Aug 12, 2020 at 9:54 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Tue, Aug 11, 2020 at 09:42:11AM -0400, Marek Olšák wrote:
> > > There are a few cases when the flags can change, for example DCC can be
> > > disabled due to a hw limitation in the 3d engine. Modifiers give the
> > > misleading impression that they help with that, but they don't. They
> > don't
> > > really help with anything.
> >
> > But if that happens, how do you tell the other side that it needs to
> > sample new flags? Does that just happen all the time?
> >
> > Also do the DDC state changes happen for shared buffers too?
> >
> 
> I thought we were only talking about shared buffers.
> 
> If the other side is only a consumer and the producer must disable DCC, the
> producer decompresses DCC and then disables it and updates the BO flags.
> The consumer doesn't need the new flags, because even if DCC stays enabled
> in the consumer, it's in a decompressed state (it has no effect). Only the
> producer knows it's disabled, and any new consumer will also know it when
> it queries the latest BO flags.
> 
> It doesn't work if both sides use writes, because it's not communicated
> that DCC is disabled (BO flags are queried only once). This hasn't been a
> problem so far.
> 
> Is there a way to disable DCC correctly and safely across processes? Yes.
> So why don't we do it? Because it would add more GPU overhead.

Yeah but in this case you can get away with just sampling the bo flags
once (which is what you're doing), so doing that at addfb time should be
perfectly fine. Ofc you might waste a bit of $something also scanning out
the compression metadata (which tells the hw that it's all uncompressed),
but that doesn't seem to be a problem for you.

So treating the legacy bo flags as invariant for shared buffers should be
perfectly fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2020-09-01  7:20 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30 20:36 [PATCH 0/7] drm/amd/display: Drop DRM private objects from amdgpu_dm Nicholas Kazlauskas
2020-07-30 20:36 ` Nicholas Kazlauskas
2020-07-30 20:36 ` [PATCH 1/7] drm/amd/display: Store tiling_flags and tmz_surface on dm_plane_state Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 21:04   ` Rodrigo Siqueira
2020-08-05 21:04     ` Rodrigo Siqueira
2020-08-07  8:24   ` daniel
2020-08-07  8:24     ` daniel
2020-07-30 20:36 ` [PATCH 2/7] drm/amd/display: Reset plane when tiling flags change Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-07-30 20:50   ` Wu, Hersen
2020-07-30 20:50     ` Wu, Hersen
2020-08-05 21:11   ` Rodrigo Siqueira
2020-08-05 21:11     ` Rodrigo Siqueira
2020-08-06 18:18     ` Kazlauskas, Nicholas
2020-08-06 18:18       ` Kazlauskas, Nicholas
2020-07-30 20:36 ` [PATCH 3/7] drm/amd/display: Avoid using unvalidated tiling_flags and tmz_surface in prepare_planes Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 21:12   ` Rodrigo Siqueira
2020-08-05 21:12     ` Rodrigo Siqueira
2020-08-07  8:30   ` daniel
2020-08-07  8:30     ` daniel
2020-08-07 14:29     ` Kazlauskas, Nicholas
2020-08-07 14:29       ` Kazlauskas, Nicholas
2020-08-10 12:25       ` Daniel Vetter
2020-08-10 12:25         ` Daniel Vetter
2020-08-10 12:30         ` Christian König
2020-08-10 12:30           ` Christian König
2020-08-10 12:32           ` Daniel Vetter
2020-08-10 12:32             ` Daniel Vetter
2020-08-11 13:42           ` Marek Olšák
2020-08-11 13:42             ` Marek Olšák
2020-08-12 13:54             ` Daniel Vetter
2020-08-12 13:54               ` Daniel Vetter
2020-08-17  6:23               ` Marek Olšák
2020-08-17  6:23                 ` Marek Olšák
2020-09-01  7:20                 ` Daniel Vetter [this message]
2020-09-01  7:20                   ` Daniel Vetter
2020-07-30 20:36 ` [PATCH 4/7] drm/amd/display: Use validated tiling_flags and tmz_surface in commit_tail Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 21:15   ` Rodrigo Siqueira
2020-08-05 21:15     ` Rodrigo Siqueira
2020-07-30 20:36 ` [PATCH 5/7] drm/amd/display: Reset plane for anything that's not a FAST update Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-07-30 20:51   ` Wu, Hersen
2020-07-30 20:51     ` Wu, Hersen
2020-08-05 20:45   ` Rodrigo Siqueira
2020-08-05 20:45     ` Rodrigo Siqueira
2020-08-06 18:27     ` Kazlauskas, Nicholas
2020-08-06 18:27       ` Kazlauskas, Nicholas
2020-08-07  8:34   ` daniel
2020-08-07  8:34     ` daniel
2020-08-07 14:26     ` Kazlauskas, Nicholas
2020-08-07 14:26       ` Kazlauskas, Nicholas
2020-08-10 12:30       ` Daniel Vetter
2020-08-10 12:30         ` Daniel Vetter
2020-07-30 20:36 ` [PATCH 6/7] drm/amd/display: Drop dm_determine_update_type_for_commit Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 20:48   ` Rodrigo Siqueira
2020-08-05 20:48     ` Rodrigo Siqueira
2020-07-30 20:36 ` [PATCH 7/7] drm/amd/display: Replace DRM private objects with subclassed DRM atomic state Nicholas Kazlauskas
2020-07-30 20:36   ` Nicholas Kazlauskas
2020-08-05 20:37   ` Rodrigo Siqueira
2020-08-05 20:37     ` Rodrigo Siqueira
2020-08-06 14:25     ` Kazlauskas, Nicholas
2020-08-06 14:25       ` Kazlauskas, Nicholas
2020-08-07  8:40   ` daniel
2020-08-07  8:40     ` daniel
2020-08-07  8:52   ` daniel
2020-08-07  8:52     ` daniel
2020-08-07 14:32     ` Kazlauskas, Nicholas
2020-08-07 14:32       ` Kazlauskas, Nicholas
2020-08-10 12:34       ` Daniel Vetter
2020-08-10 12:34         ` Daniel Vetter
2020-08-07  8:29 ` [PATCH 0/7] drm/amd/display: Drop DRM private objects from amdgpu_dm daniel
2020-08-07  8:29   ` daniel

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=20200901072039.GQ2352366@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maraeo@gmail.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.