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

[Marek Olšák]

On Fri, Aug 18, 2017 at 12:49 PM, Nicolai Hähnle <nhaehnle at gmail.com> 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've dropped this patch.

What corruption in Unigine?

Marek