Dynarec issues

[unreal9010]

It seems that between December 1 2020 (the day when PCem v17 was officially released) and June 2021 some dynarec-related regressions were accidentally introduced in PCem.
I've just done some testing with Pentium II 333 virtual machine running on Core i9 12900KF, using the latest available development version of PCem (85e1ef3) and got various degrees of regressions, ranging from mild (PCem running at 90% - Discworld, Journeyman Project 3) and medium (60% - Quake in software mode, Ultimate Race Pro) to severe (30% - Azrael's Tear).
I then ran all these games with v17 official stable release and none of the regressions happened. Performance was rock-solid at 100% the whole time.
Out of curiosity, I also tried the version from the commit 84b9af3 (dated June 7 2021) that I happened to have on my hard drive.
I can confirm the regressions mentioned above happen there too. Unfortunately I have no other development version that was released between December 1 2020 and June 7 2021 available to test and find out which commit precisely caused these regressions, however I see now that I first reported such issues on May 17 2021, meaning that they definitely existed by that time.

[unreal9010]

Update: Have just managed to compile the experimental version dated March 3 2021. Above regressions are present there too.

[tk421]

I have just tried Episode 1 Racer using the P2 333 in PCem on my i7 9750h. I admit that there were times when the emulation speed went below 100%, but not while I was playing the game. In-game performance was rock-solid at 100%. Performance only went below 100% when viewing in-game video cutscenes or when I booted Win98.

I am using the same v17 of PCem I used in Dec 2020.

In my experience PCem v17 performance is completely task-dependent. Some games run perfectly while others run below 100%. I have found the software to be extremely well-written.

I look forward to future developments in PCem. It is cutting edge software even in 2022.

tk421

[unreal9010]

Some games run perfectly while others run below 100%.

Yes, however, I am talking about specific cases that run at 100% speed with the stable build from 2020, but might regress down to 30% when using development builds from GitHub. That's a huge leap backwards. I also noticed that Configuration Manager in those builds is somewhat smaller and thinner compared to the one in v17. I am starting to think regressions could be related to the environment that these builds are being compiled in.

[tha_mos]

Some games run perfectly while others run below 100%.

Yes, however, I am talking about specific cases that run at 100% speed with the stable build from 2020, but might regress down to 30% when using development builds from GitHub. That's a huge leap backwards.

DevBuilds lack some profile optimizations that are used in stable releases, could be the reason. Also see https://pcem-emulator.co.uk/phpBB3/viewtopic.php?t=3755

[unreal9010]

Some games run perfectly while others run below 100%.

Yes, however, I am talking about specific cases that run at 100% speed with the stable build from 2020, but might regress down to 30% when using development builds from GitHub. That's a huge leap backwards.

DevBuilds lack some profile optimizations that are used in stable releases, could be the reason. Also see https://pcem-emulator.co.uk/phpBB3/viewtopic.php?t=3755

For this reason, I created a separate GitHub fork, using a source code from v17 2020 stable release and, believe it or not, I got regressions and the small and tiny configuration manager. My guess is that something went wrong in compiling process. Will try to compile it outside of GitHub and see what happens.
My workflow file (c-cpp.yml) looks as follows:

name: C/C++ CI

on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

jobs:
build:
strategy:
fail-fast: false
matrix:
include:

- name: Windows 32bits (MSYS2)
os: windows-latest
compiler: MINGW32
args: --enable-networking --enable-release-build CFLAGS="-DPCEM_BUILD_VERSION=${GITHUB_SHA::8}"
artifacts_name: PCem-Windows-MINGW32-${{ github.head_ref }}-${{ github.run_number }}
artifacts_path: PCem-${{ github.sha }}.zip
installdeps: >-
base-devel
zip
unzip
mingw-w64-i686-ntldd-git
mingw-w64-i686-toolchain
mingw-w64-i686-SDL2
mingw-w64-i686-openal
mingw-w64-i686-wxWidgets
mingw-w64-i686-autotools

