Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <6e107811295b7fdd96525453ea5587ee6adc1b06.camel@ndufresne.ca>
Subject: Re: DMA-buf and uncached system memory
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Christian =?ISO-8859-1?Q?K=F6nig?= <christian.koenig@amd.com>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        linux-media <linux-media@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        linaro-mm-sig@lists.linaro.org, lkml <linux-kernel@vger.kernel.org>
Cc:     "Sharma, Shashank" <Shashank.Sharma@amd.com>
Date:   Mon, 15 Feb 2021 15:46:39 -0500
In-Reply-To: <80c42ce0-6df1-71ab-81ec-e46cc56840ba@amd.com>
References: <91ff0bbb-ea3a-2663-3453-dea96ccd6dd8@amd.com>
         <e6897f92-4c61-cd42-2822-43c50a744d4c@suse.de>
         <302e06ad-f979-dc77-5d84-fa0923aa4632@suse.de>
         <80c42ce0-6df1-71ab-81ec-e46cc56840ba@amd.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Le lundi 15 février 2021 à 13:10 +0100, Christian König a écrit :
> 
> 
> Am 15.02.21 um 13:00 schrieb Thomas Zimmermann:
> > Hi
> > 
> > Am 15.02.21 um 10:49 schrieb Thomas Zimmermann:
> > > Hi
> > > 
> > > Am 15.02.21 um 09:58 schrieb Christian König:
> > > > Hi guys,
> > > > 
> > > > we are currently working an Freesync and direct scan out from system 
> > > > memory on AMD APUs in A+A laptops.
> > > > 
> > > > On problem we stumbled over is that our display hardware needs to 
> > > > scan out from uncached system memory and we currently don't have a 
> > > > way to communicate that through DMA-buf.
> > 
> > Re-reading this paragrah, it sounds more as if you want to let the 
> > exporter know where to move the buffer. Is this another case of the 
> > missing-pin-flag problem?
> 
> No, your original interpretation was correct. Maybe my writing is a bit 
> unspecific.
> 
> The real underlying issue is that our display hardware has a problem 
> with latency when accessing system memory.
> 
> So the question is if that also applies to for example Intel hardware or 
> other devices as well or if it is just something AMD specific?

I do believe that the answer is yes, Intel display have similar issue with
latency, hence requires un-cached memory.

> 
> Regards,
> Christian.
> 
> > 
> > Best regards
> > Thomas
> > 
> > > > 
> > > > For our specific use case at hand we are going to implement 
> > > > something driver specific, but the question is should we have 
> > > > something more generic for this?
> > > 
> > > For vmap operations, we return the address as struct dma_buf_map, 
> > > which contains additional information about the memory buffer. In 
> > > vram helpers, we have the interface drm_gem_vram_offset() that 
> > > returns the offset of the GPU device memory.
> > > 
> > > Would it be feasible to combine both concepts into a dma-buf 
> > > interface that returns the device-memory offset plus the additional 
> > > caching flag?
> > > 
> > > There'd be a structure and a getter function returning the structure.
> > > 
> > > struct dma_buf_offset {
> > >      bool cached;
> > >      u64 address;
> > > };
> > > 
> > > // return offset in *off
> > > int dma_buf_offset(struct dma_buf *buf, struct dma_buf_off *off);
> > > 
> > > Whatever settings are returned by dma_buf_offset() are valid while 
> > > the dma_buf is pinned.
> > > 
> > > Best regards
> > > Thomas
> > > 
> > > > 
> > > > After all the system memory access pattern is a PCIe extension and 
> > > > as such something generic.
> > > > 
> > > > Regards,
> > > > Christian.
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > 
> > > 
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > 
> > 
>