[Mesa-dev] [PATCH 3/3] gallium/radeon: pass LLVM processor to the disk shader cache

[Timothy Arceri]

On 18/08/17 20:49, Nicolai Hähnle wrote:
> On 11.08.2017 20:37, Marek Olšák wrote:
>> On Fri, Aug 11, 2017 at 6:00 PM, Nicolai Hähnle <nhaehnle at gmail.com> 
>> wrote:
>>> On 10.08.2017 21:57, Marek Olšák wrote:
>>>>
>>>> From: Marek Olšák <marek.olsak at amd.com>
>>>>
>>>> ---
>>>>    src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
>>>> b/src/gallium/drivers/radeon/r600_pipe_common.c
>>>> index 95458d2e..0038c9a 100644
>>>> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
>>>> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
>>>> @@ -878,21 +878,21 @@ static void r600_disk_cache_create(struct
>>>> r600_common_screen *rscreen)
>>>>    #endif
>>>>                  if (res != -1) {
>>>>                          /* These flags affect shader compilation. */
>>>>                          uint64_t shader_debug_flags =
>>>>                                  rscreen->debug_flags &
>>>>                                  (DBG_FS_CORRECT_DERIVS_AFTER_KILL |
>>>>                                   DBG_SI_SCHED |
>>>>                                   DBG_UNSAFE_MATH);
>>>>                          rscreen->disk_shader_cache =
>>>> -
>>>> disk_cache_create(r600_get_family_name(rscreen),
>>>> +
>>>> disk_cache_create(r600_get_llvm_processor_name(rscreen->family),
>>>
>>>
>>> What's the advantage of this?
>>
>> It's added to the shader cache key. It allows shaders cached for
>> Vega10 to be used by Raven and vice versa. Same for Polaris11 and
>> Polaris12. It makes things nicer for some multi-GPU setups or when
>> swapping GPUs.
> 
> I'm not a huge fan of this since the shader code does have access to the 
> family, and there might be a need for family-specific workarounds. I'm 
> actually not a huge fan of this overall, because the debug_flags thing 
> seems flaky as well.
> 
> There's currently some corruption in Unigine demos which seems related 
> to the shader cache, which just goes to show how difficult it is to 
> really get this stuff right. I'd rather be on the safe side.

I'm not sure if its related, but I noticed recently that there was at 
least 1 piglit test that seems to have regressed for the shader cache.

Should be reproducible by running piglit twice in a row, I haven't 
looked into it any further and can't recall what it was testing.


> 
> Cheers,
> Nicolai
> 
>>
>> Marek
>>
> 
>