Am 15.08.2017 um 18:03 schrieb Felix Kuehling: > On 2017-08-15 04:24 AM, Christian König wrote: >> Am 14.08.2017 um 17:31 schrieb Felix Kuehling: >>> [SNIP] >>> Repeating the same argument I made on another email: >> Commented on that in the other mail, let's keep the discussion on this >> topic there. >> >>>> BTW: What exactly this this good for? >>> Scratch memory is private memory per work-item. It's used when a shader >>> program has too few registers available. With HSA we use flat scratch >>> addressing, where shaders can access private memory in a special scratch >>> aperture using normal memory instructions. Using the same virtual >>> address, each work item gets its own private piece of memory. The >>> hardware does the address translation from the VA in the private >>> aperture to a scratch-backing VA. The application is responsible for >>> allocating the memory to back that scratch area, and to map it somewhere >>> in its virtual address space. >>> >>> This ioctl tells the hardware (or HWS firmware) the VA of the scratch >>> backing memory. >> Ok, you've got me lost here. Not that I'm deeply into that stuff, but >> my last status is that those apertures are global and not per/process >> or VMID. > The apertures for private (scratch) and LDS are configured in > SH_MEM_BASES. As far as I know, this is per VMID. At least that's the > way gfx_v8_0_init_compute_vmid initializes it. When we use the HWS we > don't program this directly, but this information is included in the > map_process packet in the runlist and the firmware programs the > registers when it assigns a VMID to a process. > > The scratch backing VA is configured in SH_HIDDEN_PRIVATE_BASE_VMID, > which is per VMID. Again, with the HWS, this is programmed by the > firmware and the driver just includes it in the map_process packet. Ok, that makes sense to me. The same question came up in a different context a few month back in a thread and I probably just confused this with some other SH_* registers which turned out to be global while we always thought it is per VMID. Christian. > Regards, > Felix > >> That would mean that when two processes try to set two different >> addresses we are completely lost here. >> >> Christian. > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
