On 04/07/2016 10:46 PM, Ilia Mirkin wrote:
On Thu, Apr 7, 2016 at 4:42 PM, Samuel Pitoiset
<[email protected]> wrote:
This might result in an INVALID_OPCODE dmesg error in case a join is
attached to an atomic operation.
Spotted with arb_shader_image_load_store-host-mem-barrier on GK104.
Signed-off-by: Samuel Pitoiset <[email protected]>
Cc: [email protected]
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 66e7b2e..730c680 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -2824,6 +2824,7 @@ FlatteningPass::visit(BasicBlock *bb)
!isSurfaceOp(insn->op) && // not confirmed
insn->op != OP_LINTERP && // probably just nve4
insn->op != OP_PINTERP && // probably just nve4
+ insn->op != OP_ATOM && // probably just nve4
((insn->op != OP_LOAD && insn->op != OP_STORE) ||
(typeSizeof(insn->dType) <= 4 && !insn->src(0).isIndirect(0)))
I'm guessing it has more to do with this clause... maybe add it to the
OP_LOAD/OP_STORE list? e.g. it's probably ok on an ATOM on shared
memory (without an indirect address)?
I have no ideas, but this seems reasonable.
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
