I don't think we use SUSTB anyways... it was used in the old handleSTORE logic in the tgsi -> nvir converter, but wtvr. I have a feeling it's the sort of thing that might matter for nv50 (vs nvc0), but for now this is fine. (Esp since the opclasses don't matter on nv50.)
On Sun, Dec 11, 2016 at 5:44 PM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: > Found by inspection, probably a typo because a surface store is > definitely not an atomic operation. > > Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com> > --- > src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp > b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp > index 273ec34..789dba4 100644 > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp > @@ -109,7 +109,7 @@ const OpClass Target::operationClass[] = > OPCLASS_TEXTURE, OPCLASS_TEXTURE, OPCLASS_TEXTURE, OPCLASS_TEXTURE, > OPCLASS_TEXTURE, OPCLASS_TEXTURE, > // SULDB, SULDP, SUSTB, SUSTP; SUREDB, SUREDP, SULEA > - OPCLASS_SURFACE, OPCLASS_SURFACE, OPCLASS_ATOMIC, OPCLASS_SURFACE, > + OPCLASS_SURFACE, OPCLASS_SURFACE, OPCLASS_SURFACE, OPCLASS_SURFACE, > OPCLASS_SURFACE, OPCLASS_SURFACE, OPCLASS_SURFACE, > // SUBFM, SUCLAMP, SUEAU, SUQ, MADSP > OPCLASS_OTHER, OPCLASS_OTHER, OPCLASS_OTHER, OPCLASS_OTHER, OPCLASS_ARITH, > -- > 2.10.2 > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
