From: "Christian König" <ckoenig.leichtzumerken@gmail.com> To: "Christoph Hellwig" <hch@infradead.org>, "Jerome Glisse" <jglisse@redhat.com>, "Christian König" <christian.koenig@amd.com>, "moderated list:DMA BUFFER SHARING FRAMEWORK" <linaro-mm-sig@lists.linaro.org>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, "amd-gfx list" <amd-gfx@lists.freedesktop.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Logan Gunthorpe" <logang@deltatee.com>, "Dan Williams" <dan.j.williams@intel.com> Subject: Re: [PATCH 4/8] dma-buf: add peer2peer flag Date: Fri, 20 Apr 2018 10:58:50 +0200 [thread overview] Message-ID: <3e17afc5-7d6c-5795-07bd-f23e34cf8d4b@gmail.com> (raw) In-Reply-To: <20180420071312.GF31310@phenom.ffwll.local> Am 20.04.2018 um 09:13 schrieb Daniel Vetter: > On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote: >> On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote: >>> We've broken that assumption in i915 years ago. Not struct page backed >>> gpu memory is very real. >>> >>> Of course we'll never feed such a strange sg table to a driver which >>> doesn't understand it, but allowing sg_page == NULL works perfectly >>> fine. At least for gpu drivers. >> For GPU drivers on x86 with no dma coherency problems, sure. But not >> all the world is x86. We already have problems due to dmabugs use >> of the awkward get_sgtable interface (see the common on >> arm_dma_get_sgtable that I fully agree with), and doing this for memory >> that doesn't have a struct page at all will make things even worse. > x86 dma isn't coherent either, if you're a GPU :-) Flushing gpu caches > tends to be too expensive, so there's pci-e support and chipset support to > forgo it. Plus drivers flushing caches themselves. > > The dma_get_sgtable thing is indeed fun, right solution would probably be > to push the dma-buf export down into the dma layer. The comment for > arm_dma_get_sgtable is also not a realy concern, because dma-buf also > abstracts away the flushing (or well is supposed to), so there really > shouldn't be anyone calling the streaming apis on the returned sg table. > That's why dma-buf gives you an sg table that's mapped already. > >>> If that's not acceptable then I guess we could go over the entire tree >>> and frob all the gpu related code to switch over to a new struct >>> sg_table_might_not_be_struct_page_backed, including all the other >>> functions we added over the past few years to iterate over sg tables. >>> But seems slightly silly, given that sg tables seem to do exactly what >>> we need. >> It isn't silly. We will have to do some surgery like that anyway >> because the current APIs don't work. So relax, sit back and come up >> with an API that solves the existing issues and serves us well in >> the future. > So we should just implement a copy of sg table for dma-buf, since I still > think it does exactly what we need for gpus? > > Yes there's a bit a layering violation insofar that drivers really > shouldn't each have their own copy of "how do I convert a piece of dma > memory into dma-buf", but that doesn't render the interface a bad idea. Completely agree on that. What we need is an sg_alloc_table_from_resources(dev, resources, num_resources) which does the handling common to all drivers. Christian. > -Daniel
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: "Christoph Hellwig" <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, "Jerome Glisse" <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>, "moderated list:DMA BUFFER SHARING FRAMEWORK" <linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>, "open list:DMA BUFFER SHARING FRAMEWORK" <linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, dri-devel <dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>, "amd-gfx list" <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>, "Linux Kernel Mailing List" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "Logan Gunthorpe" <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>, "Dan Williams" <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Subject: Re: [PATCH 4/8] dma-buf: add peer2peer flag Date: Fri, 20 Apr 2018 10:58:50 +0200 [thread overview] Message-ID: <3e17afc5-7d6c-5795-07bd-f23e34cf8d4b@gmail.com> (raw) In-Reply-To: <20180420071312.GF31310-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> Am 20.04.2018 um 09:13 schrieb Daniel Vetter: > On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote: >> On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote: >>> We've broken that assumption in i915 years ago. Not struct page backed >>> gpu memory is very real. >>> >>> Of course we'll never feed such a strange sg table to a driver which >>> doesn't understand it, but allowing sg_page == NULL works perfectly >>> fine. At least for gpu drivers. >> For GPU drivers on x86 with no dma coherency problems, sure. But not >> all the world is x86. We already have problems due to dmabugs use >> of the awkward get_sgtable interface (see the common on >> arm_dma_get_sgtable that I fully agree with), and doing this for memory >> that doesn't have a struct page at all will make things even worse. > x86 dma isn't coherent either, if you're a GPU :-) Flushing gpu caches > tends to be too expensive, so there's pci-e support and chipset support to > forgo it. Plus drivers flushing caches themselves. > > The dma_get_sgtable thing is indeed fun, right solution would probably be > to push the dma-buf export down into the dma layer. The comment for > arm_dma_get_sgtable is also not a realy concern, because dma-buf also > abstracts away the flushing (or well is supposed to), so there really > shouldn't be anyone calling the streaming apis on the returned sg table. > That's why dma-buf gives you an sg table that's mapped already. > >>> If that's not acceptable then I guess we could go over the entire tree >>> and frob all the gpu related code to switch over to a new struct >>> sg_table_might_not_be_struct_page_backed, including all the other >>> functions we added over the past few years to iterate over sg tables. >>> But seems slightly silly, given that sg tables seem to do exactly what >>> we need. >> It isn't silly. We will have to do some surgery like that anyway >> because the current APIs don't work. So relax, sit back and come up >> with an API that solves the existing issues and serves us well in >> the future. > So we should just implement a copy of sg table for dma-buf, since I still > think it does exactly what we need for gpus? > > Yes there's a bit a layering violation insofar that drivers really > shouldn't each have their own copy of "how do I convert a piece of dma > memory into dma-buf", but that doesn't render the interface a bad idea. Completely agree on that. What we need is an sg_alloc_table_from_resources(dev, resources, num_resources) which does the handling common to all drivers. Christian. > -Daniel _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2018-04-20 8:58 UTC|newest] Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-25 10:59 [PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 2/8] PCI: Add pci_find_common_upstream_dev() Christian König 2018-03-25 10:59 ` Christian König 2018-03-28 12:38 ` Christoph Hellwig 2018-03-28 15:07 ` Christian König 2018-03-28 15:07 ` Christian König 2018-03-28 15:47 ` Logan Gunthorpe 2018-03-28 16:02 ` Christian König 2018-03-28 16:02 ` Christian König 2018-03-28 16:25 ` Logan Gunthorpe 2018-03-28 18:28 ` Christian König 2018-03-28 18:28 ` Christian König 2018-03-28 18:57 ` Logan Gunthorpe 2018-03-28 19:44 ` Christian König 2018-03-28 19:44 ` Christian König 2018-03-28 19:53 ` Logan Gunthorpe 2018-03-29 11:44 ` Christian König 2018-03-29 15:45 ` Logan Gunthorpe 2018-03-29 16:10 ` Christian König 2018-03-29 16:10 ` Christian König 2018-03-29 16:25 ` Logan Gunthorpe 2018-03-29 18:15 ` Christian König 2018-03-29 18:15 ` Christian König 2018-03-30 1:58 ` Jerome Glisse 2018-03-30 1:58 ` Jerome Glisse 2018-03-30 6:33 ` Christoph Hellwig 2018-03-30 6:33 ` Christoph Hellwig 2018-03-30 15:25 ` Jerome Glisse 2018-03-30 18:46 ` Logan Gunthorpe 2018-03-30 19:45 ` Jerome Glisse 2018-03-30 19:45 ` Jerome Glisse 2018-04-02 17:02 ` Logan Gunthorpe 2018-04-02 17:20 ` Jerome Glisse 2018-04-02 17:20 ` Jerome Glisse 2018-04-02 17:37 ` Logan Gunthorpe 2018-04-02 19:16 ` Jerome Glisse 2018-04-02 19:16 ` Jerome Glisse 2018-04-02 19:32 ` Logan Gunthorpe 2018-04-02 19:45 ` Jerome Glisse 2018-04-02 19:45 ` Jerome Glisse [not found] ` <CADnq5_P-z=Noos_jaME9_CERri3C-m2hPPvx2bArr36O=1FnrA@mail.gmail.com> 2018-03-29 14:37 ` Alex Deucher 2018-03-29 14:37 ` Alex Deucher 2018-03-25 10:59 ` [PATCH 3/8] PCI: Add pci_peer_traffic_supported() Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 4/8] dma-buf: add peer2peer flag Christian König 2018-03-25 10:59 ` Christian König 2018-03-29 6:57 ` Daniel Vetter 2018-03-29 6:57 ` Daniel Vetter 2018-03-29 11:34 ` Christian König 2018-03-29 11:34 ` Christian König 2018-04-03 9:09 ` Daniel Vetter 2018-04-03 9:09 ` Daniel Vetter 2018-04-03 17:06 ` Jerome Glisse 2018-04-03 17:06 ` Jerome Glisse 2018-04-03 18:08 ` Daniel Vetter 2018-04-03 18:08 ` Daniel Vetter 2018-04-16 12:39 ` Christoph Hellwig 2018-04-16 12:39 ` Christoph Hellwig 2018-04-16 13:38 ` Daniel Vetter 2018-04-16 13:38 ` Daniel Vetter 2018-04-19 8:16 ` Christoph Hellwig 2018-04-19 8:16 ` Christoph Hellwig 2018-04-20 7:13 ` Daniel Vetter 2018-04-20 7:13 ` Daniel Vetter 2018-04-20 8:58 ` Christian König [this message] 2018-04-20 8:58 ` Christian König 2018-04-20 10:17 ` Christoph Hellwig 2018-04-20 10:17 ` Christoph Hellwig 2018-04-20 10:44 ` Christian König 2018-04-20 10:44 ` Christian König 2018-04-20 12:46 ` Christoph Hellwig 2018-04-20 15:21 ` [Linaro-mm-sig] " Daniel Vetter 2018-04-24 18:48 ` Christoph Hellwig 2018-04-24 18:48 ` Christoph Hellwig 2018-04-24 19:32 ` Daniel Vetter 2018-04-24 19:32 ` Daniel Vetter 2018-04-25 5:48 ` Christoph Hellwig 2018-04-25 5:48 ` Christoph Hellwig 2018-04-25 6:10 ` Alex Deucher 2018-04-25 6:10 ` Alex Deucher 2018-04-25 6:13 ` Daniel Vetter 2018-04-25 6:13 ` Daniel Vetter 2018-04-25 6:23 ` Daniel Vetter 2018-04-25 6:23 ` Daniel Vetter 2018-04-25 6:43 ` Christoph Hellwig 2018-04-25 6:43 ` Christoph Hellwig 2018-04-25 7:02 ` Daniel Vetter 2018-04-25 7:02 ` Daniel Vetter 2018-04-25 7:09 ` Christoph Hellwig 2018-04-25 7:09 ` Christoph Hellwig 2018-04-25 7:30 ` Daniel Vetter 2018-04-25 7:30 ` Daniel Vetter 2018-04-25 7:56 ` Thierry Reding 2018-04-25 7:56 ` Thierry Reding 2018-04-25 8:55 ` Christoph Hellwig 2018-04-25 8:55 ` Christoph Hellwig 2018-04-25 7:43 ` Thierry Reding 2018-04-25 7:43 ` Thierry Reding 2018-04-25 7:41 ` Thierry Reding 2018-04-25 7:41 ` Thierry Reding 2018-04-25 8:54 ` noveau vs arm dma ops Christoph Hellwig 2018-04-25 8:54 ` Christoph Hellwig 2018-04-25 8:54 ` Christoph Hellwig 2018-04-25 9:25 ` Russell King - ARM Linux 2018-04-25 9:25 ` Russell King - ARM Linux 2018-04-25 10:04 ` Daniel Vetter 2018-04-25 10:04 ` Daniel Vetter 2018-04-25 10:04 ` Daniel Vetter 2018-04-25 15:33 ` Christoph Hellwig 2018-04-25 15:33 ` Christoph Hellwig 2018-04-25 15:33 ` Christoph Hellwig 2018-04-25 21:35 ` Daniel Vetter 2018-04-25 21:35 ` Daniel Vetter 2018-04-25 21:35 ` Daniel Vetter 2018-04-25 23:26 ` Russell King - ARM Linux 2018-04-25 23:26 ` Russell King - ARM Linux 2018-04-26 9:17 ` Daniel Vetter 2018-04-26 9:17 ` Daniel Vetter 2018-04-26 9:17 ` Daniel Vetter 2018-04-26 9:09 ` Christoph Hellwig 2018-04-26 9:09 ` Christoph Hellwig 2018-04-26 9:09 ` Christoph Hellwig 2018-04-26 9:45 ` Daniel Vetter 2018-04-26 9:45 ` Daniel Vetter 2018-04-26 9:45 ` Daniel Vetter 2018-04-26 11:12 ` Russell King - ARM Linux 2018-04-26 11:12 ` Russell King - ARM Linux 2018-04-25 22:54 ` Russell King - ARM Linux 2018-04-25 22:54 ` Russell King - ARM Linux 2018-04-26 9:13 ` Christoph Hellwig 2018-04-26 9:13 ` Christoph Hellwig 2018-04-26 9:13 ` Christoph Hellwig 2018-04-26 9:20 ` [Linaro-mm-sig] " Daniel Vetter 2018-04-26 9:20 ` Daniel Vetter 2018-04-26 9:20 ` Daniel Vetter 2018-04-26 9:24 ` Christoph Hellwig 2018-04-26 9:24 ` Christoph Hellwig 2018-04-26 9:24 ` Christoph Hellwig 2018-04-26 9:39 ` Daniel Vetter 2018-04-26 9:39 ` Daniel Vetter 2018-04-26 9:39 ` Daniel Vetter 2018-04-25 6:24 ` [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag Alex Deucher 2018-04-25 6:24 ` Alex Deucher 2018-04-25 6:41 ` Christoph Hellwig 2018-04-25 6:41 ` Christoph Hellwig 2018-04-25 17:44 ` Alex Deucher 2018-04-25 17:44 ` Alex Deucher 2018-04-25 18:38 ` Dan Williams 2018-04-25 18:38 ` Dan Williams 2018-05-04 12:45 ` Lucas Stach 2018-03-25 10:59 ` [PATCH 5/8] drm/amdgpu: print DMA-buf status in debugfs Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 6/8] drm/amdgpu: note that we can handle peer2peer DMA-buf Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 10:59 ` [PATCH 7/8] drm/amdgpu: add amdgpu_gem_attach Christian König 2018-03-25 10:59 ` Christian König 2018-03-25 11:00 ` [PATCH 8/8] drm/amdgpu: add support for exporting VRAM using DMA-buf Christian König 2018-03-25 11:00 ` Christian König 2018-03-28 12:37 ` [PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper Christoph Hellwig 2018-03-28 12:37 ` Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3e17afc5-7d6c-5795-07bd-f23e34cf8d4b@gmail.com \ --to=ckoenig.leichtzumerken@gmail.com \ --cc=amd-gfx@lists.freedesktop.org \ --cc=christian.koenig@amd.com \ --cc=dan.j.williams@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=hch@infradead.org \ --cc=jglisse@redhat.com \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=logang@deltatee.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.