Bug 103322 - i965: dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23 takes 3m22s to compile
Summary: i965: dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23 takes 3m...
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2017-10-18 06:00 UTC by Chad Versace
Modified: 2017-12-14 23:48 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Chad Versace 2017-10-18 06:00:58 UTC
This bug prevents the Android CTS from passing. I see two ways to make the CTS happy: 1) convince the Android CTS team to increase the timeout for dEQP, or 2) fix Mesa. I haven't yet discussed option #1 with the Android team.

Tested on dual-core Skylake machine on the following commits and build configs. I built everything in release mode.
mesa master

  ./configure --disable-debug -DNDEBUG CFLAGS='-g -O2' CXXFLAGS=same ...

  commit fbf39fd7c33d56271d79bdbe039605588c8d84db
  CommitDate: Tue Oct 17 15:34:35 2017 -0700                                                                                          
  Subject: meson: turn on pl111 not vc4 when pl111 driver specificed         
vk-gl-cts master

  cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DEQP_TARGET=Wayland ...

  commit f172e07bfefa71ca877674d0553011993ef3c887
  CommitDate: Fri Sep 29 03:39:25 2017 -0400
  Subject: Test BLOCK_INDEX of uniform inside block array

Similarly, dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.5 takes 11 seconds to compile.
Comment 1 Chad Versace 2017-10-18 06:02:01 UTC
See previous bug for the same test:

dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23 takes 25 minutes to compile
Comment 2 Kenneth Graunke 2017-10-18 06:22:41 UTC
Oh, I think there's actually a simple fix here.

The issue is that add_barrier_dep sets is_barrier = true, and walks backward to the previous barrier, and forward to...the end of the program...because if you're walking forward, you haven't set is_barrier on any future instructions yet.

I think we just need to change to is_scheduling_barrier() instead, which means moving some things to backend_instruction instead of fs_inst.  (I have a vague memory that Curro wanted us to do that in the first place...)

I've got a patch to do that, and it reduces the runtime to 3.6 seconds.  The test still passes, but I'll have to do real regression testing and clean it up tomorrow.
Comment 3 Chad Versace 2017-10-18 18:37:57 UTC
Thanks Ken! I will be silent on this bug for several days, as I'm taking time off, returning Wed 25th.
Comment 4 Kenneth Graunke 2017-10-18 23:59:50 UTC
Patches on list:
Comment 5 Pallavi G 2017-10-19 08:14:12 UTC
We face the same issue on Android O. Please let us know when these fixes will merge in upstream.
Comment 6 Pallavi G 2017-10-19 09:40:55 UTC
Test passes with the above patches
Comment 7 Kenneth Graunke 2017-10-19 17:26:14 UTC
Fixed by:

commit 68f69ebdccca16246bafd86e86ed80fab369009b
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Tue Oct 17 23:19:20 2017 -0700

    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.
    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>

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.