[PATCH 12/12] drm/amdgpu: enable foreign DMA-buf objects

Felix Kuehling felix.kuehling at amd.com
Tue Jul 4 20:08:41 UTC 2017


On 17-07-04 12:39 PM, Christian König wrote:
> Long story short all those cases must cleanly be handled before this
> patch series can land upstream (or even be in any hybrid release). 
FWIW, it's in 17.20.

> I'm pretty sure that the patch as is would break A+A laptops, so
> pushing it to any branch outside some KFD testing environment is a
> clear NAK from my side.

On A+A laptops, one side of the P2P is system memory, so it shouldn't be
a problem.

>
> I would also strongly discourage to use it in a production system
> until those issues are sorted out. This patch series was a technical
> prove of concept, not something we can upstream as is.
>
> What needs to be done is working on a white list for chipsets and/or
> interconnections between PCIe bus systems. 
If I understand your concerns correctly, it's that buffer sharing across
GPUs can be used in amdgpu graphics use cases today, but forces the
memory to be migrated to system memory and shared through scatter-gather
lists. I wasn't aware of such use cases. A+A laptops shouldn't be a
problem because it's not really P2P like I pointed out above.

This patch series improves buffer sharing between GPUs but breaks if the
chipset doesn't support P2P, if there are such use cases today. I'm
still sceptical about that assumption.

So we'd need some conditions to check whether P2P is supported by the
chipset (whitelist, or maybe a config option or module parameter) for
ROCm setups that need P2P. And a working fallback path (the old SG-way)
for systems where P2P is not working.

Regards,
  Felix


More information about the amd-gfx mailing list