The shader compilation gets higher priority because you'll get stutter otherwise if it doesn't finish quickly, i think. So it's probably preferable to loose a bit of average fps to finish the compilation in time. You can also try to reduce the number of compiler threads with dxvk.numCompilerThreads, i guess. On windows the nvidia d3d11 driver will almost always do better than DXVK anyways, so why even bother?

Well, for starters because this is a dx9 game and microsoft gimped that hard?
Secondly, I wasn't exactly paying attention to the frametimes graph, but I don't believe I had been getting any stuttering before (even because my test case is literally just the character and the camera looking forever at a steady scene).

I'm really not taking any issue with the fact that there is background compilation, it's truly nice that shaders can be compiled ahead of time now.
But it makes no sense for a convenience feature to become a hindrance (and it seems like these aren't just my 2c, given the commit above). Even if there actually was some super-eager game needing this compromise for their dear life, it should be assessed and documented to the very least.

A test case of a character staring at a wall is probably not the best to assess what is best for the actual experience when playing. Most game will stutter badly if the shader compilation isn't done and you actually move forward in the game and not just stare at a wall, so I think in most cases it is preferable to have 60 instead of 80 fps for a few minutes instead of having 200ms+ stutter spikes later. If you'd give all background compile threads low priority it might take forever to finish up in a cpu heavy game.

I see why I might have been luckier than most experiences.

Still, even if this was really a necessary tradeoff (not sure what happens when a modern game meets the dozen threads of modern cpus) I'm kinda appalled by that numCompilerThreads option. Why would I want to forcefully limit free real estate on my cpu, as opposed to just lowering the priority of the compiler?

not sure what happens when a modern game meets the dozen threads of modern cpus

What happens is that it chews through tens of thousands of shaders in like 30 seconds and this is a non-issue.

Why would I want to forcefully limit free real estate on my cpu, as opposed to just lowering the priority of the compiler?

If you had perf drops due to the compiler then there was no free real estate in the first place. Anyways, it will do the compilation only once and afterwards it will come from the shader cache, I don't see how it's such a terrible issue to have only 60 instead of 80 fps once for 2 minutes?

If you had perf drops due to the compiler then there was no free real estate in the first place

Except for the part where the average is usually 70-80% of cpu usage? Which is more than enough to even allow for some extra benchmarking on the side.

I don't see how it's such a terrible issue to have only 60 instead of 80 fps once for 2 minutes?

I'm not sure where I gave the impression this was the end of the world...
A 15% hit is not terrible, but it's not even great (and if not any it's totally counterintuitive to the claims in the docs).

The compiler threads are already running at low priority, you even linked the commit that did it.

This contradiction actually being the whole point of this issue?
If the new background compilation that was added was truly running with low priority, then the end results should be at least as good as what I get when I run 7-zip.

There's also high priority compiler threads but those are only used for shaders that are needed RIGHT NOW. The priority of those threads has to be high because the game literally pauses and waits for those shader to be compiled.

Yes.. then why is 1.10 just fine?
And I'm not just talking about stuttering (for as much as my limited walking around) but cpu usage too.
Even after having just updated my drivers, it was sitting there with the normal cpu headroom that it always had. This is why I'm very skeptical that the issue is with the "hot shaders" compilation.

There isn't really anything to do here and at this point, it would be wrong to tweak DXVK specifically for an old 2C/4T CPU.

Nobody mentioned any specific tuning... just to check if/when the ostensibly labelled "background threads" are actually that.

It's entirely possible that the Windows scheduler has some mechanism to prefer whatever process currently provides the focused window.

Window focus alone doesn't really help much, it's setting the low priority that makes all the difference in the world.
And yes, this odd behaviour was exactly making me doubt that your code was actually doing the "setting" to begin with.
But I just checked myself with process hacker.
And yes, I can confirm the two d3d9.dll threads with nvoglv32 in the stack that eventually disappear when compilation ends, are indeed set to "lowest" priority.

Since the game has also some "below normal" threads, and Windows has the pesky habit of randomly deciding a thread deserves a slightly higher dynamic priority than another, I didn't want to take any chance and I further forced the two novel dxvk threads to the lowest technically possible scheduling state (yes it turns out "lowest" isn't really the absolute low). That gained me perhaps 2FPS. But I was still more or less back to square one.

And then the craziest thing happened: I suspended the two threads altogether and I was still having a lower framerate.
And no, it's not even a possible matter of whatever the optimized shader loaded in the scene still having not been built. Because after compilation was complete in the Citadel level, I loaded Virmire. Then suspended again the threads as soon as possible, and loaded back the Citadel. And I was now getting 77FPS.
Which is not a bad result, by all means, yes. It's just 5 meagre frames per second short of my stupidly yearned target.
But just think to it: we are talking about "nothing being done about nothing relevant to the current scene or level" somehow causing overhead. With all due respect, something is rotten in denmark.

Because 1.10 doesn't start compiling shaders until they are used for rendering which results in a 50-200ms pause.

You can't tell me that I'm getting slowed down by "high priority compiler threads used for shaders that are needed RIGHT NOW" (which is what was always there to begin with, right?) and then pretend that 1.10 wasn't showing any issue because it was just too dumb to render anything that wasn't currently in-use for rendering.

You can enable the graphics pipeline library feature in the configuration file as well if you prefer stutter over a performance hit while pre-compiling shaders.

For the n-th time. I cannot praise enough the new feature.
I'm saying that something is wrong if *background* threads can somehow affect performance (unless of course we are talking about power/thermal throttling shenanigans, but this isn't the case here).

You don't have any idea on how a suspended thread could still affect the rest of your pipeline?
Because this is the voodoo that is happening here.

EDIT: cross that, in fact even after you kill the two threads... the performance hit is still there.
So, the problem is not even the compilation. It's as if just the "knowledge" (or the wait itself) that the thing is happening, was having some burdensome overhead.

Yes, with enableGPL=false there's no performance hit.

FWIW I also resolved into trying numCompilerThreads=1.. and the situation is just as equally laughable.
My cpu isn't fully loaded on any core, with a hair of gpu to spare too, yet I'm taking this dreaded 10fps hit.
(this procedure is also probably way more straightforward to reproduce and understand than my hair pulling above, but evidently I had rushed into thinking the only possibly unaccounted variable left were thread priorities - I apologize).

Yup, couldn't even get to load the world that I OOMed.

But I do have another interesting oddity.
If I use enableGraphicsPipelineLibrary=true, even with an already fully built cache and all, I'm approximately getting a 10fps hit which is an amount so suspiciously similar to the one I can see during compilation.

Pics speak better than a hundred words I guess (assuming my last note picked up your attention):

• auto
• true

Sorry, I had forgot only compiler set.

• truefull
• autofull
• comp13
• comp97
• comp100

Guess like this clue was also a dead end, given how close the 97% completion data seems to the final auto results.