<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23 takes 25 minutes to compile" href="https://bugs.freedesktop.org/show_bug.cgi?id=94681#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23 takes 25 minutes to compile" href="https://bugs.freedesktop.org/show_bug.cgi?id=94681">bug 94681</a> from <a class="email" href="mailto:kenneth@whitecape.org" title="Kenneth Graunke <kenneth@whitecape.org>"> Kenneth Graunke</a> <pre>Oh, that is pretty absurd. Scheduling things seems pretty reasonable. Maybe an easier trick would be to make add_barrier_deps() stop when it hits something that's already a barrier. If you have: <bunch of instructions we'll call A> barrier_1 <bunch of instructions we'll call B> barrier_2 We need to make barrier_2 depend on everything in group B, and also barrier_1. But since barrier_1 already depends on group A, we don't need to continue. Something like: while (!prev->is_head_sentinel()) { add_dep(prev, n, 0); prev = (schedule_node *)prev->prev; if (is_scheduling_barrier(n->inst)) break; } Using is_scheduling_barrier approximates the right condition...we could also perhaps just add a schedule_node::is_barrier field that we set when calling add_barrier_deps(), and check here. Seems easy enough and would likely solve this.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>