On Tue, Mar 27, 2018 at 7:17 PM, Jason Ekstrand <[email protected]> wrote: > I have no idea why but having dest_components == -1 was causing a memory > leak somewhere. Without this, you can't get through a full shader-db > run without running out of memory.
I guess something somewhere looking at dest_components but ignoring has_dest?? Still a bit curious about why I wasn't able to reproduce this, but it explains why my test code that compared old/new tables didn't flag it. Reviewed-by: Rob Clark <[email protected]> > --- > src/compiler/nir/nir_intrinsics_c.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/compiler/nir/nir_intrinsics_c.py > b/src/compiler/nir/nir_intrinsics_c.py > index 556db78..9d7ec25 100644 > --- a/src/compiler/nir/nir_intrinsics_c.py > +++ b/src/compiler/nir/nir_intrinsics_c.py > @@ -33,7 +33,7 @@ const nir_intrinsic_info > nir_intrinsic_infos[nir_num_intrinsics] = { > ${", ".join(str(comp) for comp in opcode.src_components)} > }, > .has_dest = ${"true" if opcode.has_dest else "false"}, > - .dest_components = ${opcode.dest_components}, > + .dest_components = ${max(opcode.dest_components, 0)}, > .num_variables = ${opcode.num_variables}, > .num_indices = ${opcode.num_indices}, > .index_map = { > -- > 2.5.0.400.gff86faf > > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
