i965: Use is_scheduling_barrier instead of schedule_node::is_barrier.
authorKenneth Graunke <kenneth@whitecape.org>
Wed, 18 Oct 2017 06:19:20 +0000 (23:19 -0700)
committerKenneth Graunke <kenneth@whitecape.org>
Thu, 19 Oct 2017 17:19:20 +0000 (10:19 -0700)
commit68f69ebdccca16246bafd86e86ed80fab369009b
treeed4fd481afe0f61e2cff21b7f979d0c03e94f6ac
parent3d112a7cd49656da3dde5f9b476b6ddc2d984528
i965: Use is_scheduling_barrier instead of schedule_node::is_barrier.

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.

dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23
now compiles its shaders in 3.6 seconds instead of 3.3 minutes.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Pallavi G <pallavi.g@intel.com>
src/intel/compiler/brw_schedule_instructions.cpp