On 8/16/22 15:03, Christian König wrote: > Am 16.08.22 um 13:44 schrieb Dmitry Osipenko: >> [SNIP] >>> The other complication I noticed is that we don't seem to keep around >>> the fd after importing to a GEM handle. And I could imagine that >>> doing so could cause issues with too many fd's. So I guess the best >>> thing is to keep the status quo and let drivers that cannot mmap >>> imported buffers just fail mmap? >> That actually should be all the drivers excluding those that use >> DRM-SHMEM because only DRM-SHMEM uses dma_buf_mmap(), that's why it >> works for Panfrost. I'm pretty sure mmaping of imported GEMs doesn't >> work for the MSM driver, isn't it? >> >> Intel and AMD drivers don't allow to map the imported dma-bufs. Both >> refuse to do the mapping. >> >> Although, AMDGPU "succeeds" to do the mapping using >> AMDGPU_GEM_DOMAIN_GTT, but then touching the mapping causes bus fault, >> hence mapping actually fails. I think it might be the AMDGPU >> driver/libdrm bug, haven't checked yet. > > That's then certainly broken somehow. Amdgpu should nerve ever have > allowed to mmap() imported DMA-bufs and the last time I check it didn't. I'll take a closer look. So far I can only tell that it's a kernel driver issue because once I re-applied this "Don't map imported GEMs" patch, AMDGPU began to refuse mapping AMDGPU_GEM_DOMAIN_GTT. >> So we're back to the point that neither of DRM drivers need to map >> imported dma-bufs and this was never tested. In this case this patch is >> valid, IMO. Actually, I'm now looking at Etnaviv and Nouveau and seems they should map imported dma-buf properly. I know that people ran Android on Etnaviv. So maybe devices with a separated GPU/display need to map imported display BO for Android support. Wish somebody who ran Android on one of these devices using upstream drivers could give a definitive answer. I may try to test Nouveau later on. -- Best regards, Dmitry
