Build Your Own Arcade Controls Forum
Software Support => GroovyMAME => Topic started by: Doozer on January 29, 2015, 07:58:24 am
-
Hi,
I am running several Linux groovyarcade setups. Main systems are a single core 3GHz P4 (32bit setup) and a i5 3.2 GHz 2 cores with HT (64bit setup)
core systems.
My P4 are too old and do not have 64 bit capability. I have to stick to a 32bit distro. But I use the latest groovymame (at the time 0157_015e) patch with SDL2 enabled on both.
My ume.ini core parameters are identical between the two machines. The only difference is the monitor setup.
I would like to call the community to have a sanity check on the current configuration parameters. My main concern is observable glitches in the emulation speed on my i5 based system. It does not sustain the 100% emulation speed during game (groovyume cpu load is less than 50%). Emulation speed reporting shows slow down to 94% during less than a second several time per minute.
Any information/help/protocol would be valuable to track down the issue.
ume.ini
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0
#
# CORE SEARCH PATH OPTIONS
#
rompath /home/roms/MAME/roms;/home/roms/BIOS_roms;/home/roms/MAME/disks
hashpath $HOME/hash
samplepath /home/roms/MAME/samples
artpath /home/roms/MAME/artwork
ctrlrpath /home/roms/MAME/ctrlr
inipath $HOME/.ume;$HOME;.;$HOME/ini
fontpath /home/roms/MAME/fonts
cheatpath /home/roms/MAME/cheat
crosshairpath /home/roms/MAME/crosshair
#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory $HOME/cfg
nvram_directory $HOME/nvram
memcard_directory $HOME/memcard
input_directory $HOME/inp
state_directory $HOME/sta
snapshot_directory $HOME/snap
diff_directory $HOME/diff
comment_directory $HOME/comments
#
# CORE OUTPUT DIRECTORY OPTIONS
#
hiscore_directory $HOME/hi
#
# CORE STATE/PLAYBACK OPTIONS
#
state
autosave 0
playback
record
mngwrite
aviwrite
wavwrite
snapname %g/%i
snapsize auto
snapview internal
statename %g
burnin 0
#
# CORE PERFORMANCE OPTIONS
#
autoframeskip 0
frameskip 0
seconds_to_run 0
throttle 1
syncrefresh 0
sleep 1
speed 1.0
refreshspeed 0
#
# CORE ROTATION OPTIONS
#
rotate 1
ror 0
rol 0
autoror 0
autorol 0
flipx 0
flipy 0
#
# CORE ARTWORK OPTIONS
#
artwork_crop 1
use_backdrops 0
use_overlays 0
use_bezels 0
use_cpanels 0
use_marquees 0
#
# CORE SCREEN OPTIONS
#
brightness 1.0
contrast 1.0
gamma 1.0
pause_brightness 0.65
effect none
#
# CORE VECTOR OPTIONS
#
antialias 1
beam 1.0
flicker 0
#
# CORE SOUND OPTIONS
#
sound 1
samplerate 48000
samples 1
volume 0
#
# CORE INPUT OPTIONS
#
coin_lockout 1
ctrlr
mouse 0
joystick 0
lightgun 1
multikeyboard 0
multimouse 0
steadykey 0
ui_active 0
offscreen_reload 1
joystick_map auto
joystick_deadzone 0.3
joystick_saturation 0.85
natural 0
joystick_contradictory 0
coin_impulse 0
#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device keyboard
adstick_device keyboard
pedal_device keyboard
dial_device keyboard
trackball_device keyboard
lightgun_device lightgun
positional_device keyboard
mouse_device lightgun
#
# CORE DEBUGGING OPTIONS
#
log 0
verbose 0
update_in_pause 0
debug 0
debugscript
debug_internal 0
#
# CORE MISC OPTIONS
#
drc 1
drc_use_c 0
bios
cheat 0
skip_gameinfo 0
uifont default
ramsize
confirm_quit 0
ui_mouse 0
autoboot_command
autoboot_delay 2
autoboot_script
http 0
http_port 8080
http_path web
#
# CORE MKChamp OPTIONS
#
disable_hiscore_patch 0
disable_nagscreen_patch 0
disable_loading_patch 1
#
# CORE SWITCHRES OPTIONS
#
modeline_generation 1
monitor custom
orientation horizontal
connector auto
interlace 1
doublescan 1
cleanstretch 0
changeres 1
powerstrip 0
lock_system_modes 1
lock_unsupported_modes 1
refresh_dont_care 0
dotclock_min 0
sync_refresh_tolerance 2.0
frame_delay 0
black_frame_insertion 0
modeline auto
ps_timing auto
lcd_range auto
crt_range0 "15250-16500, 40-80, 0.036, 4.688, 8.870, 0.190, 0.191, 1.018, 1, 1, 192, 288, 448, 576"
crt_range1 "23900-24420, 40-80, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 1, 1, 384, 400, 0, 0"
crt_range2 "31000-32000, 40-80, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 1, 1, 400, 512, 0, 0"
crt_range3 auto
crt_range4 auto
crt_range5 auto
crt_range6 auto
crt_range7 auto
crt_range8 auto
crt_range9 auto
#
# DEBUGGING OPTIONS
#
oslog 0
watchdog 0
#
# PERFORMANCE OPTIONS
#
multithreading 1
numprocessors auto
sdlvideofps 0
bench 0
#
# VIDEO OPTIONS
#
video opengl
numscreens 1
window 0
maximize 1
keepaspect 0
unevenstretch 0
centerh 1
centerv 1
waitvsync 1
scalemode none
#
# OpenGL-SPECIFIC OPTIONS
#
filter 0
prescale 1
gl_forcepow2texture 0
gl_notexturerect 0
gl_vbo 1
gl_pbo 1
gl_glsl 0
gl_glsl_filter 1
glsl_shader_mame0 /home/arcade/CRT/shader/glsl_plain
glsl_shader_mame1 /home/arcade/CRT/CRT-geom
glsl_shader_mame2 none
glsl_shader_mame3 none
glsl_shader_mame4 none
glsl_shader_mame5 none
glsl_shader_mame6 none
glsl_shader_mame7 none
glsl_shader_mame8 none
glsl_shader_mame9 none
glsl_shader_screen0 none
glsl_shader_screen1 none
glsl_shader_screen2 none
glsl_shader_screen3 none
glsl_shader_screen4 none
glsl_shader_screen5 none
glsl_shader_screen6 none
glsl_shader_screen7 none
glsl_shader_screen8 none
glsl_shader_screen9 none
gl_glsl_vid_attr 1
#
# PER-WINDOW VIDEO OPTIONS
#
screen auto
aspect auto
resolution auto
view auto
screen0 auto
aspect0 auto
resolution0 auto
view0 auto
screen1 auto
aspect1 auto
resolution1 auto
view1 auto
screen2 auto
aspect2 auto
resolution2 auto
view2 auto
screen3 auto
aspect3 auto
resolution3 auto
view3 auto
#
# FULL SCREEN OPTIONS
#
switchres 1
useallheads 0
#
# SOUND OPTIONS
#
audio_latency 2.0
#
# SDL KEYBOARD MAPPING
#
keymap 0
keymap_file keymap.dat
uimodekey SCRLOCK
#
# SDL JOYSTICK MAPPING
#
joy_idx1 auto
joy_idx2 auto
joy_idx3 auto
joy_idx4 auto
joy_idx5 auto
joy_idx6 auto
joy_idx7 auto
joy_idx8 auto
sixaxis 0
#
# SDL LIGHTGUN MAPPING
#
lightgun_index1 WiiMote0
lightgun_index2 WiiMote1
lightgun_index3 auto
lightgun_index4 auto
lightgun_index5 auto
lightgun_index6 auto
lightgun_index7 auto
lightgun_index8 auto
#
# SDL LOWLEVEL DRIVER OPTIONS
#
videodriver auto
audiodriver auto
gl_lib auto
-
I'm not a groovymame expert, so I can't comment on the ini, but I've seen similar behavior.
If groovymame seems alright for several seconds, then dips more than a percentage point, it's possible that something low-level on your machine is jumping in and claiming to be time-critical, or your CPU is changing speed. Both of those causes have been discussed here previously.
Intel's speedstep, and AMD's equivalent have caused trouble, as have fan, temperature, and CPU/GPU monitoring utilities.
On one of my machines, RivaTuner (and then MSI Afterburner) caused the problem. When it's a utility, you can sometimes catch it by running Microsoft's Sysinternals Process Explorer with the 'Cycles Delta' and 'Context Switch Delta' columns turned on, set at a 2 or 5 second refresh interval, and sorted by one of those two columns.
When the glitch happens, you should see a process jump up in the list. If the process that you see jump up is 'Interrupts', it's difficult to pin down, but for real processes, you just have to determine why that process is running and find out how to stop or change it.
To fix my problem, I had to turn off Afterburner's low level hardware monitoring. I guess it takes more cycles to gather each sample now, but I have plenty of cycles to spare as long as it doesn't mind waiting for them.
-
Thank you for your answer. In one way I am happy to see that this is not an isolated case.
I have also thought of the CPU being used for another time critical task or some interrupts duty that could eat the CPU cycles for a short period of time. Here is what I have investigated.
My first remedy test was to completely shield the CPU used for groovymame. Only the 3x/4x groovyume processes and 2 interrupts (0_timer and 2_cpus which cannot be disabled) were running on a dedicated core. I was still able to see the speed issue with a duty cylcle of 25% maximum.
Secondly, I looked also at Intel speed step cpu scaling, but playing with it only bring more MHz but do not cure the issue.
Thinking that the issue could be linked to the hardware timer I verified that the system use TSC and not HTPET. Which is the case.
I assume that I have no misbehavior coming from the operating system and do not consider it as the root of the speed issue. Now, I am thinking that this could come from a mame/groovyume internal behavior. Using the tekken rom, I have identified that the sound subroutine can produce some slow down depending how the system is configured (with or without -mt and in single/multiple core) the behavior is slightly different. A single core with single or multiple thread(s) gives 100% but multi cpu configuration without multithread only give 50%. To my understanding the synchronization mechanism from the sound or frame routine could play a role here. Before digging more into the details, I need to be sure that I do not have a wrongly configured parameter in my ume.ini setup file.
I am using Arch Linux (groovyarcade) distribution to conduct all my investigations. I know that some people have done latency measurements but I did not manage to see a description of their protocol. Would it be possible to have some description here?
-
Good rundown of where you're at. That helps to clarify why you're looking more intently at GM itself.
We seem to troubleshoot similarly, even though we're in different environments. I had also tried the dedicated core and thought I'd have it licked that way. Sadly, in Windows, it looks like 'hold everything for me' means 'hold everything even if it's not in my way.' Also, my problem machine only had 3 cores to mess with, and trying to give 2 to GM for mt had the OS tripping on itself. Well, at least the limitations pushed me to find the root instead of just working around it.
Latency wasn't involved for me, so I can't help you there. Interested to see how it works out though.
-
Hi Doozer,
I also get those 'speed percentage hiccups' in some games,, but I wouldnt worry too much. Don't trust the percentage, trust your eye. If scrolls are 100% smooth, you can say the emulation is solid. Video card's clocking is much more accurate. Don't even trust the sound, as its rate is internally linked to the above mentioned speed percentage which can be bogus.
-
Hi Calamity,
I must admit that scrolling is smooth and I confirm that the cracks are perceptible on the sound track when the slow down occurs.
Based on the multi-threading implementation, do you have an idea why the emulation speed jumps from 50% to 100% when all threads are moved back exclusively on the same cpu (mono core mode)? As far as I understood the new thread only handle the audio part separately from the main emulation loop. At the moment, I link the hiccups to the sound management process. But without some guidance, I do not see where to start from to track this down.
@nexusmtz, I suspect a thread synchronization issue happening during either the vertical blank retrace or audio buffer communication (perhaps buffer underrun). Normally, having multiple threads on multiple core should not produce any special effect on mame.
-
If scrolling is smooth, then the speed fluctuations you see are artifacts of the speed measurement routine, rather than from the actual emulation. This could be due to the granularity of the system timer in use, but it would require some research to find the actual reason with some certainty.
-
When you use -mt, rendering is moved to a separate thread. This includes the code for vsync. Usually waiting for vsync eats most cpu cycles available for a thread, so releasing it from this task may be the difference in cases where the cpu is already on its limit by the emulation itself. A sudden speed drop of 50% with vsync enabled is typical when the cpu can barely handle emulation speed at 100% without vsync. Missing the retrace forces the thread to wait for the next one for each frame causing the speed to be divided by two.
-
With regards to why single threaded execution performs better on single cpu, one explanation could be that there's some overhead introduced by core switching. Bear in mind that even without -mt MAME uses threads for the emulation itself. The only thing you control with -mt is which thread handles the rendering.
-
Thank you for the clarifications.
In case there is a need for investigation on some of these aspects, I am willing to help. In case I do progress on smoothing the emulation by finding what is causing the hiccups I will let you knon.
Cheers