Build Your Own Arcade Controls Forum

Software Support => GroovyMAME => Topic started by: chrisvg on March 10, 2016, 06:57:06 am

Title: GM crashing when multithreading is enabled with video output set to opengl
Post by: chrisvg on March 10, 2016, 06:57:06 am
Not sure if this has been raised by anyone, I did a quick search and didn't see any threads on it... I apologize if this is old hat.

My mame.ini has the following set:
Code: [Select]
multithreading            0
video                     auto

If I run the following commandline:
Code: [Select]
mame64 -video opengl froggerEverything is fine.

Now, add in multithreading to the commandline:
Code: [Select]
mame64 -video opengl -mt froggerI get a big ol' stack dump from the OpenGL display code in MAME. eg:

Code: [Select]
OpenGL: VBO not supported, missing: glGenBuffers, glDeleteBuffersglBindBuffer, glBufferData, glBufferSubData,
OpenGL: PBO not supported, no VBO support.
OpenGL: FBO not supported, missing: pfn_glIsFramebuffer, pfn_glBindFramebuffer, pfn_glDeleteFramebuffers, pfn_glGenFramebuffers, pfn_glCheckFramebufferStatus, pfn_glFramebufferTexture2D,
OpenGL: PBO not supported
OpenGL: FBO not supported

-----------------------------------------------------
Exception at EIP=0000000000000000 (): ACCESS VIOLATION
While attempting to write memory at 0000000000000000
-----------------------------------------------------
RAX=00000000000000FF RBX=000000001298D2C0 RCX=0000000000000001 RDX=000000001298D38C
RSI=000000000A747550 RDI=000000001298D36C RBP=00007FF9F7B71100 RSP=00000000109AFB88
 R8=000000000000812D  R9=000000001298D36C R10=0000000000000000 R11=0000000000000300
R12=0000000000002035 R13=0000000000000001 R14=0000000000000000 R15=0000000000000000
-----------------------------------------------------
Stack crawl:
  00000000109AFB80: 0000000000000000 ()
  00000000109AFC10: 00000000015EA2AE (isa8_sblaster1_0_device::isa8_sblaster1_0_device(machine_config const&, char const*, device_t*, unsigned int)+0x029e)
  00000000109AFE00: 00000000015EDB5E (stereo_fx_device::invalid_r(address_space&, unsigned int, unsigned char)+0x000e)
  00000000109AFEA0: 00000000015EE525 (stereo_fx_device::device_start()+0x0425)
  00000000109AFF00: 00000000015DA871 (gf1_device::global_reg_data_r(address_space&, unsigned int, unsigned char)+0x0031)
  00000000109AFF50: 00000000015DA955 (gf1_device::global_reg_data_r(address_space&, unsigned int, unsigned char)+0x0115)
  00000000109AFF80: 00007FFA1FDC8102 (BaseThreadInitThunk+0x0022)
  00000000109AFFD0: 00007FFA22A0C5B4 (RtlUserThreadStart+0x0034)

I was going to try running Intealls' GMASIO build on my desktop PC with Lottes' GLSL CRT shader on a GSync monitor, but it looks like that's gonna have to wait for another day ;)

Finally, I did try this with the standard vanilla MAME build and did not have any trouble enabling both opengl and mt, tho I am quite aware that vanilla MAME's implementation of mt is quite different to GM's, so this is merely an observation.
Title: Re: GM crashing when multithreading is enabled with video output set to opengl
Post by: Calamity on March 10, 2016, 10:58:55 am
Yeah multithreading is broken in GM/OpenGL. I didn't spend time trying to figure this out when I saw OpenGL doesn't support proper vertical synchronization anyway.
Title: Re: GM crashing when multithreading is enabled with video output set to opengl
Post by: chrisvg on March 10, 2016, 11:14:58 am
No worries mate, thanks for the confirmation that it's a known issue.

It's certainly no problem if it's not a priority to fix, I play with GM on my cab 99% of the time ;)
Title: Re: GM crashing when multithreading is enabled with video output set to opengl
Post by: haynor666 on March 16, 2016, 02:35:12 pm
mt option will probably soon be removed from mame so this won't be an issue.
Title: Re: GM crashing when multithreading is enabled with video output set to opengl
Post by: Calamity on March 16, 2016, 02:56:37 pm
mt option will probably soon be removed from mame so this won't be an issue.

It's removed already for 0.172.
Title: Re: GM crashing when multithreading is enabled with video output set to opengl
Post by: krick on March 17, 2016, 12:10:21 am
Didn't GroovyMAME require multithreading for interlaced games on Windows 7 at one point?

Or is this fixed with CRT_Emudriver 2.0 and an ATI Radeon 5000+ card?

Title: Re: GM crashing when multithreading is enabled with video output set to opengl
Post by: haynor666 on March 17, 2016, 03:46:36 am
I know mt was caused some problems in official mame but it's (really?) required in groovymame and allowed speed up a little some drivers like psx based games or cv1k games. Probably we have to live it without this option :/
Title: Re: GM crashing when multithreading is enabled with video output set to opengl
Post by: Calamity on March 17, 2016, 07:21:51 am
Didn't GroovyMAME require multithreading for interlaced games on Windows 7 at one point?

GroovyMAME requires -mt for its triplebuffering implementation. What was required for interlaced games was DirectDraw (also gone now).

Quote
Or is this fixed with CRT_Emudriver 2.0 and an ATI Radeon 5000+ card?

The interlaced issue doesn't exist with 5000+ cards. For legacy cards you have 2 options in Windows 7:

- Use frame_delay
- Enable positive sync (not possible for many arcade monitors)

Title: Re: GM crashing when multithreading is enabled with video output set to opengl
Post by: haynor666 on March 17, 2016, 04:10:47 pm
Quote from: Calamity
GroovyMAME requires -mt for its triplebuffering implementation.

So how this will work now? I think some vector games that needs 42 Hz (or something like that) works on my setup with 49,5 Hz.
Title: Re: GM crashing when multithreading is enabled with video output set to opengl
Post by: Calamity on March 17, 2016, 04:53:45 pm
Quote from: Calamity
GroovyMAME requires -mt for its triplebuffering implementation.

So how this will work now? I think some vector games that needs 42 Hz (or something like that) works on my setup with 49,5 Hz.

It won't work. GM will need to resort to default throttled/nowaitvsync behaviour until something is figured out. I'm still thinking how to deal with this in the future. I might reimplement mt from the ground up, anyway it was rather buggy lately, but not in the same way baseline mt is. On the other hand, new versions of DirectX do support asynchronous rendering, so mt wouldn't be needed in the future. But that would need people making their minds up to move to Windows 7.