On Thu, Apr 7, 2016 at 4:48 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: > > > On 04/07/2016 10:46 PM, Ilia Mirkin wrote: >> >> On Thu, Apr 7, 2016 at 4:42 PM, Samuel Pitoiset >> <samuel.pitoi...@gmail.com> 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 <samuel.pitoi...@gmail.com> >>> Cc: mesa-sta...@lists.freedesktop.org >>> --- >>> 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.
Well, this is fine with me either way. These ops don't happen so often that we'd be losing out bigtime by not being able to stick a join on them. Whichever approach you choose is Acked-by: Ilia Mirkin <imir...@alum.mit.edu> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
