[Mesa-dev] [PATCH 1/2 v3] i965: add XRGB to tiled_memcpy

Matt Turner mattst88 at gmail.com
Mon Nov 11 14:01:25 PST 2013


On Mon, Nov 11, 2013 at 1:19 PM, Chad Versace
<chad.versace at linux.intel.com> wrote:
> On 11/07/2013 01:59 PM, Courtney Goeltzenleuchter wrote:
>>
>> MESA_FORMAT_XRGB8888 is equivalent to MESA_FORMAT_ARGB8888 in terms
>> of storage on the device, so okay to use this optimized copy routine.
>>
>> This series builds on work from Frank Henigman to optimize the
>> process of uploading a texture to the GPU. This series adds support for
>> MESA_XRGB_8888 and full miptrees where were found to be common activities
>> in the Smokin' Guns game. The issue was found while profiling the app
>> but that part is not benchmarked. Smokin-Guns uses mipmap textures with
>> an internal format of GL_RGB (MESA_XRGB_8888 in the driver).
>>
>> These changes need a performance tool to run against to show how they
>> improve execution performance for specific texture formats. Using this
>> benchmark I've measured the following improvement on my Ivybridge
>> Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz.
>>
>> Using 1024x1024, RGBA 8888 source, mipmap
>>                                  <<THIS PATCH>>
>
>
> I don't understand. What do you mean by ``<<THIS PATCH>>``? That all these
> numbers were obtained with this patch? But that doesn't make sense, because
> these are before-and-after numbers. And it can't be just this patch, because
> these numbers are identical to the numbers quoted in patch 2.

The first column is "before", the second is after patch 1, and the
third is after patch 2. Instead of doing before->after patch 1 in
patch 1's commit, and after patch 1->after patch 2 in patch 2's
commit, he just pasted the same data in and added <<THIS PATCH>> above
the column that corresponds to the patch.


More information about the mesa-dev mailing list