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...
Status: RESOLVED FIXED
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
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
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:


Attachments

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
https://bugs.freedesktop.org/show_bug.cgi?id=94681
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:
https://patchwork.freedesktop.org/series/32253/
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.
    
    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>


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.