Re: [PATCH] drm/[amdgpu|radeon]: fix memset on io mem

[Chen Li <chenli@uniontech.com>]

On Wed, 16 Dec 2020 22:19:11 +0800,
Christian König wrote:
> 
> Am 16.12.20 um 14:48 schrieb Chen Li:
> > On Wed, 16 Dec 2020 15:59:37 +0800,
> > Christian König wrote:
> >> Am 16.12.20 um 06:41 schrieb Chen Li:
> >>> When using e8860(gcn1) on arm64, the kernel crashed on drm/radeon:
> >>> [SNIP]
> >>> Obviously, the __memset call is generated by gcc(8.3.1). It optimizes
> >>> this for loop into memset. But this may break, because dest here is
> >>> cpu_addr mapped to io mem. So, just invoke `memset_io` directly, which
> >>> do solve the problem here.
> >> Well interesting problem you stumbled over here, but the solution is quite a
> >> hack.
> > Hi, Christian. I'm not sure why this change is a hack here. I cannot see the problem and wll be grateful if you give more explainations.
> 
> __memset is supposed to work on those addresses, otherwise you can't use the
> e8860 on your arm64 system.
If __memset is supposed to work on those adresses, why this commit(https://github.com/torvalds/linux/commit/ba0b2275a6781b2f3919d931d63329b5548f6d5f) is needed? (I also notice drm/radeon didn't take this change though) just out of curiosity.
> 
> Replacing the the direct write in the kernel with calls to writel() or
> memset_io() will fix that temporary, but you have a more general problem here.
 
I cannot see what's the more general problem here :( u mean performance?
> >> For amdgpu I suggest that we allocate the UVD message in GTT instead of VRAM
> >> since we don't have the hardware restriction for that on the new generations.
> >> 
> > Thanks, I will try to dig into deeper. But what's the "hardware restriction" meaning here? I'm not familiar with video driver stack and amd gpu, sorry.
> 
> On older hardware (AGP days) the buffer had to be in VRAM (MMIO) memory, but on
> modern system GTT (system memory) works as well.
IIUC, e8860 can use amdgpu(I use radeon now) beause its device id 6822 is in amdgpu's table. But I cannot tell whether e8860 has iommu, and I cannot find iommu from lspci, so graphics translation table may not work here?
> 
> >> For radeon I think the better approach would be to convert the direct memory
> >> writes into calls to writel().
> > Ok, so you mean the more proper way is to use writel instead of memset_io?
> 
> Well, it is a start. But I'm not sure if you will ever get that hardware working
> with this CPU.
> 
> >> BTW: How does userspace work on arm64 then? The driver stack usually only works
> >> if mmio can be mapped directly.
> > I also post two usespace issue on mesa, and you may be interested with them:
> >   https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F3954&data=04%7C01%7Cchristian.koenig%40amd.com%7Cd6ff52383a454a6dc03108d8a1c94dc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437233268588747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RDESyzYBB3ql2GgBigsYf%2Fx2g6zwCq%2Fy8HQ0AAMtX90%3D&reserved=0
> >   https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fissues%2F3951&data=04%7C01%7Cchristian.koenig%40amd.com%7Cd6ff52383a454a6dc03108d8a1c94dc1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637437233268588747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y5f9Ki%2FQ8G4zn3MjLVG7yiLLCxbhTyNelZj36hAuXQY%3D&reserved=0
> > I paste some virtual memory map in userspace there. (and the two problems do bother me quite a long time.)
> 
> I don't really see a solution for those problems.
> 
> See it is perfectly valid for an application to memset/memcpy on mmaped MMIO
> space which comes from OpenGL or Vulkan.
> 
> So your CPU simply won't work with the hardware. We could work around that with
> a couple of hacks, but this is a pretty much general problem.
> 
> Regards,
> Christian.
 
Thanks! Can you provid some details about these hacks? Should I post another issue on the mail list?
 


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel