<p dir="ltr">Forgot to reply-all.</p>
<div class="gmail_quote">On Sep 12, 2014 9:05 AM, "Jason Ekstrand" <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">The teximage-colors test that I pushed to piglit a week or two ago takes a --benchmark flag that bumps the texture size and does the upload 1000 times and gives you the average time to upload.<br>
--Jason</p>
<div class="gmail_quote">On Sep 12, 2014 9:01 AM, "Brian Paul" <<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/12/2014 08:49 AM, Jason Ekstrand wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Sep 12, 2014 7:09 AM, "Brian Paul" <<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a><br>
<mailto:<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a>>> wrote:<br>
 ><br>
 > On 09/11/2014 04:58 PM, Jason Ekstrand wrote:<br>
 >><br>
 >><br>
 >><br>
 >> On Thu, Sep 11, 2014 at 3:53 PM, Dieter Nützel <<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a><br>
<mailto:<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a>><br>
 >> <mailto:<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a> <mailto:<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a>>><u></u>> wrote:<br>
 >><br>
 >>     Am 12.09.2014 00:31, schrieb Jason Ekstrand:<br>
 >><br>
 >>         On Thu, Sep 11, 2014 at 2:55 PM, Dieter Nützel<br>
 >>         <<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a> <mailto:<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a>><br>
<mailto:<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a> <mailto:<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a>>><u></u>><br>
 >><br>
 >>         wrote:<br>
 >><br>
 >>             Am 15.08.2014 04:50, schrieb Jason Ekstrand:<br>
 >><br>
 >>                 On Aug 14, 2014 7:13 PM, "Dieter Nützel"<br>
 >>                 <<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a> <mailto:<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a>><br>
<mailto:<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a> <mailto:<a href="mailto:Dieter@nuetzel-hh.de" target="_blank">Dieter@nuetzel-hh.de</a>>><u></u>><br>
 >><br>
 >>                 wrote:<br>
 >><br>
 >><br>
 >>                     Am 15.08.2014 02:36, schrieb Dave Airlie:<br>
 >><br>
 >>                                 On 08/02/2014 02:11 PM, Jason Ekstrand<br>
 >>                                 wrote:<br>
 >><br>
 >><br>
 >><br>
 >>                                     Most format conversion operations<br>
 >>                                     required by GL can be<br>
 >><br>
 >>                 performed by<br>
 >><br>
 >>                                     converting one channel at a time,<br>
 >>                                     shuffling the channels<br>
 >><br>
 >>                 around, and<br>
 >><br>
 >>                                     optionally filling missing channels<br>
 >>                                     with zeros and ones.<br>
 >><br>
 >>                 This<br>
 >>                 adds a<br>
 >><br>
 >>                                     function to do just that in a<br>
 >>                                     general, yet efficient, way.<br>
 >><br>
 >>                                     v2:<br>
 >>                                     * Add better comments including full<br>
 >>                                     docs for functions<br>
 >>                                     * Don't use __typeof__<br>
 >>                                     * Use inline helpers instead of<br>
 >>                                     writing out conversions<br>
 >><br>
 >>                 by<br>
 >>                 hand,<br>
 >><br>
 >>                                     * Force full loop unrolling for<br>
 >>                                     better performance<br>
 >><br>
 >><br>
 >><br>
 >>                         This file seems to anger gcc a lot.<br>
 >><br>
 >>                         It seems to take upwards of a minute or two to<br>
 >>                         compile here.<br>
 >><br>
 >>                         gcc 4.8.3 on 32-bit x86.<br>
 >><br>
 >>                         Dave.<br>
 >><br>
 >><br>
 >><br>
 >>                     For me (on our poor little Duron 1800/2 GB) it<br>
ran ~5<br>
 >><br>
 >>                 minutes...<br>
 >><br>
 >><br>
 >>                     gcc 4.8.1 on 32-bit x86.<br>
 >><br>
 >><br>
 >>                 If we'd like, the way the macros are set up, it would be<br>
 >>                 easy to<br>
 >>                 change it so that we do less unrolling in the cases<br>
 >>                 where we are<br>
 >>                 actually doing substantial format conversion and<br>
 >>                 wouldn't notice<br>
 >>                 the<br>
 >>                 extra logic quite as much. I'll play with it a bit<br>
 >>                 tomorrow or<br>
 >>                 next<br>
 >>                 week and see how how much of a hit we would actually<br>
 >>                 take if we<br>
 >>                 unrolled a little less in places.<br>
 >>                 --Jason Ekstrand<br>
 >><br>
 >><br>
 >>             Ping.<br>
 >><br>
 >>             In a second it took 11+ minutes , here...<br>
 >><br>
 >><br>
 >>         11 minutes! What system are you running?  and are you using<br>
-03 or<br>
 >>         something?  Yes, we can do something to cut it down, but it will<br>
 >>         probably require a configure flag; the question is what flag.<br>
 >><br>
 >>         --Jason<br>
 >><br>
 >><br>
 >>     See above, the old children's system... ;-)<br>
 >>     -O2 -m32 -march=athlon-mp -mtune=athlon-mp -m3dnow -msse -mmmx<br>
 >>     -mfpmath=sse,387 -pipe<br>
 >><br>
 >>     Bad? - Worked for ages on AthlonMP....8-)<br>
 >>     Maybe it is bad on Duron (the MP thing, much smaller cache and<br>
 >>     better GCC), now.<br>
 >><br>
 >>     Dieter<br>
 >><br>
 >><br>
 >> Yeah, my recommendation would be hacking the macros to not unroll and<br>
 >> keep the patch locally.  If you've got a better idea as to how to<br>
 >> organize the code so the compiler likes it, I'm open as long as we don't<br>
 >> loose performance.<br>
 ><br>
 ><br>
 > It looks like a release build with MSVC is taking quite a while to<br>
compile this file too (actually at link time when the optimizer kicks in).<br>
 ><br>
 > But even on my fast Linux system with gcc, the difference in compile<br>
time between -O0 and -O3 is pretty big (2 seconds vs. 1 minute, 3 seconds).<br>
<br>
The unfortunate thing is that I doubt -O3 gains you anything on this<br>
function given how thoroughly things are unrolled. :-(<br>
</blockquote>
<br>
Do you have a benchmark program to test the speed of this code?  Have you compared -O0 .. -O3?  I'd be very interested in that.<br>
<br>
-Brian<br>
<br>
</blockquote></div>
</blockquote></div>