Hi Sergey, On Wed, Jun 10, 2015 at 12:47 PM, Sergey Sharybin <[email protected]> wrote:
> 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. > Yes this could be an issue. But I still think it is also useful to measure the whole application performance. > > 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. > This argument could be made about all possible ways to do this. The numbers produced by some random user and posted on a forum somewhere have little meaning always no matter how you look at it. > 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. > What exactly you think is difficult? Unlocking the max fps or making interface frames map to animation frames on a 1 to 1 basis ? It could maybe help if you could provide additional technical oriented feedback to that? > On Wed, Jun 10, 2015 at 12:09 PM, Martijn Berger <[email protected] > > > 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 > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
