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

[Christian König]

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