Yes, I thought it could possibly be the SLI method, so I tried five different modes and still get the pause-and-play hesitations. You seem to be saying that petit-freeze and screen-pause are two different things, but they are the same thing to me.
What caused me to give up trying to configure the game to run without this problem was when I ran the game on a top end workstation system and still got the same events. The game runs great otherwise and looks amazing.
Hi Chalenge,
From all my testing I believe that they all are a result of the lower than normal CPU\GPU core loading due to the AHIII game client running under Dx11...in this aspect they are all caused by the same. As for the petite freezing I also was able to isolate this particular aspect to be more affected by the advent of Intel's CEIST being active (a symptom of the cause), which is also activated by low CPU core loading, but when I used CPU core affinity to reduce the amount of CPU cores available to be used w\ the game under Dx11 w\ CEIST enabled this also raised the CPU core loading on the CPU cores being used enough to stop CEIST from throttling the CPU core power\frequency which stopped the GPU micro hesitations from causing the petite freezes on my box as well (very noticeable thru the GPU frametiming graph line in MSI Afterburner as well as visually while in game). If I used 1 CPU core or more than 4 CPU cores the petite freezes came back but for different reasons but I could still see a slight difference in the GPU frametime graph line between 2 CPU cores being used vs 3 or 4 w\ the GPU frametime line being the cleanest when 2 CPU cores were being used.....which lines up w\ HTC's statement of the client being written to use 2 CPU cores. This tells me that the game threading is optimized on 2 highly loaded CPU cores and using more than 2 CPU cores starts to introduce unwanted CPU latency due to the OS wasting time parsing game threads across all these CPU cores which shows up at the GPU thru the frametime graph line. This testing has shown me the need for the AHIII game client to have CPU core affinity written into it to maintain game stability across modern platforms as CPU core counts are only gonna grow...........
But neither method has gotten the CPU core usage up enough under Dx11 to stop the screen pausing as from all my testing under the methods at my disposal I haven't recorded a screen pause occurring when the CPU core usage %, regardless of the number of CPU cores being used from 2 cores up to 6 (I have Hyperthreading disabled on my I7 5820K CPU), if the CPU core usage stays above 35% on the highest loaded CPU core while the game is running.....only when the CPU core usage drops below this mark is when a screen pause has occurred. This is the only data that I have found to be consistent w\ this happening on my box to date. But until I can get the AHIII game client running under Dx11 to consistently maintain CPU core loading to keep it consistently above this 35% mark to then prove that this IS the main issue can I make the call. So far I cannot make this happen on my end unless I reduce the CPU core usage to 1 CPU core then I've gotten everything else negative to start showing back up due to 1 CPU core w\o Hyperthreading enabled ain't gonna cut it running AHIII game client. Using 2 CPU cores the best I have gotten is 60%-70% but the game has to be very busy along w\ a high texture count map loaded as well or it won't stay there and will drop back below this mark. Haven't witnessed this occurring as soon as it lowers below 35%....have seen the CPU core usage be as low as 9% when a screen pause occurred but 34% is the highest recorded CPU core usage I've noted when a screen pause did occur thus I use 35% as the threshold for now.....................
So in short I agree w\ you on this but I believe that the true source is due to the lower than normal CPU core loading derived from the AHIII game client, which was optimized to run under Dx9, being ported to run under Dx11 since the VR coding was added to the client as when I've compared the recorded CPU AND GPU core loading of the AHIII game client being run on both Dx API's the difference is very large and noticeable in favor of Dx9 showing to load the CPU\GPU FAR more than Dx11 does thus I also believe this is why the AHIII client run under Dx9 runs w\o all these petite freezes\screen pauses showing up on my box.
All other items that we've all discovered, brought to the table are but symptoms of the central issue as this low CPU core loading can affect ALL the other devices operation as well and cause a domino effect.....not that the other devices don't need to be looked into. Since going thru all this I've found quite a medley of issues concerning my broadband equipment on my end that didn't help w\ the situation either so I've got some good out of doing all this on my end as well.
This is where I'm coming down on all this after the work I've expended into diagnosing this problem on my end.
Other than all this the game does run excellent on my box as well whether under Dx11 or Dx9.
Since shutting down CEIST in my UEFI all I see happening now is the screen pausing every once in a while...........
So as you I'm pretty much at my end of all this and will be playing AHIII under Dx9 going forward as I don't use a VR headset so am not wetted to using Dx11 exclusively but I really want to run the game under Dx11 due to the graphics performance that I've seen w\ my Fury X running under Dx11 vs Dx9 but the screen pausing gets very old and does interrupt game play.
But from discovering what I have noted concerning my set up I will also be setting the CPU core affinity to 2 CPU cores on my box when I do play going forward........