runs-on: ${{ matrix.os }}
name: ${{ matrix.name }}

steps:
- uses: actions/checkout@v2
with:
path: temp
fetch-depth: 0

- name: Setup MSYS2 (Windows)
if: runner.os == 'Windows'
# You may pin to the exact commit or the version.
# uses: msys2/setup-msys2@a43b8403533fffe0c157dd8498f021ddec66bff7
uses: msys2/setup-msys2@v2
with:
# Variant of the environment to set by default: MSYS, MINGW32, MINGW64, UCRT64 or CLANG64
msystem: ${{ matrix.compiler }}
# Retrieve and extract base installation from upstream GitHub Releases
release: false # optional, default is true
# Update MSYS2 installation through pacman
update: false
# Install packages after installation through pacman
install: ${{ matrix.installdeps }}
- name: npcap download (Windows)
if: runner.os == 'Windows'
shell: msys2 {0}
run: |
wget https://nmap.org/npcap/dist/npcap-sdk-1.05.zip
unzip -d npcap-sdk-1.05/ npcap-sdk-1.05.zip
cd npcap-sdk-1.05
cp -r Include/* /mingw32/include/
cp -r Include/* /mingw64/include/
cp -r Lib/*.lib /mingw32/lib/
cp -r Lib/x64/*.lib /mingw64/lib/
- name: Setup ubuntu dependencies
if: runner.os == 'Linux'
run: |
sudo apt-get update
sudo apt-get install ${{ matrix.installdeps }}
# Copy all the sources to the dist folder, before we start generating intermediate files.
- name: prepare-package (Windows32)
if: runner.os == 'Windows' && matrix.compiler == 'MINGW32'
shell: msys2 {0}
run: |
mkdir dist
cp -R ./temp/* dist
rm -Rf ./dist/.git
cp /mingw32/bin/libdeflate.dll dist
cp /mingw32/bin/libexpat-1.dll dist
cp /mingw32/bin/libgcc_s_dw2-1.dll dist
cp /mingw32/bin/libjbig-0.dll dist
cp /mingw32/bin/libjpeg-8.dll dist
cp /mingw32/bin/libLerc.dll dist
cp /mingw32/bin/liblzma-5.dll dist
cp /mingw32/bin/libopenal-1.dll dist
cp /mingw32/bin/libpng16-16.dll dist
cp /mingw32/bin/libstdc++-6.dll dist
cp /mingw32/bin/libtiff-5.dll dist
cp /mingw32/bin/libwebp-7.dll dist
cp /mingw32/bin/libwinpthread-1.dll dist
cp /mingw32/bin/libzstd.dll dist
cp /mingw32/bin/SDL2.dll dist
cp /mingw32/bin/wxbase30u_gcc_custom.dll dist
cp /mingw32/bin/wxbase30u_xml_gcc_custom.dll dist
cp /mingw32/bin/wxmsw30u_adv_gcc_custom.dll dist
cp /mingw32/bin/wxmsw30u_core_gcc_custom.dll dist
cp /mingw32/bin/wxmsw30u_html_gcc_custom.dll dist
cp /mingw32/bin/wxmsw30u_xrc_gcc_custom.dll dist
cp /mingw32/bin/zlib1.dll dist

- name: configure (Windows)
if: runner.os == 'Windows'
shell: msys2 {0}
run: |
cd temp
autoreconf -i
./configure ${{ matrix.args }}
- name: make (Windows)
if: runner.os == 'Windows'
shell: msys2 {0}
run: |
cd temp
make -j
- name: package (Windows)
if: runner.os == 'Windows'
shell: msys2 {0}
run: |
cp ./temp/src/pcem.exe dist
cd dist
zip -r -9 ${{ matrix.artifacts_path }} *
- name: prepare-package (Linux)
if: runner.os == 'Linux'
run: |
mkdir dist
cp -R ./temp/* dist
rm -Rf ./dist/.git
- name: configure (Linux)
if: runner.os == 'Linux'
run: |
cd temp
autoreconf -i
./configure ${{ matrix.args }}
- name: make (Linux)
if: runner.os == 'Linux'
run: |
cd temp
make -j
- name: package (Linux)
if: runner.os == 'Linux'
run: |
cp ./temp/src/pcem dist
cd dist
tar -cjf ${{ matrix.artifacts_path }} *
- name: "Upload GitHub Actions artifacts"
uses: actions/upload-artifact@v2
with:
name: ${{ matrix.artifacts_name }}
path: ./dist/${{ matrix.artifacts_path }}

[tha_mos]

Yes, however, I am talking about specific cases that run at 100% speed with the stable build from 2020, but might regress down to 30% when using development builds from GitHub. That's a huge leap backwards.

DevBuilds lack some profile optimizations that are used in stable releases, could be the reason. Also see https://pcem-emulator.co.uk/phpBB3/viewtopic.php?t=3755

For this reason, I created a separate GitHub fork, using a source code from v17 2020 stable release and, believe it or not, I got regressions and the small and tiny configuration manager. My guess is that something went wrong in compiling process. Will try to compile it outside of GitHub and see what happens.

Ok, interesting. I thought the tiny configuration manager came during the development of v18. So it already existed back then?

[unreal9010]

It doesn't exist in the stable official release build which is available to download. It only exists in development builds and builds that you compile on your own using GitHub actions, be it with compiling instructions from spring 2021 or the more recent ones.

[MichaelJManley]

@unreal9010: Can you test and see if build 85e1ef3 is better in regards to speed https://github.com/sarah-walker-pcem/pc ... 2056679721

This build now uses compiler flags more on par with v17's release. GitHub Action builds were built with optimizations, so it was odd the speed differences on those but it was due to some missing extra optimizations.

[unreal9010]

.

[unreal9010]

@unreal9010: Can you test and see if build 85e1ef3 is better in regards to speed https://github.com/sarah-walker-pcem/pc ... 2056679721

This build now uses compiler flags more on par with v17's release. GitHub Action builds were built with optimizations, so it was odd the speed differences on those but it was due to some missing extra optimizations.

I've been testing the build 85e1ef3 since 2 weeks ago and that's the one with issues. I also tested the latest build (Commit ac0cc45) and got the same results.
I then tried to compile my own build outside of GitHub actions with MSYS2 by carefully following the instructions provided at your site, however, when executing the command cmake -G "MSYS Makefiles" -DUSE_NETWORKING=OFF -DCMAKE_BUILD_TYPE=Release ..
I got the following, despite that I installed all the required packages (Cmake and PCAP including):
CMake Error at CMakeLists.txt:8 (include):
include could not find requested file:

C:/msys64/home/includes/includes.cmake


PCem vNext - Build Type: Release
***************************************************************
OS Building For: Windows
System Processor: x86_64
***************************************************************
Plugin Support: OFF
Networking Support: OFF
Experimental Modules: OFF
***************************************************************
PCem Program Directories:
PCem Share Directory: bin
PCem Binary Directory: bin
PCem Library Directory: sdk/lib
PCem Plugin Directory: bin/plugins
PCem Include File Directory: sdk/include
***************************************************************
CMake Error at CMakeLists.txt:113 (include):
include could not find requested file:

apple.cmake


CMake Error at CMakeLists.txt:127 (find_package):
By not providing "FindPCAP.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "PCAP", but
CMake did not find one.

Could not find a package configuration file provided by "PCAP" with any of
the following names:

PCAPConfig.cmake
pcap-config.cmake

Add the installation prefix of "PCAP" to CMAKE_PREFIX_PATH or set
"PCAP_DIR" to a directory containing one of the above files. If "PCAP"
provides a separate development package or SDK, be sure it has been
installed.


-- Configuring incomplete, errors occurred!

[unreal9010]

Another interesting thing: builds that do not cause performance issues come without generated wxWidgets DLL files.

[MichaelJManley]

Humm, you shouldn't even be asked for PCap if Networking is off. I'll push a fix for that now.

Should be able to compile now if you pull recent code

[unreal9010]

Thank you for fixing it. I've just compiled my own build and tested some stuff.
Unfortunately regressions are still present. Quake in software mode at 320x240 can drop down to 40% (it's at rock-solid 100% the whole time in v17 stable build).
Is it possible to generate some sort of a log file or open a debugger to see what gets reported once these regressions start to kick in?

[unreal9010]

For now, the workaround with experimental builds is to turn the internal CPU cache off in the virtual machine BIOS. Comes in handy for software Quake, old LucasArts SCUMM engine-based adventure games (with the exceptions of Full Throttle and The Dig), in particularly Monkey Island 1/2, Sam and Max, Day of the Tentacle, Indiana Jones and the Fate of Atlantis.
Also brings some 3D stuff such as UltraHLE and Ultimate Race Pro to 100%, but framerates are of course very choppy due to the lack of internal CPU cache.

[MichaelJManley]

I'll look into what changed since v17 and now. I have yet to do any code changes on Dynarec so it's very strange it has any slowdown in that area.

[MichaelJManley]

Going back I did notice this

https://github.com/sarah-walker-pcem/pcem/issues/92

It seems one function got optimizations disabled due to the emulator crashing, I need to find which build I implemented this in. Could be GCC is optimizing wrong.

[SarahWalker]

Did you ever get a backtrace for that crash? Disabling optimisation for exec_recompiler() will absolutely kill performance, it's the dispatcher for the recompiler and definitely needs to be optimised!

[MichaelJManley]

Found the build: https://github.com/sarah-walker-pcem/pc ... 66afa76031

So I did a Release build with that optimization disable attribute removed, if possible can you check to see if this build has the same lag issues?
https://repo.nasutek.com/repository/pce ... 220413.zip

[MichaelJManley]

Did you ever get a backtrace for that crash? Disabling optimisation for exec_recompiler() will absolutely kill performance, it's the dispatcher for the recompiler and definitely needs to be optimised!

It only happened on release builds, it was beyond odd. But it could have been due to missing optimization parameters which are now added into CMake. The newer release build I just posted did not segfault when the dynarec is enabled.

EDIT: So what would happen is on a certain section of exec_recompiler it would complain about a section being "optimized out" then segfault. it was around this line

Code: Select all

                void (*code)() = (void *)&block->data[BLOCK_START]; // FIX: This seems to get optimized out, I tried making volatile but still segfaulted

Though it seems resolved at least on Windows with the correct release flags

[unreal9010]

Found the build: https://github.com/sarah-walker-pcem/pc ... 66afa76031

So I did a Release build with that optimization disable attribute removed, if possible can you check to see if this build has the same lag issues?
https://repo.nasutek.com/repository/pce ... 220413.zip

Just checked the build from Nasutek repository. Unfortunately, this build is even a tad slower since software Quake now drops down to 38% with dynarec enabled.

[unreal9010]

I really wonder what causes these lags and bottlenecks to happen. For example, games Archimedean Dynasty and Extreme Assault both utilize the same technology and come from the same developer, yet AD is always consistent at 100% whereas EA jumps between 40-60%. It might be of use to compare debug outputs of both games. A similar thing with Full Throttle (which runs at constant 100% till the end) and other SCUMM engine titles (e.g. Monkey Island 1/2, Sam and Max, Day of the tentacle that regress heavily with internal CPU cache on).
As with the Museum Madness MIDI bug, fixing regression issues with one of these games will likely help other games affected by this bug.

[unreal9010]

I've got an interesting discovery to report regarding regressions. I've just tested the 1996 game Time Commando (Windows 95 version) under emulated Pentium II 400 Mhz, 64 MB RAM, ViRGE/DX (4 MB) running Windows 95. If I leave the flipping option on the game runs beautifully at 100%, however, if I turn the flipping option off then the average emulation speed would range between 60-65%.
I think the regressions could be related to page-flipping.