[PATCH 2/4] drm/amdkfd: Adding new IOCTL for scratch memory

[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.

Regards,
  Felix

>
> That would mean that when two processes try to set two different
> addresses we are completely lost here.
>
> Christian.