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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC072C636D6 for ; Wed, 22 Feb 2023 15:08:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231820AbjBVPIo (ORCPT ); Wed, 22 Feb 2023 10:08:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229631AbjBVPIo (ORCPT ); Wed, 22 Feb 2023 10:08:44 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C8F5125B8 for ; Wed, 22 Feb 2023 07:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677078480; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zRCEb4SvpDKPjZLK4vn9/q7q7Y3I8z1o20cZm/AYJwk=; b=J674CxC/A8mIk5DOt7XHpBdjO1Idf7raegOPYNJexLTDhcAA9i5YI34LMTIkCdwj+mNFyT 2jaJwn4lWhPNnBcVSqKiDAYtP7eicUuEhzzpY2Y/T1rnpurwJLtmYyzr8F/VBM0y7WL0tw w4ubGX7wyhZ7wl6XzJRLeAXsLgEDP/w= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-222-GeQN6x6COb61PA-IXEXkUg-1; Wed, 22 Feb 2023 10:07:57 -0500 X-MC-Unique: GeQN6x6COb61PA-IXEXkUg-1 Received: by mail-ed1-f70.google.com with SMTP id dm14-20020a05640222ce00b0046790cd9082so11614361edb.21 for ; Wed, 22 Feb 2023 07:07:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zRCEb4SvpDKPjZLK4vn9/q7q7Y3I8z1o20cZm/AYJwk=; b=2HRCoXPTLr66NgQXPxSkAepBLO02VjOOT8AZjTT/QuXsx0yqKAk1eiHyhXz05fRqN9 ZdH4dBmvwvnkH2aQApgwJlOej6OG+mn50x2Ol+C37pPfBWTCaw3B8MrsLQ5bYqIV1adt wutplTwytJIpKgNYEldowANr+mh4hi2NZES6zJxvr3PyC48RXNt4oVyKmYa5qOI1XlZ9 gBcte9gongmJE0SRWmaF/fYct4Gk0xIOHFdvRp2TwllQbGsTKJjy+DmhC61tPNHKL1kF VDWQifk/yR+29k2dehGWHNvhsxCsQuf47IjKFcteHJ3V+gOjuIz7rlXizSExLg7vCkIP 9JfQ== X-Gm-Message-State: AO0yUKWPkAHSdvR/A3xiXjONalMcXKkv6UioB19RJ017Iu8zAlu6JNQg vvpikzld8tsmQ+KWSa359Fcrhq8Oo7VwLLbV8ZH+wSh8oPJLl9CVI6tsIcioCWPrkw1ACxTNcRv kLyFoq/jsxTtjM0CNrxvq X-Received: by 2002:a17:907:1623:b0:8b1:76dd:f5f6 with SMTP id hb35-20020a170907162300b008b176ddf5f6mr29151549ejc.50.1677078475595; Wed, 22 Feb 2023 07:07:55 -0800 (PST) X-Google-Smtp-Source: AK7set8V2KGVMm3Rh6GnmJnl329zmNElexUMuVrYhLPpVZhOY6NIjF1ZDTeKB87CfdRbYWnWGPbc0Q== X-Received: by 2002:a17:907:1623:b0:8b1:76dd:f5f6 with SMTP id hb35-20020a170907162300b008b176ddf5f6mr29151515ejc.50.1677078475224; Wed, 22 Feb 2023 07:07:55 -0800 (PST) Received: from ?IPV6:2a02:810d:4b3f:de78:642:1aff:fe31:a15c? ([2a02:810d:4b3f:de78:642:1aff:fe31:a15c]) by smtp.gmail.com with ESMTPSA id q20-20020a170906771400b008e57b5e0ce9sm1160273ejm.108.2023.02.22.07.07.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Feb 2023 07:07:54 -0800 (PST) Message-ID: Date: Wed, 22 Feb 2023 16:07:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH drm-next v2 05/16] drm: manager to keep track of GPUs VA mappings Content-Language: en-US To: =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de, mripard@kernel.org, corbet@lwn.net, bskeggs@redhat.com, Liam.Howlett@oracle.com, matthew.brost@intel.com, boris.brezillon@collabora.com, alexdeucher@gmail.com, ogabbay@kernel.org, bagasdotme@gmail.com, willy@infradead.org, jason@jlekstrand.net, linux-doc@vger.kernel.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Dave Airlie References: <20230217134422.14116-1-dakr@redhat.com> <20230217134422.14116-6-dakr@redhat.com> <70ba382f-1559-289a-4922-ca9c371aaf59@amd.com> From: Danilo Krummrich Organization: RedHat In-Reply-To: <70ba382f-1559-289a-4922-ca9c371aaf59@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 2/22/23 11:25, Christian König wrote: > Am 17.02.23 um 14:44 schrieb Danilo Krummrich: >> +/** >> + * DOC: Overview >> + * >> + * The DRM GPU VA Manager, represented by struct drm_gpuva_manager >> keeps track >> + * of a GPU's virtual address (VA) space and manages the >> corresponding virtual >> + * mappings represented by &drm_gpuva objects. It also keeps track of >> the >> + * mapping's backing &drm_gem_object buffers. >> + * >> + * &drm_gem_object buffers maintain a list (and a corresponding list >> lock) of >> + * &drm_gpuva objects representing all existent GPU VA mappings using >> this >> + * &drm_gem_object as backing buffer. >> + * >> + * If the &DRM_GPUVA_MANAGER_REGIONS feature is enabled, a GPU VA >> mapping can >> + * only be created within a previously allocated &drm_gpuva_region, >> which >> + * represents a reserved portion of the GPU VA space. GPU VA mappings >> are not >> + * allowed to span over a &drm_gpuva_region's boundary. >> + * >> + * GPU VA regions can also be flagged as sparse, which allows drivers >> to create >> + * sparse mappings for a whole GPU VA region in order to support Vulkan >> + * 'Sparse Resources'. > > Well since we have now found that there is absolutely no technical > reason for having those regions could we please drop them? I disagree this was the outcome of our previous discussion. In nouveau I still need them to track the separate sparse page tables and, as you confirmed previously, Nvidia cards are not the only cards supporting this feature. The second reason is that with regions we can avoid merging between buffers, which saves some effort. However, I agree that this argument by itself probably doesn't hold too much, since you've pointed out in a previous mail that: 1) If we merge and decide to only do that inside certain boundaries then those boundaries needs to be provided and checked against. This burns quite some CPU cycles 2) If we just merge what we can we might have extra page table updates which cost time and could result in undesired side effects. 3) If we don't merge at all we have additional housekeeping for the mappings and maybe hw restrictions. However, if a driver uses regions to track its separate sparse page tables anyway it gets 1) for free, which is a nice synergy. I totally agree that regions aren't for everyone though. Hence, I made them an optional feature and by default regions are disabled. In order to use them drm_gpuva_manager_init() must be called with the DRM_GPUVA_MANAGER_REGIONS feature flag. I really would not want to open code regions or have two GPUVA manager instances in nouveau to track sparse page tables. That would be really messy, hence I hope we can agree on this to be an optional feature. > > I don't really see a need for them any more. > > Regards, > Christian. > 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 6B0BFC61DA4 for ; Wed, 22 Feb 2023 15:08:03 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D6D9610E9EA; Wed, 22 Feb 2023 15:08:02 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 17EFB10E9EA for ; Wed, 22 Feb 2023 15:08:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677078479; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zRCEb4SvpDKPjZLK4vn9/q7q7Y3I8z1o20cZm/AYJwk=; b=MGAVENluDGkNE7r3DBZSkYqSbgygbAJqeSwY35bQ1PvemjAst6JJcxOQ6F5GpNnt3Gx75m 5rPjqJZTPsWY3+3Htb2vN9PASJdJJoA938u50W/Vee2spEbQ18jdY16YgRtTfEneI6nPG0 jmgBXPA4OKg8hW7amKOGd4CShtDbE5o= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-630-TqL64WIyNXyLVncBSB0BpQ-1; Wed, 22 Feb 2023 10:07:57 -0500 X-MC-Unique: TqL64WIyNXyLVncBSB0BpQ-1 Received: by mail-ed1-f69.google.com with SMTP id ck7-20020a0564021c0700b004a25d8d7593so10541354edb.0 for ; Wed, 22 Feb 2023 07:07:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zRCEb4SvpDKPjZLK4vn9/q7q7Y3I8z1o20cZm/AYJwk=; b=GOocFtC83FbnKKK0pJIAV36fMu0PqOGcP+SGNUKqd5bILAF3qD6i+PixgSbSFYdXV0 AUjLrbxBXbqcY4g++/YlBDAiMZygQbbTWcNMxiLd27hy6mDN8BrCYpfwfqfb5V1v5Sq8 rUDmKHoqrRPnWfK0psw7jZd0j+MKBRZ+sZ5Tsuz/VVJ443o4pqYXisPC53KChvQmNHx6 PGfI0YLtbFrtpzO7cEBMcIITd5bsRDValqvn4rIIzlzthaq8iv/EKEuJkI441/nMIHT4 SYh/kt8r4UNQ4a4x6/NwE8Aw/M9Jj1pgzaFYh01iZU7zEqpo+ZAhK1gAGAhBimSLTc3u 5fjg== X-Gm-Message-State: AO0yUKVgCXga2kSetNoQdhbuXrrBDmb7C/QlFDzgVhgmmQ2X4CO7PZV8 Krfj4VOCSIACedRsdEIW9OLviJxLrseiir5OOSD3FxdpUzofBA+ALMY3jWlw6hNC3nBKTU6bp+x iYecxOEnJmUfHJ4nKqyF1fzpBng== X-Received: by 2002:a17:907:1623:b0:8b1:76dd:f5f6 with SMTP id hb35-20020a170907162300b008b176ddf5f6mr29151557ejc.50.1677078475598; Wed, 22 Feb 2023 07:07:55 -0800 (PST) X-Google-Smtp-Source: AK7set8V2KGVMm3Rh6GnmJnl329zmNElexUMuVrYhLPpVZhOY6NIjF1ZDTeKB87CfdRbYWnWGPbc0Q== X-Received: by 2002:a17:907:1623:b0:8b1:76dd:f5f6 with SMTP id hb35-20020a170907162300b008b176ddf5f6mr29151515ejc.50.1677078475224; Wed, 22 Feb 2023 07:07:55 -0800 (PST) Received: from ?IPV6:2a02:810d:4b3f:de78:642:1aff:fe31:a15c? ([2a02:810d:4b3f:de78:642:1aff:fe31:a15c]) by smtp.gmail.com with ESMTPSA id q20-20020a170906771400b008e57b5e0ce9sm1160273ejm.108.2023.02.22.07.07.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Feb 2023 07:07:54 -0800 (PST) Message-ID: Date: Wed, 22 Feb 2023 16:07:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: =?UTF-8?Q?Christian_K=c3=b6nig?= References: <20230217134422.14116-1-dakr@redhat.com> <20230217134422.14116-6-dakr@redhat.com> <70ba382f-1559-289a-4922-ca9c371aaf59@amd.com> From: Danilo Krummrich Organization: RedHat In-Reply-To: <70ba382f-1559-289a-4922-ca9c371aaf59@amd.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Nouveau] [PATCH drm-next v2 05/16] drm: manager to keep track of GPUs VA mappings X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: matthew.brost@intel.com, willy@infradead.org, daniel@ffwll.ch, dri-devel@lists.freedesktop.org, corbet@lwn.net, nouveau@lists.freedesktop.org, ogabbay@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, mripard@kernel.org, linux-mm@kvack.org, alexdeucher@gmail.com, boris.brezillon@collabora.com, bskeggs@redhat.com, Liam.Howlett@oracle.com, Dave Airlie , bagasdotme@gmail.com, jason@jlekstrand.net Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" On 2/22/23 11:25, Christian König wrote: > Am 17.02.23 um 14:44 schrieb Danilo Krummrich: >> +/** >> + * DOC: Overview >> + * >> + * The DRM GPU VA Manager, represented by struct drm_gpuva_manager >> keeps track >> + * of a GPU's virtual address (VA) space and manages the >> corresponding virtual >> + * mappings represented by &drm_gpuva objects. It also keeps track of >> the >> + * mapping's backing &drm_gem_object buffers. >> + * >> + * &drm_gem_object buffers maintain a list (and a corresponding list >> lock) of >> + * &drm_gpuva objects representing all existent GPU VA mappings using >> this >> + * &drm_gem_object as backing buffer. >> + * >> + * If the &DRM_GPUVA_MANAGER_REGIONS feature is enabled, a GPU VA >> mapping can >> + * only be created within a previously allocated &drm_gpuva_region, >> which >> + * represents a reserved portion of the GPU VA space. GPU VA mappings >> are not >> + * allowed to span over a &drm_gpuva_region's boundary. >> + * >> + * GPU VA regions can also be flagged as sparse, which allows drivers >> to create >> + * sparse mappings for a whole GPU VA region in order to support Vulkan >> + * 'Sparse Resources'. > > Well since we have now found that there is absolutely no technical > reason for having those regions could we please drop them? I disagree this was the outcome of our previous discussion. In nouveau I still need them to track the separate sparse page tables and, as you confirmed previously, Nvidia cards are not the only cards supporting this feature. The second reason is that with regions we can avoid merging between buffers, which saves some effort. However, I agree that this argument by itself probably doesn't hold too much, since you've pointed out in a previous mail that: 1) If we merge and decide to only do that inside certain boundaries then those boundaries needs to be provided and checked against. This burns quite some CPU cycles 2) If we just merge what we can we might have extra page table updates which cost time and could result in undesired side effects. 3) If we don't merge at all we have additional housekeeping for the mappings and maybe hw restrictions. However, if a driver uses regions to track its separate sparse page tables anyway it gets 1) for free, which is a nice synergy. I totally agree that regions aren't for everyone though. Hence, I made them an optional feature and by default regions are disabled. In order to use them drm_gpuva_manager_init() must be called with the DRM_GPUVA_MANAGER_REGIONS feature flag. I really would not want to open code regions or have two GPUVA manager instances in nouveau to track sparse page tables. That would be really messy, hence I hope we can agree on this to be an optional feature. > > I don't really see a need for them any more. > > Regards, > Christian. > 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 9122FC636D6 for ; Wed, 22 Feb 2023 15:08:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BFCBF10E9EC; Wed, 22 Feb 2023 15:08:04 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 36DC510E9EA for ; Wed, 22 Feb 2023 15:08:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677078481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zRCEb4SvpDKPjZLK4vn9/q7q7Y3I8z1o20cZm/AYJwk=; b=IyRlixNqBqg90bX6JjASThIcEkQcTjyORydJ61ldpK8yW3nbONiR6bERJS9O5i/k6DzxK6 zBlBRdhnb7BYM8kNuUEwMKDpbaJA5A2B8kCbaqzJL9X2DqJTTRaJ1zWfvrrk8GaDb4Lnlb IxxtRqMDOtIjF3OgPLo/rtP/XFNByhw= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-14-QIgr8nscPVajiJjtSzu4sQ-1; Wed, 22 Feb 2023 10:07:59 -0500 X-MC-Unique: QIgr8nscPVajiJjtSzu4sQ-1 Received: by mail-ed1-f71.google.com with SMTP id b1-20020aa7dc01000000b004ad062fee5eso11045518edu.17 for ; Wed, 22 Feb 2023 07:07:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zRCEb4SvpDKPjZLK4vn9/q7q7Y3I8z1o20cZm/AYJwk=; b=x4H5ouKBoKBH3H5jOx18+QP0puXTtvGaWi4PoJWkm7FncjQxkuu/duS0fzQrUHNdUI JAhw/gbl2T80h+C30Il6eDv/V1LkUaoa4f4DIYkOFy9igOzX4rV/yst2WRa7g4ZEwC8+ 3cygj+D5YFXZrIpurGifxELW0HBKWUdu2ciPWR7yKNKHB/bIZbbHUGAOSN4sE6kFdRCm c81uLDiGQWGTDxfIAJT6FjGmgJqcR5Ain5xVPM3pGCau5+F8jprEF++rWinBkmr1BCOv HfTDVvQcrOlUTB2ZYYwu31OhabdIfuNfgZ7RQXh/8ErTXGGTTExif7GHlurzHaxADmnL 4jwA== X-Gm-Message-State: AO0yUKWzHOPByR/y3GEfISoaX0xXmt26dpUA9+O15nvQvSV5qIeNou6M CSdai6nHcu3dLorrFYxCmy2BYNAVfmTQetuGC/KrFOiu5ZvnYHr1vqs/LaviEDNwx6V+yTOklKx rDLMjo+0ie82BtitnquT3X5e9F8Ut X-Received: by 2002:a17:907:1623:b0:8b1:76dd:f5f6 with SMTP id hb35-20020a170907162300b008b176ddf5f6mr29151565ejc.50.1677078475601; Wed, 22 Feb 2023 07:07:55 -0800 (PST) X-Google-Smtp-Source: AK7set8V2KGVMm3Rh6GnmJnl329zmNElexUMuVrYhLPpVZhOY6NIjF1ZDTeKB87CfdRbYWnWGPbc0Q== X-Received: by 2002:a17:907:1623:b0:8b1:76dd:f5f6 with SMTP id hb35-20020a170907162300b008b176ddf5f6mr29151515ejc.50.1677078475224; Wed, 22 Feb 2023 07:07:55 -0800 (PST) Received: from ?IPV6:2a02:810d:4b3f:de78:642:1aff:fe31:a15c? ([2a02:810d:4b3f:de78:642:1aff:fe31:a15c]) by smtp.gmail.com with ESMTPSA id q20-20020a170906771400b008e57b5e0ce9sm1160273ejm.108.2023.02.22.07.07.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Feb 2023 07:07:54 -0800 (PST) Message-ID: Date: Wed, 22 Feb 2023 16:07:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH drm-next v2 05/16] drm: manager to keep track of GPUs VA mappings To: =?UTF-8?Q?Christian_K=c3=b6nig?= References: <20230217134422.14116-1-dakr@redhat.com> <20230217134422.14116-6-dakr@redhat.com> <70ba382f-1559-289a-4922-ca9c371aaf59@amd.com> From: Danilo Krummrich Organization: RedHat In-Reply-To: <70ba382f-1559-289a-4922-ca9c371aaf59@amd.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US 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: , Cc: matthew.brost@intel.com, willy@infradead.org, dri-devel@lists.freedesktop.org, corbet@lwn.net, nouveau@lists.freedesktop.org, ogabbay@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, boris.brezillon@collabora.com, bskeggs@redhat.com, tzimmermann@suse.de, Liam.Howlett@oracle.com, Dave Airlie , bagasdotme@gmail.com, jason@jlekstrand.net Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 2/22/23 11:25, Christian König wrote: > Am 17.02.23 um 14:44 schrieb Danilo Krummrich: >> +/** >> + * DOC: Overview >> + * >> + * The DRM GPU VA Manager, represented by struct drm_gpuva_manager >> keeps track >> + * of a GPU's virtual address (VA) space and manages the >> corresponding virtual >> + * mappings represented by &drm_gpuva objects. It also keeps track of >> the >> + * mapping's backing &drm_gem_object buffers. >> + * >> + * &drm_gem_object buffers maintain a list (and a corresponding list >> lock) of >> + * &drm_gpuva objects representing all existent GPU VA mappings using >> this >> + * &drm_gem_object as backing buffer. >> + * >> + * If the &DRM_GPUVA_MANAGER_REGIONS feature is enabled, a GPU VA >> mapping can >> + * only be created within a previously allocated &drm_gpuva_region, >> which >> + * represents a reserved portion of the GPU VA space. GPU VA mappings >> are not >> + * allowed to span over a &drm_gpuva_region's boundary. >> + * >> + * GPU VA regions can also be flagged as sparse, which allows drivers >> to create >> + * sparse mappings for a whole GPU VA region in order to support Vulkan >> + * 'Sparse Resources'. > > Well since we have now found that there is absolutely no technical > reason for having those regions could we please drop them? I disagree this was the outcome of our previous discussion. In nouveau I still need them to track the separate sparse page tables and, as you confirmed previously, Nvidia cards are not the only cards supporting this feature. The second reason is that with regions we can avoid merging between buffers, which saves some effort. However, I agree that this argument by itself probably doesn't hold too much, since you've pointed out in a previous mail that: 1) If we merge and decide to only do that inside certain boundaries then those boundaries needs to be provided and checked against. This burns quite some CPU cycles 2) If we just merge what we can we might have extra page table updates which cost time and could result in undesired side effects. 3) If we don't merge at all we have additional housekeeping for the mappings and maybe hw restrictions. However, if a driver uses regions to track its separate sparse page tables anyway it gets 1) for free, which is a nice synergy. I totally agree that regions aren't for everyone though. Hence, I made them an optional feature and by default regions are disabled. In order to use them drm_gpuva_manager_init() must be called with the DRM_GPUVA_MANAGER_REGIONS feature flag. I really would not want to open code regions or have two GPUVA manager instances in nouveau to track sparse page tables. That would be really messy, hence I hope we can agree on this to be an optional feature. > > I don't really see a need for them any more. > > Regards, > Christian. >