On 11.08.2017 20:37, Marek Olšák wrote:
On Fri, Aug 11, 2017 at 6:00 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
On 10.08.2017 21:57, Marek Olšák wrote:
From: Marek Olšák <marek.ol...@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.
Cheers,
Nicolai
Marek
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
