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

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


Hi,

On 02/23/2017 08:16 PM, Nicolas Pomarède wrote:
I just added 2 new options to Hatari's command line :

 --disable-video : don't refresh the screen during emulation. Emulated
screen is still updated into Hatari's internal buffer, but the result is
never displayed on screen through SDL calls.

You've documented the option as:
	--disable-video <bool> Run emulation without displaying video

For consistency with other options, I think it should be either:
	--disable-video
or
	--video <bool>


This can be useful if you just want to listen to Hatari's sound without
the extra cpu needed to display on screen (for example a music disk).

I added frame skip feature to Hatari v1.1 to for this purpose.
It has even SDL GUI settings for forcing a larger than necessary
frame skip value, if one wants less CPU usage:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/tip/doc/manual.html#Performance

If the video option would skip Hatari window completely and
allow running Hatari on headless setups, then it would make
more sense to have video disabling as config file option.

As it's now, I'd rather remove the config file support,
as a potential source of user bug reports (when it gets
enabled & saved there by accident).


It can also be useful with the --benchmark option below to disable as
many OS interaction as possible.
Note that main window is stil created (for keyboard input), but only
refreshed when displaying the F12 menu.

 --benchmark : similar to fast forward mode, Hatari will run at maximum
possible speed allowed by the host CPU.

Why not just alias it to fast-forward option instead of
duplicating code?

Or do you see some potential problem with fast-forward as that
has also a config file option, user shortcut key, takes audio
buffering into account, and its value is shown in statusbar?


By disabling sound output and
video output, one can remove most of SDL/OS calls and get a better
measure of Hatari's inner work.

This can then be used to test different emulation options (cpu accuracy,
video, sound, ...) and see the effect (speedup / slowdown) it implies on
the global emulation.
For example, I plan to use this to test different shifter rendering
methods and ensure there's no major slowdown.

For repeatable measures, best would be to save memstate at some point,
then restore it without audio/video and run it for a large number of VBL
for example :

hatari --memstate test.sav --sound off --disable-video 1 --run-vbls 10000

Maybe you could update also:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/tip/doc/manual.html#Measuring_the_performance

Section in the manual?


	- Eero



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