From: Daniel Vetter <daniel@ffwll.ch>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: "Tvrtko Ursulin" <tursulin@igalia.com>,
amd-gfx@lists.freedesktop.org, kernel-dev@igalia.com,
"Alex Deucher" <alexander.deucher@amd.com>,
"Rob Clark" <robdclark@chromium.org>,
"Christian König" <christian.koenig@amd.com>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] Documentation/gpu: Document the situation with unqualified drm-memory-
Date: Fri, 3 May 2024 17:33:05 +0200 [thread overview]
Message-ID: <ZjUDsRIHHmJ0oM-1@phenom.ffwll.local> (raw)
In-Reply-To: <2cdee989-f48d-4923-b12a-f09a1cc2b34d@igalia.com>
On Fri, May 03, 2024 at 01:58:38PM +0100, Tvrtko Ursulin wrote:
>
> [And I forgot dri-devel.. doing well!]
>
> On 03/05/2024 13:40, Tvrtko Ursulin wrote:
> >
> > [Correcting Christian's email]
> >
> > On 03/05/2024 13:36, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> > >
> > > Currently it is not well defined what is drm-memory- compared to other
> > > categories.
> > >
> > > In practice the only driver which emits these keys is amdgpu and in them
> > > exposes the total memory use (including shared).
> > >
> > > Document that drm-memory- and drm-total-memory- are aliases to
> > > prevent any
> > > confusion in the future.
> > >
> > > While at it also clarify that the reserved sub-string 'memory' refers to
> > > the memory region component.
> > >
> > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> > > Cc: Alex Deucher <alexander.deucher@amd.com>
> > > Cc: Christian König <christian.keonig@amd.com>
> >
> > Mea culpa, I copied the mistake from
> > 77d17c4cd0bf52eacfad88e63e8932eb45d643c5. :)
> >
> > Regards,
> >
> > Tvrtko
> >
> > > Cc: Rob Clark <robdclark@chromium.org>
> > > ---
> > > Documentation/gpu/drm-usage-stats.rst | 10 +++++++++-
> > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/gpu/drm-usage-stats.rst
> > > b/Documentation/gpu/drm-usage-stats.rst
> > > index 6dc299343b48..ef5c0a0aa477 100644
> > > --- a/Documentation/gpu/drm-usage-stats.rst
> > > +++ b/Documentation/gpu/drm-usage-stats.rst
> > > @@ -128,7 +128,9 @@ Memory
> > > Each possible memory type which can be used to store buffer
> > > objects by the
> > > GPU in question shall be given a stable and unique name to be
> > > returned as the
> > > -string here. The name "memory" is reserved to refer to normal
> > > system memory.
> > > +string here.
> > > +
> > > +The region name "memory" is reserved to refer to normal system memory.
> > > Value shall reflect the amount of storage currently consumed by
> > > the buffer
> > > objects belong to this client, in the respective memory region.
> > > @@ -136,6 +138,9 @@ objects belong to this client, in the respective
> > > memory region.
> > > Default unit shall be bytes with optional unit specifiers of 'KiB'
> > > or 'MiB'
> > > indicating kibi- or mebi-bytes.
> > > +This is an alias for drm-total-<region> and only one of the two
> > > should be
> > > +present.
This feels a bit awkward and seems to needlessly complicate fdinfo uapi.
- Could we just patch amdgpu to follow everyone else, and avoid the
special case? If there's no tool that relies on the special amdgpu
prefix then that would be a lot easier.
- If that's not on the table, could we make everyone (with a suitable
helper or something) just print both variants, so that we again have
consisent fdinfo output? Or breaks that a different set of existing
tools.
- Finally maybe could we get away with fixing amd by adding the common
format there, deprecating the old, fixing the tools that would break and
then maybe if we're lucky, remove the old one from amdgpu in a year or
so?
Uapi that's "either do $foo or on this one driver, do $bar" is just
guaranteed to fragement the ecosystem, so imo that should be the absolute
last resort.
-Sima
> > > +
> > > - drm-shared-<region>: <uint> [KiB|MiB]
> > > The total size of buffers that are shared with another file (e.g.,
> > > have more
> > > @@ -145,6 +150,9 @@ than a single handle).
> > > The total size of buffers that including shared and private memory.
> > > +This is an alias for drm-memory-<region> and only one of the two
> > > should be
> > > +present.
> > > +
> > > - drm-resident-<region>: <uint> [KiB|MiB]
> > > The total size of buffers that are resident in the specified region.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2024-05-03 15:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240503123657.9441-1-tursulin@igalia.com>
[not found] ` <736ba0a2-035b-4727-bbcc-437029420377@igalia.com>
2024-05-03 12:58 ` [PATCH] Documentation/gpu: Document the situation with unqualified drm-memory- Tvrtko Ursulin
2024-05-03 13:39 ` Alex Deucher
2024-05-03 13:55 ` Tvrtko Ursulin
2024-05-03 15:33 ` Daniel Vetter [this message]
2024-05-03 15:58 ` Alex Deucher
2024-05-03 17:06 ` Tvrtko Ursulin
2024-05-03 18:25 ` Alex Deucher
2024-05-06 12:56 ` Daniel Vetter
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=ZjUDsRIHHmJ0oM-1@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=robdclark@chromium.org \
--cc=tursulin@igalia.com \
--cc=tvrtko.ursulin@igalia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).