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. Regards, Felix > > That would mean that when two processes try to set two different > addresses we are completely lost here. > > Christian.
