[Mesa-dev] [PATCH v2 1/3] st/glsl_to_tgsi: move nir detection earlier - bisected

Timothy Arceri tarceri at itsqueeze.com
Fri Feb 9 00:45:15 UTC 2018


On 09/02/18 10:49, Marek Olšák wrote:
> Does this fix the cache/no cache conflict?
> 
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 26835d6..97f11ea 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -642,7 +642,8 @@ static void si_disk_cache_create(struct si_screen *sscreen)
>                                  sscreen->debug_flags &
>                                  (DBG(FS_CORRECT_DERIVS_AFTER_KILL) |
>                                   DBG(SI_SCHED) |
> -                                DBG(UNSAFE_MATH));
> +                                DBG(UNSAFE_MATH) |
> +                                DBG(NIR));
> 
>                          sscreen->disk_shader_cache =
>                                  disk_cache_create(si_get_family_name(sscreen),
> 
> 
> Marek

That should do it thanks. Feel free to add my r-b and push.

Reviewed-by: Timothy Arceri <tarceri at itsqueeze.com>


> 
> On Thu, Feb 8, 2018 at 11:51 PM, Dieter Nützel <Dieter at nuetzel-hh.de> wrote:
>> Am 08.02.2018 05:30, schrieb Timothy Arceri:
>>>
>>> On 07/02/18 19:17, Dieter Nützel wrote:
>>>>
>>>> Am 06.02.2018 00:23, schrieb Timothy Arceri:
>>>>>
>>>>> On 05/02/18 15:04, Dieter Nützel wrote:
>>>>>>
>>>>>> Am 02.02.2018 10:24, schrieb Timothy Arceri:
>>>>>>>
>>>>>>> On 02/02/18 19:26, Dieter Nützel wrote:
>>>>>>>>
>>>>>>>> Hello Tim,
>>>>>>>>
>>>>>>>> _this_ version brake UH, UV, mpv, blender 2.79 (some test files not
>>>>>>>> all).
>>>>>>>> Must be something with the cache file(s).
>>>>>>>
>>>>>>>
>>>>>>> The cache currently needs to be deleted when switching between nir and
>>>>>>> tgsi. I'm not sure it I should try to avoid this or not ... I guess it
>>>>>>> will probably save some bug reports so I'll try send a follow up
>>>>>>> patch.
>>>>>>
>>>>>>
>>>>>> Hi Tim,
>>>>>>
>>>>>> it is NOT your fault.
>>>>>> I tracked it down to Marek's commit commit
>>>>>> be973ed21f6e456ebd753f26a99151d9ea6e765c
>>>>>
>>>>>
>>>>> This should fix things for now:
>>>>>
>>>>> https://patchwork.freedesktop.org/patch/202759/
>>>>
>>>>
>>>> Apart that it landed already:
>>>>
>>>> Tested-by: Dieter Nützel <Dieter at nuetzel-hh.de>
>>>>
>>>> But I get some severe hangs with current git code on Polaris 20.
>>>> Steam (Linux only, NOT  Wine), UH and UV hang full system.
>>>> I could remotely log in but nothing in the logs.
>>>> Have to bisect, again...
>>>
>>>
>>> I'm seeing deadlocks in piglit caused by the following patch, could be
>>> what you are seeing.
>>>
>>> commit 6a651b6b77b68db71a027c826abccc843ace88ef (HEAD)
>>> Author: Tapani Pälli <tapani.palli at intel.com>
>>> Date:   Mon Jan 22 11:55:06 2018 +0200
>>>
>>>      disk cache: initialize cache path and index only when used
>>>
>>>      This patch makes disk_cache initialize path and index lazily so
>>>      that we can utilize disk_cache without a path using callback
>>>      functionality introduced by next patch.
>>>
>>>      v2: unmap mmap and destroy queue only if index_mmap exists
>>>
>>>      Signed-off-by: Tapani Pälli <tapani.palli at intel.com>
>>>      Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>
>>>      Reviewed-by: Emil Velikov <emil.velikov at collabora.com>
>>
>>
>> Ah, thanks. Will verify this, too.
>> But now, my only remaining NIR sigfaults are your 'announced' (;-))
>> NIR/without NIR cache fighting. Even _with_ Tapani's commit.
>>
>> [  504.814523] si_shader:2[10216]: segfault at 7f1959a377cc ip
>> 00000000839230e0 sp 0000000097aa8f3e error 4 in
>> libc-2.26.so[7f19865b8000+1b1000]
>>
>> My above reported deadlocks (hangs) was (must be) a LLVM git (7.0.0) bug.
>> With LLVM git from yesterday all are gone.
>>
>> Steam Linux, DiRT Rally and F1 2017 and
>> UH/UV all solved. The later 'faster than ever'.
>>
>> Xeon X3470, 4/8 c/t, 2,93 GHz, 24 GB, Polaris 20 (RX 580), NIR (!):
>> HD (1920x1080)
>> UH: ~91 fps (!!!)
>> UV: ~86 fps
>>
>> GREAT work!
>>
>> Greetings,
>> Dieter


More information about the mesa-dev mailing list