Adds support for preventing the display from sleeping while a game is
running. Supports Windows, Linux (with the org.freedesktop.ScreenSaver
D-Bus service), and macOS.
* Use Linux timers for sleeps up to 1ms (v3)
The current sleep timer implementation basically offers two variants. Either
wait the specified time exactly with a condition variable (as host) or use a
combination of it with a thread yielding busy loop afterwards (usleep timer).
While the second one is very precise it consumes CPU loops for each wait call
below 50us. Games like Bomberman Ultra spam 30us waits and the emulator hogs
low power CPUs. Switching to host mode reduces CPU consumption but gives a
~50us penalty for each wait call. Thus extending all sleeps by a factor of
more than two.
The following bugfix tries to improve the system timer for Linux by using
Linux native timers for small wait calls below 1ms. This has two effects.
- Host wait setting has much less wait overhead
- usleep wait setting produces lower CPU overhead
Move source files to Emu/GDB.cpp, GDB.h
Remove "WITH_GDB" option, enable GDB Server by default.
Change class name to gdb_thread.
Alias for external access gdb_server.
Change config option name to "GDB Server"
Bind on 127.0.0.1 by default.
* camera_frame = NULL is now checked for CELL_GEM_NO_VIDEO (applied both on start and finish)
* camera_frame = NULL on Start() still starts the update
* Implemented NOT_FINISHED/STARTED
All of those were reversed and hw tested.
* sys_cond fixes
sys_cond_wait is now signaled atomically (regression fix)
Fix a corner case with sys_cond_wait and sys_cond_destroy EBSUY check (waiter count was inaccurate if thread is not the owner of mutex)
Add not about EBUSY corner case (TODO)
* Fix inconcistency in sys_cond_destroy and ETIMEDOUT
.. event at sys_cond_wait regarding waiters count.
Now waiters count is properly connected to the mutex owner actions after ETIMEDOUT in sys_cond_wait.
- If a stale reference is left lying around (e.g the texture bound to
depth has been deleted and we attach a color image) no operations
actually take place. glCheckFramebufferStatus also does not catch this
problem.
- Sometimes program-point-size is enabled, but the vs does not actually
write to the point size register. In this case, pass the incoming point
size along instead of the default register init.
- When compiling LLVM objects, it is possible to starve the driver thread and cause the timeouts to trigger
- Observed in RE6 when using SPU LLVM since the game generates a very large number of objects "infinitely"
