On Wed, Oct 18, 2017 at 4:59 PM, Kenneth Graunke <kenn...@whitecape.org> wrote: > Commit a73116ecc60414ade89802150b tried to make add_barrier_deps() > walk to the next barrier, and stop. To accomplish that, it added an > is_barrier flag. Unfortunately, this only works half of the time. > > The issue is that add_barrier_deps() walks both backward (to the > previous barrier), and forward (to the next barrier). It also sets > is_barrier. Assuming that we're processing instructions in forward > order, this means that is_barrier will be set for previous instructions, > but not future ones. So we'll never see it, and walk further than we > need to.
Dang. I should have realized that in my original patch. With the typo Dylan pointed out fixed, both are: Reviewed-by: Matt Turner <matts...@gmail.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
