Am 03.10.2018 um 09:14 schrieb Daniel Vetter: > On Sat, Sep 29, 2018 at 9:27 AM Koenig, Christian > <Christian.Koenig@xxxxxxx> wrote: >> This is work in progress. >> >> I published patches to enable DMA_buf P2P a few months ago, but now I'm waiting for the PCI subsystem to pick up core support for this. >> >> I can prepare you a branch based on current upstream kernel next week if you want to test this. > Thread hijack, since I just read the lwn article on p2p for storage folks: > > https://lwn.net/Articles/767281/ > > Totally doesn't match what I remember of your dma-buf p2p work. Do we > need to rework, or is this some kind of higher-level interface on top > of the raw p2p pci stuff? Or do I misremember. The P2P from the storage folks are some mix of raw p2p capability detection for PCI and higher level interface. I'm actually waiting for that stuff to land to extract the p2p capability detection and use it for this DMA-buf stuff as well. Alternative would be to convince Logan to extract the capability detection in his patch set as well, but so far he wasn't very keen about that. Christian. > > Thanks, Daniel > >> Regards, >> Christian. >> >> Am 29.09.2018 09:01 schrieb Dirk Eibach <dirk.eibach@xxxxxxxxxxxxxx>: >> I want to access GPU VRAM via PCIe P2P access, like DirectGMA but with >> mainline drivers. >> I can acquire a dmabuf from the GPU and pass it to my PCIe >> framegrabber. But I don't see a way to get the PCIe bus address of the >> video memory which I need for the P2P transfer. Is there already any >> infrastructure in place for doing this? If not, what would be the >> right way to implement this? Add another callback to the dmabuf >> struct? >> >> Cheers >> Dirk >> _______________________________________________ >> dri-devel mailing list >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
