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 20A7AD0C606 for ; Fri, 25 Oct 2024 12:48:18 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BA55610EAA5; Fri, 25 Oct 2024 12:48:11 +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="gDKxLQ2G"; dkim-atps=neutral Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) by gabe.freedesktop.org (Postfix) with ESMTPS id C7FA310E8CE; Thu, 24 Oct 2024 08:29:23 +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=Ukhu1zEgudrLrY4FbTtrJ0nj4ZcHWLk3Hk7myyRZWso=; b=gDKxLQ2GzSkytVi8d7dxLZowcY eKvfDCnK2LvTFU8z1U4GQ0WRLi4OsUTlciXZIEWs+4wRfr3KbOhnEO0hSb6V/HSsSmNEhzPIRk5r7 SVdIrRR+C4CrpPmnqW7F5AzjIheq/bfkpuHezw5Et8dzbp6y3dLaaHXZWTPZpzPNHfDF2YaaQnBl/ EsMfHg0SdjaedfIrEUp81uxg3nJV5rh5yJPOiI6v1fVux5JjMZoJocSpNTk48HukrSwyiejkFN43W LjHmlTgZXNzRkr+VfP88JHmK30cOE74hlhteEIFdgdPLcbYlY0FKnHGcbS9WrOPGlr1oTUzmai907 6v45iEJg==; 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 1t3tDe-00EQ5y-09; Thu, 24 Oct 2024 10:29:22 +0200 Message-ID: <50803e40-eaaf-4301-8459-e1b465b2d6f7@igalia.com> Date: Thu, 24 Oct 2024 09:29:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 4/4] drm/amdgpu: track bo memory stats at runtime To: =?UTF-8?Q?Christian_K=C3=B6nig?= , "Li, Yunxiang (Teddy)" , "dri-devel@lists.freedesktop.org" , "amd-gfx@lists.freedesktop.org" Cc: "Deucher, Alexander" References: <20241018133308.889-1-Yunxiang.Li@amd.com> <20241018133308.889-5-Yunxiang.Li@amd.com> <1057097f-02f4-4f0f-9ac5-37aa84570b47@amd.com> <53382fc0-0686-46af-9285-0cd6aec314ae@amd.com> <47e4b79b-2c08-4ee8-b472-5482bc159856@amd.com> <6d324aca-76fd-420b-9bae-6c0984e659e1@igalia.com> <7503c3fd-deea-4eb9-9324-ab4f13f70332@amd.com> <2141a4f4-bcf4-4419-8756-fb5afd6c7f3a@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-Mailman-Approved-At: Fri, 25 Oct 2024 12:48:03 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On 23/10/2024 13:56, Christian König wrote: > Am 23.10.24 um 14:24 schrieb Tvrtko Ursulin: >> [SNIP] >>>> To fold or not the special placements (GWS, GDS & co) is also >>>> tangential. In my patch I just preserved the legacy behaviour so it >>>> can easily be tweaked on top. >>> >>> Yeah, but again the original behavior is completely broken. >>> >>> GWS, GDS and OA are counted in blocks of HW units (multiplied by >>> PAGE_SIZE IIRC to avoid some GEM&TTM warnings). >>> >>> When you accumulate that anywhere in the memory stats then that is >>> just completely off. >> >> Ooops. :) Are they backed by some memory though, be it system or VRAM? > > GDS is an internal 4 or 64KiB memory block which is only valid while > shaders are running. It is used to communicate stuff between different > shader stages and not even CPU accessible. > > GWS and OA are not even memory, those are just HW blocks which implement > a fixed function. > > IIRC most HW generation have 16 of each and when setting up the > application virtual address space you can specify how many will be used > by the application. I see, thank you! Though I could have bothered to look in the code or even instrument at runtime too. I agree removing it from system is correct. If wanted and/or desirable some or all could be exported as different memory regions even. DRM fdinfo specs already allows that. Like: drm-total-vram: ... drm-total-gds: ... drm-total-oa: ... Etc. Regards, Tvrtko