Wierd Lag, CPU Optimisations on Linux

[debianidiot]

Hi,

Ive been having some issues with all linux internals, where in the overlay there using seems to lag behind my refresh rate. Theres no FPS dip, more like a slight delay on the frame buffer or something.

Similar issues described in the issues below - Ive done pretty much everything to optimize the game, my system and setup similar to the issues described.

https://github.com/HackerPolice/MissedIT/issues/27 https://github.com/HackerPolice/MissedIT/issues/23

Ive noticed your the most active of the developers, and having compiled Osiris I too see the same issue I see with the fusion forks. So its related to sdlswapwindow or imgui or its limitations?

So what do I want? Well.. considering this is a limitation of dearimg or whatever, how would I edit the project settings on linux to enable CPU optimizations? I have ryzen 5000 series CPU and would for sure benefit from some of those available. I could do somethign similar with visual studio, but dont have the issue in windows.

Id like to take the opportunity to also thank you for all your work in the CSGO space. Your one byte python stuff allowed me to scrape together a pretty effective python multi hack, using your repos and resources at UC and GH, so thanks.

TL:DR How to edit project settings on linux to enable AVX / AVX2 / AVX-512 instructions sets.

[debianidiot]

I added native to the release flags, although Im not sure this is correct. set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -fno-rtti -march=native")

[mdilai]

Osiris using outdated version of imgui. I've tried to update OpenGL backend with latest commits from ImGUI master and created PR #3456. To try it right now just run following commands inside your local Osiris repo folder:

$ git fetch origin pull/3456/head
$ git merge FETCH_HEAD

In CMakeLists.txt you can replace line set(CMAKE_C_FLAGS_RELEASE "-O3 -fvisibility=hidden -flto -fno-exceptions -DNDEBUG -Wfatal-errors") with set(CMAKE_C_FLAGS_RELEASE "-Ofast -march=native -fvisibility=hidden -flto -fno-exceptions -DNDEBUG -Wfatal-errors") in order to get maximum optimization.

Of course, don't forget to compile in Release mode, e.g. mkdir Release && cd Release && cmake -D CMAKE_BUILD_TYPE=Release .. for Arch, or sudo apt-get update && sudo apt-get install -y libsdl2-dev libfreetype-dev gcc-10 g++-10 mkdir Release && cd Release && cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_C_COMPILER=gcc-10 -D CMAKE_CXX_COMPILER=g++-10 .. for Ubuntu

Let us know if you get any difference.

[debianidiot]

Ok so Ive compiled with the pr mentioned and added the flags in cmakelists and the issue is still present.

I appreciate everything you've done and Im sure ill benefit from the more performant code. The update youve pushed is great and I hope it gets pushed across other linux releases - it was much needed regardless of if the issue here still remains. So once again, thanks for your time with the PR!

Its most pronounced when underfire from multiple enemies. I can re create the issues easily by loading up a custom map. There is no frame dip on the frame counter. Id guess the overlay is like 60fps or something, and dips further under stress. Its no big deal, ill push through it and keep checking the updates across all the linux repos/

EDIT: Seriously, thanks for this. Alot of people pass through the repos without recognition of the time taken.

Osiris using outdated version of imgui. I've tried to update OpenGL backend with latest commits from ImGUI master and created PR #3456. To try it right now just run following commands inside your local Osiris repo folder:

$ git fetch origin pull/3456/head
$ git merge FETCH_HEAD

In CMakeLists.txt you can replace line set(CMAKE_C_FLAGS_RELEASE "-O3 -fvisibility=hidden -flto -fno-exceptions -DNDEBUG -Wfatal-errors") with set(CMAKE_C_FLAGS_RELEASE "-Ofast -march=native -fvisibility=hidden -flto -fno-exceptions -DNDEBUG -Wfatal-errors") in order to get maximum optimization.

Of course, don't forget to compile in Release mode, e.g. mkdir Release && cd Release && cmake -D CMAKE_BUILD_TYPE=Release .. for Arch, or sudo apt-get update && sudo apt-get install -y libsdl2-dev libfreetype-dev gcc-10 g++-10 mkdir Release && cd Release && cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_C_COMPILER=gcc-10 -D CMAKE_CXX_COMPILER=g++-10 .. for Ubuntu

Let us know if you get any difference.

[mdilai]

You're welcome. I did this long time ago for myself so, basically, now i've just did a pull request with two clicks :smile:

As for your problem, you can determine your ImGUI framerate with following patch:

diff --git a/Osiris/Hacks/Misc.cpp b/Osiris/Hacks/Misc.cpp
index d968f3e2..776f65a2 100644
--- a/Osiris/Hacks/Misc.cpp
+++ b/Osiris/Hacks/Misc.cpp
@@ -509,7 +509,7 @@ void Misc::watermark() noexcept
     static auto frameRate = 1.0f;
     frameRate = 0.9f * frameRate + 0.1f * memory->globalVars->absoluteFrameTime;

-    ImGui::Text("Osiris | %d fps | %d ms", frameRate != 0.0f ? static_cast<int>(1 / frameRate) : 0, GameData::getNetOutgoingLatency());
+    ImGui::Text("Osiris | %d game fps | %d ImGUI fps | %d ms", frameRate != 0.0f ? static_cast<int>(1 / frameRate) : 0, static_cast<int>(ImGui::GetIO().Framerate), GameData::getNetOutgoingLatency());
     ImGui::End();
 }

