<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>