From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CC4F0ECE579 for ; Mon, 9 Sep 2024 09:13:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4909C10E340; Mon, 9 Sep 2024 09:13:16 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=igalia.com header.i=@igalia.com header.b="ef7eqMSl"; dkim-atps=neutral Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) by gabe.freedesktop.org (Postfix) with ESMTPS id 358F210E340; Mon, 9 Sep 2024 09:13:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=UQorVFH+3/p6XhrJD9Gg39tlZOUc67E0HuFK3IMFSis=; b=ef7eqMSlq9FT8UyfetbDJXgb3f N4vExWyTh3b+QUW28FwxYirERSCAFi5fuatwcelQjxpYwOvF6pbHwBA0cIGJHINnjH427i28Y1j2m 0rkcu6VGHBQImyparPkC5txe9OtmbKUeev8cKg9N2R6ZkZx9b0YaKG/PUCxo42Rs0SS7Gv4K1oo27 4rSPRqNmUIIekHZciuTiNcRu4fevcYnxQbppyoyvzobm2OjkWaFX80o7sCuPYC9gt0A7bRjJ4YYsg 0jygnHW0EQgQnZDCZDfVldSkfISXn8Yen3FaAWqUmRkaxji7DuETLUtPiS5ZtyhlYhBxcOTMHY6N7 0LDnl3PQ==; Received: from [90.241.98.187] (helo=[192.168.0.101]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1snaSJ-00BQiz-P4; Mon, 09 Sep 2024 11:13:07 +0200 Message-ID: Date: Mon, 9 Sep 2024 10:13:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] Documentation/gpu: Document the situation with unqualified drm-memory- To: Alex Deucher Cc: Tvrtko Ursulin , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, kernel-dev@igalia.com, Alex Deucher , Rob Clark , =?UTF-8?Q?Christian_K=C3=B6nig?= , Maxime Ripard , Thomas Zimmermann References: <20240813135712.82611-1-tursulin@igalia.com> <20240813135712.82611-2-tursulin@igalia.com> <8c732c8e-27d3-46f8-83fe-6b3edb835d95@igalia.com> Content-Language: en-GB From: Tvrtko Ursulin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 06/09/2024 19:12, Alex Deucher wrote: > On Wed, Sep 4, 2024 at 4:36 AM Tvrtko Ursulin wrote: >> >> >> On 21/08/2024 21:47, Alex Deucher wrote: >>> On Tue, Aug 13, 2024 at 9:57 AM Tvrtko Ursulin wrote: >>>> >>>> From: Tvrtko Ursulin >>>> >>>> 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 current resident buffer object memory (including shared). >>>> >>>> To prevent any confusion, document that drm-memory- is deprecated and an >>>> alias for drm-resident-memory-. >>>> >>>> While at it also clarify that the reserved sub-string 'memory' refers to >>>> the memory region component, and also clarify the intended semantics of >>>> other memory categories. >>>> >>>> v2: >>>> * Also mark drm-memory- as deprecated. >>>> * Add some more text describing memory categories. (Alex) >>>> >>>> v3: >>>> * Semantics of the amdgpu drm-memory is actually as drm-resident. >>>> >>>> Signed-off-by: Tvrtko Ursulin >>>> Cc: Alex Deucher >>>> Cc: Christian König >>>> Cc: Rob Clark >>>> --- >>>> Documentation/gpu/drm-usage-stats.rst | 25 ++++++++++++++++++++++--- >>>> 1 file changed, 22 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst >>>> index a80f95ca1b2f..ff964c707754 100644 >>>> --- a/Documentation/gpu/drm-usage-stats.rst >>>> +++ b/Documentation/gpu/drm-usage-stats.rst >>>> @@ -144,7 +144,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. >>>> @@ -152,6 +154,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 key is deprecated and is an alias for drm-resident-. Only one of >>>> +the two should be present in the output. >>>> + >>> >>> I'm not sure how best to handle this. What should amdgpu do? We have >>> customers out in the field using these existing fields and then with >>> patch 2, they go away. Arguably we'd want both for backwards >>> compatibility. >> >> Exactly, so it looks you maybe missed that 2/2 is not removing the >> amdgpu "legacy" drm-memory-. It keeps outputting it and also duplicating >> under drm-resident-. This is mentioned in the commit paragraph: >> >> """ >> Legacy keys have been preserved, with the outlook of only potentially >> removing only the drm-memory- when the time gets right. >> """ >> >> Put differently, I don't think 2/2 should break the existing >> tools/parsers. Only if they have hardcoded assumptions about the order >> of keys perhaps? > > You're right. I totally missed that part. The series is: > Reviewed-by: Alex Deucher > Happy to take the patches through my tree or patch 2 via mine and > patch 1 via drm-misc. Thanks! As to how to merge I don't have a strong preference. Adding Maxime and Thomas to check if they would want to take 1/2 via drm-misc-next? But IMO not splitting the patches between trees also kind of makes sense. Regards, Tvrtko > > Alex > >> >> Regards, >> >> Tvrtko >> >>>> - drm-shared-: [KiB|MiB] >>>> >>>> The total size of buffers that are shared with another file (e.g., have more >>>> @@ -159,20 +164,34 @@ than a single handle). >>>> >>>> - drm-total-: [KiB|MiB] >>>> >>>> -The total size of buffers that including shared and private memory. >>>> +The total size of all created buffers including shared and private memory. The >>>> +backing store for the buffers does not have to be currently instantiated to be >>>> +counted under this category. >>>> >>>> - drm-resident-: [KiB|MiB] >>>> >>>> -The total size of buffers that are resident in the specified region. >>>> +The total size of buffers that are resident (have their backing store present or >>>> +instantiated) in the specified region. >>>> + >>>> +This is an alias for drm-memory- and only one of the two should be >>>> +present in the output. >>>> >>>> - drm-purgeable-: [KiB|MiB] >>>> >>>> The total size of buffers that are purgeable. >>>> >>>> +For example drivers which implement a form of 'madvise' like functionality can >>>> +here count buffers which have instantiated backing store, but have been marked >>>> +with an equivalent of MADV_DONTNEED. >>>> + >>>> - drm-active-: [KiB|MiB] >>>> >>>> The total size of buffers that are active on one or more engines. >>>> >>>> +One practical example of this can be presence of unsignaled fences in an GEM >>>> +buffer reservation object. Therefore the active category is a subset of >>>> +resident. >>>> + >>>> Implementation Details >>>> ====================== >>>> >>>> -- >>>> 2.44.0 >>>>