No, you didn't. You prove it in your screenshot.
F*** my apologies there is a minor omission in that doc (I've pasted the wrong draft like an idiot) that has a major impact. I mentioned the resolution but not that these test were done on a 3090 (I mention it earlier in the thread but not on that page). If your card is weaker than that and since the process doesn't specify it like I thought, it's possible you followed it otherwise. Mea culpa. I blew it.
I did however mention you're going to need extremely high frame rates and 120 ain't that. Try to double or triple it by reducing the resolution.
Otherwise its you who have not explained it properly
It's exactly that, I am sorry. I've had SO many people fail to follow the process (usually followed by abusing me which is great fun) I tarred you with their brush. Jerk move. My bad.
Else, please confirm that hwinfo64 + Heaven + Limiter should not produce spikes? Because your post says otherwise claiming that no matter what framerate or what resolution the spikes will occur.
The delays will occur but you may not see them. Since I've wasted a ton of your time I owe you at least a proper explanation. I'll try and keep it plain-english-y.
What happens here is that the monitoring call which should be done in microseconds, takes several milliseconds. This is CPU time, not GPU time. FWIW, an earlier experiment showed me that this is extremely memory-speed critical. Taking my memory down from the usual 3800 flat 16s to 2133 with stock timings, made this issue extremely drastic and noticeable. Delays in the memory pipeline appear as delays in the cpu pipeline at a higher level of monitoring (because it's the CPU that's waiting on the data from RAM). So, given that at this point, the frame is being rendered by the CPU in order to take it's place at the end of a queue behind two other frames which have to be processed and displayed before the one that was delayed, that delay is eaten up by the buffer and you don't see it - BUT IT STILL ATE YOUR CPU IN THERE. IT JUST HID THE EVIDENCE. < Caps because this is super important otherwise it would be a non-issue, right?
So, we have the need to force a CPU-limited scenario, in order to see the CPU's behaviour. And we want to avoid a pre-rendering queue hiding the mess, right? So how? Frames, all of the frames. By reaching a massive framerate we have ensured the GPU is lightly loaded (or it wouldnt be able to get those frames - we're not trying to inducee a GPU-limited scenario here, so not too high!) and will attempt to render the frames at full tilt, thus loading up the CPU by emptying the prerender queue quickly, the loaded CPU exacerbating the issue, and the short queue exposing it.
SOOOO you need like 250+ FPS to see it. 300+ is recommended. The more, the better - so long as the system can realistically handle that load. This is why I went to the trouble of specifying 1600x900 in heaven, because at that res, with the 3090, you'll just be able to see it. So, aside from the fact I'd typed that stuff like a dozen times and didn't realise that this time I forgot to mention what card it was like an idiot..... Now you understand why nobody sees it. It's buried and hidden by mechanisms that are supposed to do exactly that, to give us smooth frametimes and high framerates. And this is why I'm being a stickler about following the process (which I screwed up and I apologise again) because if one does not (which sadly appears to be almost everyone almost all of the time) then you very easily end up in a scenario where you are not within the parameters where the bug is visible to you, for example by running 120FPS where your frametimes are too high to see it and too high to get the CPU mad, and you could probably easily run too low res and choke your system entirely and not see anything.
BTW, nvidias got the right info including the card type and much, much more than I've shared here, so that's not why they can't see it.
