Re: [PATCH v3 5/5] drm/amdgpu: switch workload context to/from compute

["Sharma, Shashank" <shashank.sharma@amd.com>]

On 9/29/2022 3:37 PM, Lazar, Lijo wrote:
> To be clear your understanding -
> 
> Nothing is automatic in PMFW. PMFW picks a priority based on the actual 
> mask sent by driver.
> 
> Assuming lower bits corresponds to highest priority -
> 
> If driver sends a mask with Bit3 and Bit 0 set, PMFW will chose profile 
> that corresponds to Bit0. If driver sends a mask with Bit4 Bit2 set and 
> rest unset, PMFW will chose profile that corresponds to Bit2. However if 
> driver sends a mask only with a single bit set, it chooses the profile 
> regardless of whatever was the previous profile. t doesn't check if the 
> existing profile > newly requested one. That is the behavior.
> 
> So if a job send chooses a profile that corresponds to Bit0, driver will 
> send that. Next time if another job chooses a profile that corresponds 
> to Bit1, PMFW will receive that as the new profile and switch to that. 
> It trusts the driver to send the proper workload mask.
> 
> Hope that gives the picture.
>


Thanks, my understanding is also similar, referring to the core power 
switch profile function here: amd_powerplay.c::pp_dpm_switch_power_profile()
*snip code*
hwmgr->workload_mask |= (1 << hwmgr->workload_prority[type]);
		index = fls(hwmgr->workload_mask);
		index = index <= Workload_Policy_Max ? index - 1 : 0;
		workload = hwmgr->workload_setting[index];
*snip_code*
hwmgr->hwmgr_func->set_power_profile_mode(hwmgr, &workload, 0);

Here I can see that the new workload mask is appended into the existing 
workload mask (not overwritten). So if we keep sending new 
workload_modes, they would be appended into the workload flags and 
finally the PM will pick the most aggressive one of all these flags, as 
per its policy.

Now, when we have a single workload:
-> Job1: requests profile P1 via UAPI, ref count = 1
-> driver sends flags for p1
-> PM FW applies profile P1
-> Job executes in profile P1
-> Job goes to reset function, ref_count = 0,
-> Power profile resets

Now, we have conflicts only when we see multiple workloads (Job1 and Job 2)
-> Job1: requests profile P1 via UAPI, ref count = 1
-> driver sends flags for p1
-> PM FW applies profile P1
-> Job executes in profile P1
-> Job2: requests profile P2 via UAPI, refcount = 2
-> driver sends flags for (P1|P2)
-> PM FW picks the more aggressive of the two (Say P1, stays in P1)
-> Job1 goes to reset function, ref_count = 1, job1 does not reset power 
profile
-> Job2 goes to reset function, ref_counter = 2, job 2 resets Power profile
-> Power profile resets to None

So this state machine looks like if there is only 1 job, it will be 
executed in desired mode. But if there are multiple, the most aggressive 
profile will be picked, and every job will be executed in atleast the 
requested power profile mode or higher.

Do you find any problem so far ?

- Shashank


> Thanks,
> Lijo