<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Implement a NIR -> vec4 pass" href="https://bugs.freedesktop.org/show_bug.cgi?id=89580#c36">Comment # 36</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Implement a NIR -> vec4 pass" href="https://bugs.freedesktop.org/show_bug.cgi?id=89580">bug 89580</a> from <a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> Jason Ekstrand</a> <pre>(In reply to Eduardo Lima Mitev from <a href="show_bug.cgi?id=89580#c35">comment #35</a>) > At this point, we have produced a new NIR pass which we called > 'nir_lower_vec_and_coalesce', that will take the NIR shader right after SSA, > and will try to coalesce registers by propagating vecN destination > components to the instructions that define its sources. The pass will > produce new reduced vecN instructions, containing the channels that were not > propagated. Hence, this pass is compatible with lower_vec_to_movs(), and if > in the future we decide to disable it, we can still use > lower_vec_and_coalesce transparently. > > Right now, the pass is very conservative about the conditions in which it > will propagate register components. The reason is that at this point we are > very interested in feedback about the whole idea, before we add more > complexity to the pass. > > The branch is here: > <a href="https://github.com/Igalia/mesa/commits/elima/nir-vec4-quality">https://github.com/Igalia/mesa/commits/elima/nir-vec4-quality</a> > > There are 2 patches only, one that adds the pass to NIR; and a second that > just activates it on i965 for non-scalar shaders. Only the first one is > interesting. > > With this pass enabled, we get these shader-db VS results against > vec4_visitor: > > total instructions in shared programs: 1853747 -> 1762126 (-4.94%) > instructions in affected programs: 1681255 -> 1589634 (-5.45%) > helped: 7751 > HURT: 9344 > GAINED: 0 > LOST: 0 > > And these against NIR-vec4 as in current master: > > total instructions in shared programs: 1801527 -> 1762126 (-2.19%) > instructions in affected programs: 1156923 -> 1117522 (-3.41%) > helped: 10283 > HURT: 1281 > GAINED: 0 > LOST: 0 > > It is not very impressive but there are a lot of clear opportunities left > out, that would add some complexity that is maybe not worth at this point. > > There are no piglit or dEQP regressions observed. > > What do you think? I'm sorry I haven't had a chance to get back to you. I've had a lot on my plate the last few weeks. I did take a brief look at it today but didn't really give a full review. Could you please send it to the list as at least an RFC so I can more easily make comments inline? Thanks! I also took a stab at helping things out: <a href="http://lists.freedesktop.org/archives/mesa-dev/2015-September/093737.html">http://lists.freedesktop.org/archives/mesa-dev/2015-September/093737.html</a> I'm not 100% sure that I like it, but it seems to be effective: > total instructions in shared programs: 1801527 -> 1761720 (-2.21%) > instructions in affected programs: 978662 -> 938855 (-4.07%) > helped: 7924 > HURT: 497 With the total GLSL IR vs. NIR delta being > total instructions in shared programs: 1853737 -> 1761720 (-4.96%) > instructions in affected programs: 1686064 -> 1594047 (-5.46%) > helped: 7717 > HURT: 9942 Not sure how the two passes interact, I put your branch on top of mine and the final GLSL IR vs. NIR results with both of them are > total instructions in shared programs: 1853737 -> 1697708 (-8.42%) > instructions in affected programs: 1695435 -> 1539406 (-9.20%) > helped: 11648 > HURT: 5540 That seems pretty decent to me. Eventually, I do think we want to make register coalescing in the back-end non-terrible, but these seem to help at the very least. If you get it sent to the list, I'll try and read your pass again and wrap my head around it.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>