<div dir="ltr">Hi Chad,<div><br></div><div>Does Matt's explanation help?</div><div><br></div><div>I wanted to tell the performance story and show the progression of performance enhancements with these two patches.</div>
<div><br></div><div>Thanks,</div><div>Courtney</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 11, 2013 at 3:01 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"><div class="im">On Mon, Nov 11, 2013 at 1:19 PM, Chad Versace<br>
<<a href="mailto:chad.versace@linux.intel.com">chad.versace@linux.intel.com</a>> wrote:<br>
> On 11/07/2013 01:59 PM, Courtney Goeltzenleuchter wrote:<br>
>><br>
>> MESA_FORMAT_XRGB8888 is equivalent to MESA_FORMAT_ARGB8888 in terms<br>
>> of storage on the device, so okay to use this optimized copy routine.<br>
>><br>
>> This series builds on work from Frank Henigman to optimize the<br>
>> process of uploading a texture to the GPU. This series adds support for<br>
>> MESA_XRGB_8888 and full miptrees where were found to be common activities<br>
>> in the Smokin' Guns game. The issue was found while profiling the app<br>
>> but that part is not benchmarked. Smokin-Guns uses mipmap textures with<br>
>> an internal format of GL_RGB (MESA_XRGB_8888 in the driver).<br>
>><br>
>> These changes need a performance tool to run against to show how they<br>
>> improve execution performance for specific texture formats. Using this<br>
>> benchmark I've measured the following improvement on my Ivybridge<br>
>> Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz.<br>
>><br>
>> Using 1024x1024, RGBA 8888 source, mipmap<br>
>>                                  <<THIS PATCH>><br>
><br>
><br>
> I don't understand. What do you mean by ``<<THIS PATCH>>``? That all these<br>
> numbers were obtained with this patch? But that doesn't make sense, because<br>
> these are before-and-after numbers. And it can't be just this patch, because<br>
> these numbers are identical to the numbers quoted in patch 2.<br>
<br>
</div>The first column is "before", the second is after patch 1, and the<br>
third is after patch 2. Instead of doing before->after patch 1 in<br>
patch 1's commit, and after patch 1->after patch 2 in patch 2's<br>
commit, he just pasted the same data in and added <<THIS PATCH>> above<br>
the column that corresponds to the patch.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Courtney Goeltzenleuchter<br><div>LunarG</div><div><img src="http://media.lunarg.com/wp-content/themes/LunarG/images/logo.png" width="96" height="65"><br>
</div></div>
</div>