Slow speed on OpenBSD

[bentley]

gbe_plus and gbe_plus_qt run at (about?) half speed on OpenBSD. This occurs in both 1.1 and master.

Wildly speculating, I messed around with the sample rate, but except for audio quality, values of 1/22000/24000/44000/48000/96000 don’t seem to act any differently. (The OpenBSD sound server defaults to 48000.)

I’m not really sure what information would help debug this issue, but I’m happy to provide it…

[shonumi]

Does it run at about 30FPS? Is it just audio slow or is audio and video slow? You can view the FPS in the SDL only version (the gbe_plus binary compiled one directory above gbe_plus_qt's binary). For that matter, how does the SDL version run?

Only thing I can think of is that it's some weird VSync issue (iirc, something similar happens on Dolphin under some conditions). GBE+ doesn't use VSync for software rendering, but it will use whatever limit is imposed by your driver's when using OpenGL. Try disabling OpenGL and see if that works. The problem is with however the drivers handle stuff in that case.

If it's just audio that's slow (audio runs in a separate thread on GBE+, and the video thread shouldn't be affected by any slowdowns) it may be that SDL2's audio buffering being too small, but in that case 48KHz usually solves anything, and 96KHz should have been overkill, so it could be something else.

Lastly, you wouldn't happen to have any CGFX options set by any chance?

[bentley]

Video and audio are both slow. SDL and Qt perform identically.

How do I view the FPS? I don’t see it in the SDL output:

GBE+ 1.1 [SDL]
MMU::Initialized
CPU::Initialized
GBE::Launching DMG-GBC core
MMU::Cartridge Type - MBC5
MMU::ROM Size - 256KB
MMU::ROM CRC32: f630dc62
MMU::games/roms/dmg/pht-mr.gbc loaded successfully. 
LCD::Initialized
APU::Initialized
SIO::Initialized

I’m running with the default gbe.ini from master. use_opengl is already set to 0 there; setting it to 1 results in (if the shader exists) a segfault during “OGL::Compiling vertex shader : /home/anthony/.gbe_plus/data/shaders/vertex.vs” or (if the shader doesn’t exist) a black screen with slow audio still going in the background.

Thread 1 received signal SIGSEGV, Segmentation fault.
strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:124
124             movq    (%rax),%rdx             /* get bytes to check */
(gdb) bt
#0  strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:124
#1  0x000009ce68eeea5a in std::__1::char_traits<char>::length (__s=0x0)
    at /usr/include/c++/v1/string:647
#2  std::__1::operator<< <std::__1::char_traits<char> > (__os=..., __str=0x0)
    at /usr/include/c++/v1/ostream:894
#3  ogl_load_shader (vertex_shader_file=..., fragment_shader_file=..., 
    ext_data_usage=@0x9d13daad2cc: 0)
    at /tmp/gbe-plus/src/common/ogl_util.cpp:434
#4  0x000009ce68e64fd1 in DMG_LCD::opengl_init (this=0x9d13daad280)
    at /tmp/gbe-plus/src/dmg/opengl.cpp:131
#5  0x000009ce68e55921 in DMG_LCD::init (this=0x9d13daad280)
    at /tmp/gbe-plus/src/dmg/lcd.cpp:209
#6  0x000009ce68e50c65 in virtual thunk to DMG_core::start() ()
    at /tmp/gbe-plus/src/dmg/core.cpp:64
#7  0x000009ce68e01241 in main (argc=<optimized out>, args=0x7f7fffff2878)
    at /tmp/gbe-plus/src/main.cpp:100

use_cgfx is set to 0.

[shonumi]

FPS appears in the program title bar, although it might not pop up depending on what kind of window manager you have. On X.org and Windows 8 it will show up, but I have no idea what OpenBSD uses (X.org as well?)

The error log shows a bunch of mis-handling for string related stuff when parsing the shaders, but none of that happens on my end when.

So to clarify, can you actually run the SDL version with OpenGL disabled? What does your CPU load look like during that time?

[bentley]

Yes, with OpenGL enabled I get the mentioned crash, and with it disabled the game plays and appears to be correct, just too slow.

Window title says “GBE+ 34FPS” and doesn’t appear to vary.

CPU usage is nothing excessive:

20052 anthony   10    0   14M   18M sleep/2   nanosle   0:01  0.24% gbe_plus

[shonumi]

Hmm, that doesn't makes any sense :( There's nothing in GBE+'s code that would cause it to slow down to roughly half-speed like that when the load is so low.

Timing is controlled via the emulated LCD, specifically this line, and the only thing that can mess that up would be however SDL_GetTicks() works, which is dependent on how the system clock works. If there's something interfering with the how the system clock is presented to SDL, that's the culprit rather than GBE+.

It could be a bug in SDL2. Are you on SDL 2.0.7? If not, try upgrading.

One more question, what happens when you disable the frame limit (default hotkey = TAB) using SDL and no OpenGL?

[bentley]

Updated to SDL 2.0.7 and rebuilt GBE+; no difference in behavior.

I get 833 FPS when pressing tab.

[shonumi]

Still not sure what exactly OpenBSD doesn't like :/

It would probably take me a while to get around to setting up OpenBSD in a VM or something (lack of time rather than effort). In the meantime, if you know how to do bisecting, could you perhaps narrow down which commit first caused this slowdown?

[bentley]

I don’t know that there was a first commit. I faintly recall having the same problem at the time I reported #37; I just never got around to reporting it (sorry…).

[shonumi]

No worries. Like I said, it'll be a while before I get a test environment setup, but so far at least I have some decent information about what's going on, so thanks for answering all my questions so far.

[stefan9999991]

Having the same problem. Any fixes?

[mincerafter42]

I am also having this problem and also would like to hear of fixes.