<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 4, 2016 at 5:48 PM, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Helps 11 shaders in UnrealEngine4 demos.<br> <br> I seriously hope they would have given us bitfieldReverse() if we<br> exposed GL 4.0 (but we do expose ARB_gpu_shader5, so why not use that<br> anyway?).<br> <br> instructions in affected programs: 4875 -> 4633 (-4.96%)<br> cycles in affected programs: 270516 -> 244516 (-9.61%)<br> <br> I suspect there's a *lot* of room to improve nir_search/opt_algebraic's<br> handling of this. We'd actually like to match, e.g., step2 by matching<br> step1 once and then doing a pointer comparison for the second instance<br> of step1, but unfortunately we generate an enormous tuple for instead.<br> <br> The .text size increases by 6.5% and the .data by 17.5%.<br> <br> text data bss dec hex filename<br> 22957 45224 0 68181 10a55 nir_libnir_la-nir_opt_algebraic.o<br> 24461 53160 0 77621 12f35 nir_libnir_la-nir_opt_algebraic.o<br> <br> I'd be happy to remove this if Unreal4 uses bitfieldReverse() if it is<br> in a GL 4.0 context once we expose GL 4.0.<br> ---<br> Maybe it'd be better do make this a separate pass capable of recognizing this<br> pattern without blowing up the compiled code size. Probably worth checking<br> whether they use bitfieldReverse() under GL 4.0 first...<br> <br> src/compiler/nir/nir_opt_algebraic.py | 12 ++++++++++++<br> 1 file changed, 12 insertions(+)<br> <br> diff --git a/src/compiler/nir/nir_opt_algebraic.py b/src/compiler/nir/nir_opt_algebraic.py<br> index 0a248a2..f92c6b9 100644<br> --- a/src/compiler/nir/nir_opt_algebraic.py<br> +++ b/src/compiler/nir/nir_opt_algebraic.py<br> @@ -311,6 +311,18 @@ optimizations = [<br> 'options->lower_unpack_snorm_4x8'),<br> ]<br> <br> +def bitfield_reverse(u):<br> + step1 = ('ior', ('ishl', u, 16), ('ushr', u, 16))<br> + step2 = ('ior', ('ishl', ('iand', step1, 0x00ff00ff), 8), ('ushr', ('iand', step1, 0xff00ff00), 8))<br> + step3 = ('ior', ('ishl', ('iand', step2, 0x0f0f0f0f), 4), ('ushr', ('iand', step2, 0xf0f0f0f0), 4))<br> + step4 = ('ior', ('ishl', ('iand', step3, 0x33333333), 2), ('ushr', ('iand', step3, 0xcccccccc), 2))<br> + step5 = ('ior', ('ishl', ('iand', step4, 0x55555555), 1), ('ushr', ('iand', step4, 0xaaaaaaaa), 1))<br> +<br> + return step5<br></blockquote><div><br></div><div>Mind calling this "ue4_bitfield_reverse"? You're not detecting a generic bitfield reverse here. With that, patches 1, 3, and 5 are <br><br></div><div>Reviewed-by: Jason Ekstrand <<a href="mailto:jason.ekstrand@intel.com">jason.ekstrand@intel.com</a>><br><br></div><div>I trust Dylan on patch 4. I was just trying to ensure that we got/used a 32-bit value.<br></div><div>--Jason<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +<br> +optimizations += [(bitfield_reverse('x'), ('bitfield_reverse', 'x'))]<br> +<br> +<br> # Add optimizations to handle the case where the result of a ternary is<br> # compared to a constant. This way we can take things like<br> #<br> <span class="HOEnZb"><font color="#888888">--<br> 2.4.10<br> <br> _______________________________________________<br> mesa-dev mailing list<br> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br> </font></span></blockquote></div><br></div></div>