[Mesa-dev] [PATCH 2/3] radv: hardcode shader WAVE_LIMIT to the maximum value

Samuel Pitoiset samuel.pitoiset at gmail.com
Tue Aug 14 12:29:48 UTC 2018



On 8/1/18 5:12 AM, Marek Olšák wrote:
> On Fri, Oct 20, 2017 at 4:34 PM, Andres Rodriguez <andresx7 at gmail.com> wrote:
>> When WAVE_LIMIT is set, a submission will opt-in for SPI based resource
>> scheduling. Because this mechanism is cooperative, we must ensure that
>> all submissions have this field set, otherwise they will bypass resource
>> arbitration.
>>
>> We always hardcode the field to its maximum value, instead of
>> attempting to calculate an approximate usage. In testing, there were no
>> benefits to using anything other than the maximum.
>>
>> Signed-off-by: Andres Rodriguez <andresx7 at gmail.com>
>> ---
>>   src/amd/vulkan/si_cmd_buffer.c          | 27 ++++++++++++++++++---------
>>   src/gallium/drivers/radeonsi/si_state.c | 21 ++++++++++++++-------
>>   2 files changed, 32 insertions(+), 16 deletions(-)
>>
>> diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
>> index de3b388..ac3dff8 100644
>> --- a/src/amd/vulkan/si_cmd_buffer.c
>> +++ b/src/amd/vulkan/si_cmd_buffer.c
>> @@ -179,7 +179,8 @@ si_emit_compute(struct radv_physical_device *physical_device,
>>          radeon_emit(cs, 0);
>>          radeon_emit(cs, 0);
>>
>> -       radeon_set_sh_reg_seq(cs, R_00B854_COMPUTE_RESOURCE_LIMITS, 3);
>> +       radeon_set_sh_reg_seq(cs, R_00B854_COMPUTE_RESOURCE_LIMITS,
>> +                             S_00B854_WAVES_PER_SH(0x3));
> 
> This part doesn't set WAVES_PER_SH. Also, the number 3 would be wrong for it.

This is just a default value for that register. COMPUTE_RESOURCE_LIMITS 
is computed like RadeonSI when we generate the PM4 stuff for compute 
pipelines, and then emitted at dispatch time.

Do you think we should remove that default value?

> 
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 


More information about the mesa-dev mailing list