Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|06715||Speed||Major||Always||Oct 14, 2017, 10:32||Oct 22, 2017, 01:10|
|Assigned To||Resolution||Invalid report||OS||Linux (64-bit)|
|Version||0.190||Fixed in Version||Build||64-bit|
|Summary||06715: Huge slowdown with bezels|
Emulation get a huge slowdown if a bezel artwork is used, this only happens on Linux. It happened with a cps1 game, it might happen with others too.
Sorry, I don't have a rom collection to test it out.
|Steps To Reproduce||
- Copy the attached bezel file over artwork
- ./mame64 sf2
- Enable demo sounds
- As the audio start the emulation start to drag.
|Affected Sets / Systems|
sf2.zip (3,510,660 bytes) Oct 14, 2017, 10:32 Uploaded by wuemura
sf2 Bezel Artwork
|There are no relationship linked to this issue.|
Oct 14, 2017, 12:28
Some video modes are not as robust as others, I'd imagine.
From what I understand using Linux is an extreme exercise of finding just the right video setup/driver for your setup.
I'll let someone using SDL test/respond, but I assume it breaks down to what video mode you are using with MAME and what video libraries you may have installed.
Oct 14, 2017, 12:34
It only happens if the combination of bezels and sound are enabled, turning off sound or bezels makes the issue goes away.
Oct 14, 2017, 12:55
I'm wrong, using "-audio none" it drags the same.
This is my main settings:
GIGABYTE AM3+ ATX GA-990FXA-UD5 R5
AMD FX-8350 Vishera
Corsair Vengeance 16GB (2x8GB) 1866MHz DDR3 CL10 Red CMZ16GX3M2A1866C10R
wellington@Dragon:~/Downloads/_mame$ lspci|grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde PRO [Radeon HD 7750/8740 / R7 250E
This info is from the git version, it might help.
Available videodrivers: x11 wayland dummy
Current Videodriver: x11
Available audio drivers:
Build version: 0.190 (mame0190-364-gd1acf72abb-dirty)
Build defines 1: SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1
Build defines 1: LSB_FIRST=1 PTR64=1 MAME_DEBUG=1
SDL/OpenGL defines: SDL_COMPILEDVERSION=2005 USE_OPENGL=1
Compiler defines A: __GNUC__=6 __GNUC_MINOR__=3 __GNUC_PATCHLEVEL__=0 __VERSION__="6.3.0 20170516"
Compiler defines B: __amd64__=1 __x86_64__=1 __unix__=1
Compiler defines C: __USE_FORTIFY_LEVEL=0
Adding monitor screen0 (1920 x 1080)
Invalid video value dummy; reverting to software
Invalid prescale option, reverting to '1'
Using SDL multi-window soft driver (SDL 2.0+)
Oct 15, 2017, 16:39
Invalid video value dummy; reverting to software
You seem to be using software which is the lowest speed/most compatible video available. Also, prescale appears to be set somewhere and MAME is reverting because it is an invalid value.
Oct 17, 2017, 10:53
That's MAME default, I didn't set any video driver.
The prescale, was set to "0" zero, "1" is the only valid option?
What if the user want prescale disabled? It would enable it any way?
I'll do some tests latter to see if I change the video driver the issue get's better.
Oct 17, 2017, 17:22
prescale = 2 means to scale the output to 2x its natural size, prescale = 1 is 1x natural size which is the same as no prescale, so prescale = 0 is meaningless.
Are you sure you don't have a mame.ini tucked away somewhere, the actual MAME defaults would not be invalid.
Oct 18, 2017, 00:57
edited on: Oct 18, 2017, 01:00
Looking further, there was a hidden folder at ~/.mame with a mame.ini inside, about the prescale issue, MAME allowed me to change it to "0" from that video setting option, it was set that way because I was testing the video option crashing bug. And by the way, there is another bug that I need to fill about that.
The video issue, the default value for video was "auto" and so is shown at the internal interface, MAME should pick up the best driver available, why it choose "dummy"? The best option for videorender was - if available - opengl, not dummy or software.
If we took the audio driver for example, MAME uses the best driver available, in my case pulseaudio, it didn't choose "dummy" in auto settings. Why in video it chooses "dummy" than moves to software? There should be a condition inside MAME to decide witch best driver to use in his auto settings, dummy and software should be the last options if nothing else are available.
Specific to this slowdown, manually changing the video from "auto" to "opengl" is a workaround to the problem, not a fix, MAME should decide and go with a better option if available.
Oct 18, 2017, 03:13
|If you provide an video option to MAME which doesn't work or isn't valid (the 'dummy' mentioned), it doesn't determine "best use" - it simply drops to the most compatible/baseline one guaranteed to work to all video cards (Software for SDL, GDL for Windows). With -audio assigments, it defaults to whatever AUTO is for the environment you are in.|
Oct 18, 2017, 12:01
We understand that, if the user set an invalid option.
In my case it was "auto", MAME correctly detected my environment, listed the best options and still choose dummy first. If the audio assignment choose the best environment I'm in, why can't video do the same?
As the output show, MAME already does that:
I'm not a programmer, can MAME do if this this and this options available, than use it, else use the best compatible option available. Mame already listed the best available option "opengl" as first but didn't use it for auto.
Windows is a very different environment, the video set as "auto" MAME chooses the best option available, Direct 3D in my case:
Oct 21, 2017, 23:13
|Requesting more feedback on this one...|
Oct 22, 2017, 00:38
|What do you need?|
Oct 22, 2017, 01:10
|He means Developer feedback.. Devs that have access to a Linux machine and can answer issues with more authority.|