On 2017-08-22 04:52 AM, Christian König wrote:
>> BTW, on Vega10 the way scratch works has been changed, and this ioctl
>> becomes basically a no-op. The SH_HIDDEN_PRIVATE_BASE_VMID register no
>> longer exists. Instead the base address is now provided to the shader
>> directly without being programmed ahead of time by KFD or HWS. Setting
>> up scratch memory per queue is entirely up to the Runtime now.
>
> So essentially this is actually more a workaround to set a privileged
> register by the hardware scheduler when it switches between tasks.
Sort of. In case we run without HWS it's programmed by the driver once
(because we assign VMIDs statically in that case).
>
> Do we have more cases like this? In other words would it make sense to
> generalize this interface to something like "Please HWS when you
> switch to one of my tasks can you set register X to value Y"?
In general, if you're looking for process-specific information that's
programmed by the HWS, the MAP_PROCESS PM4 packet definition is a good
place to look. Beside the sh_hidden_private_base_vmid it includes
information about virtual memory address apertures. Part of this is
handled by the set_memory_policy ioctl that's already upstream. More
will be added by a dGPU-specific ioctl:
struct kfd_ioctl_set_process_dgpu_aperture_args {
uint64_t dgpu_base;
uint64_t dgpu_limit;
uint32_t gpu_id;
uint32_t pad;
};
The only other similar thing that comes to mind is the secondary trap
handler address. But that's not programmed in a register, but in a
memory buffer associated with the first level trap handler.
Regards,
Felix
>
> Regards,
> Christian.
