Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 20 Jan 2023 11:08:33 +0100
From:   Boris Brezillon <boris.brezillon@collabora.com>
To:     Matthew Brost <matthew.brost@intel.com>
Cc:     Danilo Krummrich <dakr@redhat.com>,
        dri-devel@lists.freedesktop.org, corbet@lwn.net,
        tzimmermann@suse.de,
        "Thomas =?UTF-8?B?SGVsbHN0csO2bQ==?= (Intel)" 
        <thomas_os@shipmail.org>, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, bskeggs@redhat.com,
        jason@jlekstrand.net, nouveau@lists.freedesktop.org,
        airlied@redhat.com, christian.koenig@amd.com
Subject: Re: [PATCH drm-next 13/14] drm/nouveau: implement new VM_BIND UAPI
Message-ID: <20230120110833.76cc7864@collabora.com>
In-Reply-To: <Y8jOCE/PyNZ2Z6aX@DUT025-TGLU.fm.intel.com>
References: <20230118061256.2689-1-dakr@redhat.com>
        <20230118061256.2689-14-dakr@redhat.com>
        <e371e8a1-88f8-1309-07ca-f48f4157fec8@shipmail.org>
        <8e10b46c-f934-8eee-904e-b3d8a7644a71@redhat.com>
        <Y8jOCE/PyNZ2Z6aX@DUT025-TGLU.fm.intel.com>
Organization: Collabora
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 19 Jan 2023 04:58:48 +0000
Matthew Brost <matthew.brost@intel.com> wrote:

> > For the ops structures the drm_gpuva_manager allocates for reporting the
> > split/merge steps back to the driver I have ideas to entirely avoid
> > allocations, which also is a good thing in respect of Christians feedback
> > regarding the huge amount of mapping requests some applications seem to
> > generate.
> >  
> 
> It should be fine to have allocations to report the split/merge step as
> this step should be before a dma-fence is published, but yea if possible
> to avoid extra allocs as that is always better.
> 
> Also BTW, great work on drm_gpuva_manager too. We will almost likely
> pick this up in Xe rather than open coding all of this as we currently
> do. We should probably start the port to this soon so we can contribute
> to the implementation and get both of our drivers upstream sooner.

Also quite interested in using this drm_gpuva_manager for pancsf, since
I've been open-coding something similar. Didn't have the
gpuva_region concept to make sure VA mapping/unmapping requests don't
don't go outside a pre-reserved region, but it seems to automate some
of the stuff I've been doing quite nicely.