Hi Courtney,
I've been doing similar work but using Xenotic as the benchmark. Here is
how I've been estimating upload times: First I made a rough determination
of a texture count, like 300, as a metric. In intelTexImage I use
clock_gettime to determine the elapsed time between the loading of texture
0 and texture 300. Then I use _mesa_debug to output the results to a log
file by setting these env variables:
export MESA_DEBUG=1;
export MESA_LOG_FILE=`pwd`/mesa.log
Cheers,
Mark
On Mon, Oct 14, 2013 at 9:00 AM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:
> Does anyone know of a test that measures frame 0 time? Or texture upload
> speed?
>
> For Smokin' Guns, I tried measuring the overall time, but an improved
> frame 0 time has difficulty standing out of a 2607 frame test.
>
> I may have to create something. Suggestions for an appropriate framework?
>
> Thanks,
> Courtney
>
>
> On Mon, Oct 14, 2013 at 8:32 AM, Chad Versace <
> chad.vers...@linux.intel.com> wrote:
>
>> On 10/13/2013 08:33 PM, Ian Romanick wrote:
>>
>>> On 10/13/2013 01:50 PM, Frank Henigman wrote:
>>>
>>>> On Fri, Oct 11, 2013 at 10:00 PM, Chad Versace
>>>> <chad.vers...@linux.intel.com> wrote:
>>>>
>>>>> On 10/11/2013 10:17 AM, Courtney Goeltzenleuchter wrote:
>>>>>
>>>>>>
>>>>>> Support all levels of a supported texture format.
>>>>>> ---
>>>>>> src/mesa/drivers/dri/i965/**intel_tex_subimage.c | 13
>>>>>> +++++++++++--
>>>>>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/src/mesa/drivers/dri/i965/**intel_tex_subimage.c
>>>>>> b/src/mesa/drivers/dri/i965/**intel_tex_subimage.c
>>>>>> index 4aec05d..5e46760 100644
>>>>>> --- a/src/mesa/drivers/dri/i965/**intel_tex_subimage.c
>>>>>> +++ b/src/mesa/drivers/dri/i965/**intel_tex_subimage.c
>>>>>> @@ -541,14 +541,13 @@ intel_texsubimage_tiled_**memcpy(struct
>>>>>> gl_context *
>>>>>> ctx,
>>>>>> uint32_t cpp;
>>>>>> mem_copy_fn mem_copy = NULL;
>>>>>>
>>>>>> - /* This fastpath is restricted to specific texture types: level 0
>>>>>> of
>>>>>> + /* This fastpath is restricted to specific texture types:
>>>>>> * a 2D BGRA, RGBA, L8 or A8 texture. It could be generalized to
>>>>>> support
>>>>>> * more types.
>>>>>> */
>>>>>> if (!brw->has_llc ||
>>>>>> type != GL_UNSIGNED_BYTE ||
>>>>>> texImage->TexObject->Target != GL_TEXTURE_2D ||
>>>>>> - texImage->Level != 0 ||
>>>>>> pixels == NULL ||
>>>>>> _mesa_is_bufferobj(packing->**BufferObj) ||
>>>>>> packing->Alignment > 4 ||
>>>>>> @@ -616,6 +615,16 @@ intel_texsubimage_tiled_**memcpy(struct
>>>>>> gl_context *
>>>>>> ctx,
>>>>>> DBG("%s: level=%d offset=(%d,%d) (w,h)=(%d,%d)\n",
>>>>>> __FUNCTION__, texImage->Level, xoffset, yoffset, width,
>>>>>> height);
>>>>>>
>>>>>> + /* Adjust x and y offset based on miplevel
>>>>>> + */
>>>>>> + if (texImage->Level) {
>>>>>> + GLuint xlevel, ylevel;
>>>>>> + intel_miptree_get_image_**offset(image->mt, texImage->Level,
>>>>>> 0,
>>>>>> + &xlevel, &ylevel);
>>>>>> + xoffset += xlevel;
>>>>>> + yoffset += ylevel;
>>>>>> + }
>>>>>> +
>>>>>> linear_to_tiled(
>>>>>> xoffset * cpp, (xoffset + width) * cpp,
>>>>>> yoffset, yoffset + height,
>>>>>>
>>>>>>
>>>>> Usually when we commit performance patches like this, we state in the
>>>>> commit message what the observed relative performance gain.
>>>>>
>>>>> What gain did you see? Hardware? Benchmark? Kernel version? How many
>>>>> runs?
>>>>>
>>>>
>>>> We could quote from my patch, as this is just opening more paths into
>>>> that code.
>>>> Or do you think this calls for different testing?
>>>>
>>>
>>> I think what Chad is asking is whether there's some information like
>>> "Improves load time of application XYZ 12.3+4.5%" or similar.
>>>
>>> In the past, we've had problems with patches that just make vague claims
>>> of "improves performance" when we later find critical bugs in those
>>> patches... can we just revert the code, or is it going to run the
>>> performance of... something?
>>>
>>> For reference, see commit 329cd6a9b and this thread from mesa-dev:
>>>
>>> http://lists.freedesktop.org/**archives/mesa-dev/2013-June/**040811.html<http://lists.freedesktop.org/archives/mesa-dev/2013-June/040811.html>
>>>
>>
>> Ian read my mind correctly. The commit message should say "Improves XYZ of
>> application ABC by 10.3+-1.2%", as well as state the hardware at a
>> minimum,
>> and kernel version too if you're feeling gracious.
>>
>> In the future, if someone discover that this patch introduces a bug, the
>> commit
>> message's performance claim will prevent that someone from simply
>> reverting the
>> code.
>>
>>
>
>
> --
> Courtney Goeltzenleuchter
> LunarG
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
