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