Apply it to Osiris/Hacks/Misc.cpp, recompile, and enable Watermark at Misc tab. Now you will see both FPS of game renderer and framerate of ImGUI itself. Then load your custom high fps map and compare this values.

[debianidiot]

rebuilt with the patch applied.

The frame rates are basically identical. The imgui frame rate is too, in the 500/600s. Perhaps pushing these frames in the overlay is effecting performance when under strain?

For the sake of testing, are you aware of anyway I can apply a frame cap to the overlay, or sync imgui to my refresh rate?

[mdilai]

Provide your system information. CPU, GPU, drivers, distro version etc. you can get a nice hardware info from Steam itself, look at menu.

[mdilai]

Open ~/.local/share/Steam/steamapps/common/Counter-Strike\ Global\ Offensive/csgo.sh and add following lines before # and launch the game

export __GL_YIELD="NOTHING"
export __GL_MaxFramesAllowed="1"

Also be sure that you running CSGO with performance governor: echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

[debianidiot]

Had the performance governor and max frames set, Ill see if export __GL_YIELD="NOTHING" does anything and report back.

Thanks again for the input, appreciated.

[mdilai]

You may try to increase __GL_MaxFramesAllowed as well.

[debianidiot]

I already had the performance governor and max frames allowed, ive now added the yield command and captured some footage.

Its much easier to feel than see, the limitations of OBS capture doesnt help. But its there. As I take damage and dip back into cover, 00:02 to 00:03 the screen seems to hitch or something, otherwise gameplay is smooth as butter. This continues when I slip through the boxes again although its not as apparent in the footage.

https://streamable.com/fnw71v

I have footage without injection, the issue is not there, I can dip into and out of cover, under fire, with no hitches.

https://streamable.com/qfzys6

Its hard to capture this with the limit of OBS, but I hope the first example clearly shows the hitch, on atleast the first "jiggle".

[mdilai]

I've remembered that i had such slowdowns when experimented with different kernel configurations and schedulers. Try stock Manjaro kernel and/or Manjaro RealTime kernel.

[debianidiot]

I've remembered that i had such slowdowns when experimented with different kernel configurations and schedulers. Try stock Manjaro kernel and/or Manjaro RealTime kernel.

Ive tried different distros and kernels, Xanmod, Liquorix, tkg. I first encountered this issue on ubuntu maybe 6 months ago, figured it was hardware teething problems. Moved on to manjaro and always played CSGO on windows. Python was rather limiting so I came back to check out some of the linux offerings, feeling safer about VAC.

Ive tried some different schedulers when building kernel, but couldnt recall which now. Ill look into Manjaro RT and report back along with tweaking max frames allowed. Thanks again.

[mdilai]

Also my CSGO launch parameters, just for case xrandr -s 1440x1080; nvidia-settings -a "DigitalVibrance=1023"; gamemoderun %command% -dxlevel 90 -novid -nojoy -nosteamcontroller -noff -softparticlesdefaultoff -reuse -gl_enablesamplerobjects -gl_texclientstorage -NoQueuedPacketThread -gl_nv_bindless_texturing -off_nouserclip -nobreakpad -noaafonts -trusted -gl_swaplimit 0 -high; nvidia-settings -a "DigitalVibrance=0"; xrandr -s 1920x1080

[mdilai]

Btw, for python i prefer PyPy instead of CPython, it have a JIT-compiler and a lot faster.

[debianidiot]

Tried multiple schedulers.. unfortunately no change. I feel its certain to happen when I take damage, or soon after. Does the cheat perform any calculations based on damage taken? Are there any hooks that can play custom damage sounds? I feel I cant ignore the fact it only seems to happen when Im shot at, and hit.

I theorized it could be to do with the damage indicator being drawn, but removing the hud still shows the issue. Figured maybe it was an audio issue linked to being hit, so I tweaked the snd_mixahead latency to take some strain off the audio device, as well as editing packet sizes in pulse audio conf before returning them to default values. Still the same result.

Tried Kubo to rule out any GDB issues after trawling through the open issues. Nothings changed.

[mdilai]

Personally I had changed #define OSIRIS_SOUND() true to false inside Osiris/Hacks/Sound.h to avoid all fancy sound modulations (doesn't affect hitsound/killsound btw)

GameData::update() is one of the heaviest computation part of Osiris and running on each frame. PlayerData::update() and LocalPlayerData::update() functions update a bunch of data for both local player(who take damage) and remote players (who caused damage). Somewhere there may be issue. Every access to GameData is guarded with "mutex lock". It is a mechanism which controls that only one game thread can access data at a time, and forces other threads to just wait in their turn. Moreover, locking, unlocking, and managing the mutex waitlist is costly itself. And when a dozen of locks between couple of threads acquires 600 times per second it may become a massive overhead. If you have enough enthusiasm then performance profiler is what you looking for. I got best results with OProfile. But this may be a bit complicated on linux. I wish VS Code have a Performance Profiler from MSVS on Linux