Much shorter replay time

[José Fonseca]

There's lots of tools to measure FPS in black box.

Which OS do you care for?

For Windows there's FIPS http://www.fraps.com/ .

For Linux there's e.g http://git.cworth.org/git/fips

The point is, you want a tool that intercepts the application, and measures
the frame rate *live* with minimal interference.  Not offline from traces.

Jose


On Thu, Dec 3, 2015 at 12:23 PM, Sunil Nakum <sunil.nakum at gmail.com> wrote:

> Hi Jose,
>
> Thank you for the clarification.
>
> I understand, here the primary audience comprises of graphics developers,
> what I'm trying to figure out is whether I can use it for
> measuring/comparing graphics performance (in black-box manner). Please
> correct me, if my approach for ApiTrace is not in right direction. I don't
> have access to code and that's why I resorted for comparing FPS numbers by
> replaying trace files, but as per your reply it is not designed to do that.
> I've also tried diff-images option for two runs, that worked well but does
> not indicate performance.
>
> When you say replays are not good for FPS and it can be measured on actual
> app, did you mean it by ApiTrace or application itself or by other means?
> My application doesn't have this facility inbuilt thus looking for external
> means. If ApiTrace can measure it on actual app, then surely I've missed
> reading something from the documentation.
>
> The app isn't slow, the object is to measure how slow/fast it is in one
> environment as compared to others.
>
> Thanks,
> Sunil
>
>
> On Wed, Dec 2, 2015 at 8:10 PM, José Fonseca <jose.r.fonseca at gmail.com>
> wrote:
>
>> Yes,  glretrace replays the trace as fast as it can, and not to the same
>> rhythm as the original app.
>>
>> Replays are not suitable for measuring FPS.  You can easily do that on
>> the actual app.  The purpose is to provide a magnifying glass into the
>> graphics API.  This is  by design.
>>
>> If your app is slow due to something other than the graphics API then
>> you'll need to investigate that using different tools (e.g, general
>> profilers.)
>>
>> Jose
>>
>> On Wed, Dec 2, 2015 at 12:54 PM, Sunil Nakum <sunil.nakum at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm from testing domain and it is my first attempt to test performance
>>> of 3d product. As it's a propitiatory product, I wont be able to provide
>>> much information on it though any questions are very welcomed.
>>>
>>> The tracing and replay though works well, but the replaying time reduces
>>> to almost 3rd of the recording time. Suppose, I record the graphics
>>> manipulation for 30 seconds the resulting trace file gets replayed in about
>>> 10 seconds.
>>>
>>> To understand how ApiTrace behaves I performed following test, while
>>> tracing I tried halting graphics manipulation for few seconds. The
>>> resulting trace file when replayed does not show this halting effect for
>>> appropriate time. So I'm thinking that ApiTrace sort of skips the time to
>>> plot such frames (during which frames are not changing) and thus completes
>>> replaying in much shorter time. Is that correct? Is is possible to have
>>> exact same replay time as recorded while tracing?
>>>
>>> The problem with this fast replaying is that it gives much higher FPS
>>> number (because of much lesser time) as compared to the actual clock time.
>>>
>>> Kindly ignore lack of terminologies in explaining it, as I'm not well
>>> conversed with this technology.
>>>
>>> Thanks,
>>> Sunil
>>>
>>>
>>> _______________________________________________
>>> apitrace mailing list
>>> apitrace at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/apitrace
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20151203/f440cbf1/attachment.html>