Re: [hatari-devel] New option --disable-video and --benchmark

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Le 27/02/2017 à 00:23, Eero Tamminen a écrit :
Hi,

On 02/26/2017 07:21 PM, Nicolas Pomarède wrote:
Le 26/02/2017 à 13:37, Eero Tamminen a écrit :
see the values I posted earlier, disabling the SDL calls *does* impact
performance I go from 200 VBL/s to 275 VBL/s, that's clear performance
advantage.

I gave numbers that show that there's no real performance
or CPU usage benefit from disabling video output, compared
to using Hatari options which don't have the disadvantage
of losing the output.

Did you try them?

Hi

What for ? I know what thoses options do, I just keep telling that's not what I need. I don't want to modify any options while doing benchmark, I don't want to remove border rendering, I don't want to use x1 zooming or frame skipping.



Also, I don't want to disable accuracy by removing borders
emulation or disabling spec512 mode, that's not my goal.

I don't understand how that's relevant.  When you disable video,
you're not seeing the border content or spec512 palette changes
anyway, so you don't lose anything extra compared to video disabling.

Of course I don't see the colors on screen, but all the inner work is done nonetheless, except calling SDL to put the result on screen, which is just what I want.


If you want to benchmark screen conversion routines, you
obviously want to maximize that part's overhead to see
the effect of optimizations better.

But how that's relevant for --disable-video discussion?

"--disable-video" option is last thing you would want to do
for such measurements, as that will minimize[1] the conversions
which you wanted to measure???

[1] = same as frameskip, border & spec512 mode disabling does.

did you really look at the code I added with "--disable-video" ? It does an immediate return in Screen_Blit in screen.c, which is called from Screen_DrawFrame, just after pDrawFunction is called.

So of course screen conversion is measured in that case and SDL overhead is also removed, which is exactly what I want to measure screen conversion routines for example by minimizing SDL overhead.

This discussion leads to nowhere I'm afraid.


Please tell why one would want to disable video for
that use-case?

I showed that there's no real performance nor CPU usage advantage
from that, so one can as well run it will frameskip so that one
sees what one's interacting with.

Frameskipping is not the same as not calling SDL Copy/Render, frameskipping does an immediate return much earlier in Video_DrawScreen and never calls Screen_Draw, so screen conversion routines are not called on *every* frame.

--disable-video *calls* the screen conversion routines on *every* frame.


I have issue only with video disabling usefulness claims,
and what you're (not) comparing it with.

Read the code again and compare what frameskipping does and what ConfigureParams.Screen.DisableVideo does :)

Nicolas




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/