[Mesa-stable] [Mesa-dev] [PATCH] nv50/ir: do not try to attach JOIN ops to ATOM

[Ilia Mirkin]

On Thu, Apr 7, 2016 at 4:48 PM, Samuel Pitoiset
<samuel.pitoiset at 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.pitoiset at 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.pitoiset at gmail.com>
>>> Cc: mesa-stable at 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 <imirkin at alum.mit.edu>