Facetracking issue and way higher cpu usage since 1.0 release

[TheRealDadbeard]

So I was hunting some weird issue with your face tracking effects that occured in one game I played (the walking dead definitive edition) when I noticed that CPU usage is much higher in any version after 1.0 release from around 10% to 22%.

The other thing is and I have no idea why this happens is that when any of the facetracking effects are enabled and obs is recording/streaming the above mentioned game would have really bad freezes for whatever reason but ONLY while obs is recording. It's a bit less worse on 0.15.

GPU usage is not the issue, running on a 4070ti so NVENC is in use. I attached a log.

2026-02-05 21-54-33.txt

[ludolpif]

Hi,
To try to get more data on your case before xurei have a chance to analyze it:

• It seems the log is one with a run using Shadertastic 0.1.5, do you have also a log with 1.x for comparison?
• I am unsure to understand with the streaming and/or recording point
  • there is freeze in-game only if you have OBS recording in progress?
  • there is no freeze if you are streaming but not recording?
  • is the game reading it's file from same disk as OBS records the output video ?
• You have some other plugins loaded, which is fine, but may be there is a configuration we don't have imagined
  • could you detail a bit your Source/Scene configuration that is running while you have the troubles?
  • is there is multiple facetracking effects enabled, or using the result multiple times in one way or another?
  • what the simplest scene you can setup which still shows the troubles?

[edit]
In the log, I see a few places involving Shadertastic, notably one on a source clone. I don't really know which were is use when it goes bad, hint us on this.

21:54:40.909:     - source: 'CamWideBig' (source-clone)
21:54:40.909:         - filter: 'Shadertastic Filter' (shadertastic_filter)
[...]
21:54:40.910: - scene 'WebcamForNesting':
21:54:40.910:     - source: 'WebcamForNestingOnly' (scene) (appears twice on the dump)
21:54:40.910:         - filter: 'PatPat' (shader_filter)
21:54:40.910:         - filter: 'BonkSchrink' (shader_filter)
21:54:40.910:         - filter: 'ZoomTracking' (shadertastic_filter)
21:54:40.910:         - filter: 'PixelCamOnly' (pixel_art_plugin)
21:54:40.910:         - filter: 'Retro Effects 2' (obs_retro_effects_filter)
21:54:40.910:         - filter: 'ZoomWursti' (3d_effect_filter)
21:54:40.910:         - filter: 'ZoomWurstiMove' (move_value_filter)
21:54:40.910:         - filter: 'ZoomEQ' (move_value_filter)
21:54:40.910:         - filter: 'LaserEyes' (shadertastic_filter)
21:54:40.910:     - source: 'FartSmoke' (ffmpeg_source)

Hoping that will help!

[xurei]

Hi @TheRealDadbeard, thank you for this feedback.

The new version has been profoundly reworked, and the performance we measured while developing the plugin were actually much better. But as it is mostly hardware-dependent, I'm not necessarily surprised.

What is your CPU ? How many RAM do you have ?

"the above mentioned game would have really bad freezes for whatever reason but ONLY while obs is recording"

So you mean the game is fluid when you don't record ?
In that case, the first thing coming to my mind is that you GPU bandwidth may get bottlenecked. The LaserEyes effect is indeed quite expensive, add a GPU-intensive game and NVENC and maybe it can't keep up ?

[xurei]

Now, on the "why" it might be worse in 1.0 than 0.15 :
I changed some of the flags in the ONNX Runtime, and also updated it. I think the usual suspect is the spin control flag:

shadertastic/onnxmediapipe/src/models_provider.cpp

Line 44 in 4c076d6

ortThreadingOptions.SetGlobalSpinControl(true);

if (num_cores > 4) {
    // Enable spin control to reduce latency and jitter
    ortThreadingOptions.SetGlobalSpinControl(true);
}

Basically, it changes how the CPU "waits" for frame to render. The default setting is a sleep/activate pattern, which can lead to lags. This version uses a while(true) pattern. This increase the CPU cost but is supposed to reduce jitter and lag.

But since their seems to not always be the case, maybe this should be an advanced parameter.

[TheRealDadbeard]

Hi @TheRealDadbeard, thank you for this feedback.

The new version has been profoundly reworked, and the performance we measured while developing the plugin were actually much better. But as it is mostly hardware-dependent, I'm not necessarily surprised.

What is your CPU ? How many RAM do you have ?

"the above mentioned game would have really bad freezes for whatever reason but ONLY while obs is recording"

So you mean the game is fluid when you don't record ? In that case, the first thing coming to my mind is that you GPU bandwidth may get bottlenecked. The LaserEyes effect is indeed quite expensive, add a GPU-intensive game and NVENC and maybe it can't keep up ?

I'm on a 5800X3D with 32GB of RAM.

I think there is something wrong with the mentioned game, maybe it does some weird rendering thing and something in the plugin triggers something in the render queue. It's the only game I have encountered it with.

Other games with much higher GPU usage do not show this issue so it is only that one game

[xurei]

Interesting. That means we could use this game as a benchmarking tool 📝

If you're interested, I can make a build with a setting to disable the spin control, and see if it improves things.

[TheRealDadbeard]

Interesting. That means we could use this game as a benchmarking tool 📝

If you're interested, I can make a build with a setting to disable the spin control, and see if it improves things.

Yes i can totally test builds with that game, funny thing is i am not gpu limited, like that game does not reach 100% at all, but I can test some other games too and see which version is better