[Bf-committers] Blender performance measuring instrumentation improvement proposal

Sergey Sharybin sergey.vfx at gmail.com
Wed Jun 10 12:47:23 CEST 2015


It doesn't seem to be so much an improvement to be honest, such a test will
be more or less about nothing. It shouldn't be full testing, it should be
per-area time measuring. For example, we could speedup viewport opengl
display but accidentally slowdown dependency graph and having just an
aggregated number will tell you simply nothing.

it is also important to setup a strictly controlled environment for such
tests if we want the numbers to mean anything. Otherwise we'll end up with
folks reporting speed regressions in blender while it might be just new
antivirus application being installed on their desktop.

Surely if we'll have such an environment setup then it'll be handy, but the
proposal for it needs much more work i'm afraid.

On Wed, Jun 10, 2015 at 12:09 PM, Martijn Berger <martijn.berger at gmail.com>
wrote:

> Hello everyone,
>
>
> Blender is evolving at a rather nice pace currently but I feel we could use
> better measurements to guide its the performance aspect of this a bit
> better.
>
> Some 3d games (like quake) have a feature called “timedemo” this basically
> runs the game as fast as the hardware will let it run. I tried doing
> something similar in blender and found a number of little things that maybe
> could be tweaked to make this possible.
>
> Overview of how this would work:
>
> The user runs the command:
>
> “blender --factory-startup --python-expr="import bpy;
> bpy.ops.debug_timer(type='FULLTEST', report=True); sys.exit(0);"
> demo_scene.blend”
>
> The following happens:
>
>
>    1.
>
>    Blender starts and loads demo_scene.blend
>    2.
>
>    Blender executes the python expression passed to it
>    3.
>
>    debug_timer() is invoked:
>    1.
>
>       Move animation counter to the start of the range
>       2.
>
>       unlock max fps ( if vsync is disabled this allows very high
>       framerates)
>       3.
>
>       Gets an accurate time measurement
>       4.
>
>       Run the animation and render 1 OpenGL frame per frame of animation
>       5.
>
>       At the end of the range, capture time again
>       6.
>
>       Print this time ( to stdout ?)
>       4.
>
>    sys.exit(0), exit blender
>
>
> What we need for this to work:
>
>
>    1.
>
>    implement bpy.ops.debug_timer()
>    2.
>
>    Allow higher then 120 fps for animation playback
>    3.
>
>    Not sure, if we allow gl frames to be locked to blender animation frames
>    4. (optional) implement ‘python-expr’ command line argument
>
>
>
> I might have missed stuff but the purpose of this message is to inform and
> discus the possibility as well as map out the bits and pieces that need to
> be done in order to get this functionality.
>
> I think something like this could also be instrumental in achieving high
> performance in the viewport project.
>
>
> Martijn
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin


More information about the Bf-committers mailing list