Am 2015-02-18 09:13, schrieb Michel Dänzer:
On 18.02.2015 16:52, Grigori Goronzy wrote:
Hi,
AFAIR not enabling this makes LLVM generate really slow code in some
common cases. Maybe this is just a bug in LLVM/R600 triggered by
unsafe
FP math optimization or some optimization is too eager. Other drivers
do
fine with these types of optimization.
It can be enabled again after fixing the problem exposed by The Talos
Principle.
Right. I just want to avoid the situation that this workaround gets
committed and then forgotten about. I guess it's up to me then. :)
On 17.02.2015 09:15, Michel Dänzer wrote:
From: Michel Dänzer <michel.daen...@amd.com>
This reverts commit 0e9cdedd2e3943bdb7f3543a3508b883b167e427.
It caused the grass to disappear in The Talos Principle.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89069
Signed-off-by: Michel Dänzer <mic...@daenzer.net>
---
src/gallium/drivers/radeon/radeon_llvm_emit.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
b/src/gallium/drivers/radeon/radeon_llvm_emit.c
index 0f9dbab..624077c 100644
--- a/src/gallium/drivers/radeon/radeon_llvm_emit.c
+++ b/src/gallium/drivers/radeon/radeon_llvm_emit.c
@@ -80,10 +80,6 @@ void radeon_llvm_shader_type(LLVMValueRef F,
unsigned type)
sprintf(Str, "%1d", llvm_type);
LLVMAddTargetDependentFunctionAttr(F, "ShaderType", Str);
-
- if (type != TGSI_PROCESSOR_COMPUTE) {
- LLVMAddTargetDependentFunctionAttr(F, "unsafe-fp-math", "true");
- }
}
static void init_r600_target()
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
