[Bug 94477] Too many temporary expressions in shader freeze glLinkProgram

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94477

--- Comment #8 from Matt Turner <mattst88 at gmail.com> ---
(In reply to Tapani Pälli from comment #6)
> Created attachment 126170 [details] [review]
> fix
> 
> This should result in same effect as the first experimentation, I will run
> testing on this and if it works fine then I'll send it to mesa-dev mailing
> list.

That's pretty clever, but unfortunately it cannot work. Cases of dividing by
zero, inf, nan, etc cannot be handled. We don't do this optimization in
opt_algebraic for exactly that reason.

On top of that, the purpose of the test is to check whether you can compile a
huge expression, and the one it uses is hilariously unrepresentative and prone
to abuse by hacks like this one :)

The test has uncovered real flaws in our compiler: GLSL IR's copy propagation
runs in O(n^2), and the channel_expressions pass creates a huge number of
expressions.

Ken and I have spent time recently trying to handle the shader-db regressions
by disabling channel_expressions. It's slow going and other tasks keep taking
priority.

The most direct way forward then, is to improve copy propagate's run time like
I described in comment 3. Maybe you want to take a stab at replacing the linked
lists in the pass with hash tables? I spent some time on it... maybe you'll
have better luck. :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160902/59af185d/attachment.html>