On 03/27/2018 04:35 PM, Ian Romanick wrote: > On 03/27/2018 04:29 PM, Jason Ekstrand wrote: >> This was causing us to walk dest_components times over a thing with no >> destination. This happened to work because all of the image intrinsics >> without a destination also happened to have dest_components == 0. We >> shouldn't be reading dest_components if has_dest == false. > > I'm assuming we want this fix in addition to the other change to > nir_intrinsics_c.py? I haven't tested this yet, but, based on the > discussion on IRC, I suspect this will fix my shader-db problem on its > own. Give me a couple minutes...
The previous memory usage pattern of never exceeding 3.1% is restored with just this patch. I agree with Rob that we should do both. Reviewed-by: Ian Romanick <[email protected]> >> --- >> src/intel/compiler/brw_fs_nir.cpp | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/src/intel/compiler/brw_fs_nir.cpp >> b/src/intel/compiler/brw_fs_nir.cpp >> index f5d5399..8d1c387 100644 >> --- a/src/intel/compiler/brw_fs_nir.cpp >> +++ b/src/intel/compiler/brw_fs_nir.cpp >> @@ -3848,9 +3848,11 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, >> nir_intrinsic_instr *instr >> get_image_atomic_op(instr->intrinsic, >> type)); >> >> /* Assign the result. */ >> - for (unsigned c = 0; c < info->dest_components; ++c) >> - bld.MOV(offset(retype(dest, base_type), bld, c), >> - offset(tmp, bld, c)); >> + if (nir_intrinsic_infos[instr->intrinsic].has_dest) { >> + for (unsigned c = 0; c < info->dest_components; ++c) >> + bld.MOV(offset(retype(dest, base_type), bld, c), >> + offset(tmp, bld, c)); >> + } >> break; >> } >> > > _______________________________________________ > 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
