See sig below for my specs........................
....
From all my testing\checking the issues that we're seeing IMHO are simply symptoms of the cause (net variance spikes, GPU clock drops, GPU frametime variance spikes, etc) and the cause is somewhere within the front end interaction w\ the AH III game client software working thru the OS thru Dx thru the CPU thru the GPU to the screen on our computers. The vast occurances are centering thru the AH III Dx11 version which puts the emphasis on Dx11 API interaction w\ the AH III game client coding IMHO. The game software is the exact same software being used w\ both Dx API versions so this kinda eliminates the AH III game coding out of the picture for the most part IMHO which leaves the rest. Yes we can do some things to improve on the symptom end to lessen the severity of the cause (which is what most of us is\are actually doing) but still the actual cause for this issue is still there. The cause is what HTC is trying to find but so far they can't duplicate it on their computer configurations to then know what\where to check for in the game client code, but are keenly aware from all the reporting that the issue is real and is there somewhere.
Again this is my opinion but I think this is due to a bleedover function of the game coding to provide VR rendering to the VR headset to a conventional monitor even though we have the checkbox ticked to disable VR in the AH III client software (which both Dx9 and Dx11 see but somehow I think that the OS thru Dx11 is misinterpreting here and is sending VR-ish code thru to the GPU to render to a conventional monitor and causing the screen to freeze waiting for the double render to screen that isn't there causing the freeze\pause and this can happen at any instance). The rest just doesn't add up IMM as to date I haven't read or noticed where a VR player has seen or witnessed any of this freezing\pausing happening thru their headsets (VR monitor if you prefer) and they're using the Dx11 version of AH III exclusively......this runs up a red flag IMHO to really focus in this area of the coding to find a random argument out of place.....which may not be so obvious to find.
But HTC may have already done this ad nausem for all I know........
Usually what causes a GPU to slow down\stop work is due to the interrupt signal from the CPU to instruct the GPU that there is work to get from the system mem cache and to flip the finished rendered graphics frames to display in sequence somehow got delayed or lost so the GPU simply stops until it receives this interrupt from the CPU after it sent an interrupt signal to the CPU to ask for data....which also interrupts everything else (Internet packet sequencing for starters...). It is this process that has been noted by others and is referred to as a "CPU bottleneck" but the CPU may\may not be the actual cause for the signal delay\drop.....could also be software related between the application\game client thru the OS (where Dx is applied thru the OS according to the game coding instructions to method\process of use) and so the CPU has to wait for the instructions to actually finish it's work before it can answer the GPU's interrupt request and would\could be more acute on a more modern, faster computer configuration where these processes happen much faster making them more prone to idle wait time vs an older computer configuration where these processes are slower thus may happen to be more in sync and thus not as prone to see this happening.....depending upon the myriad of varibles in between the start to finish of a single process path.
Then when you add in a computer configuration in this mix this is what is making this very hard to track down as the VAST number of specific computer configurations being used will either AMPLIFY the issue or actually MASK the issue. Yep, just because you aren't seeing it occur on your particular computer configuration doesn't mean the issue isn't relevant.
I have witnessed this very same screen freezing\pausing in times past and have verified that it can simply be that a specific computer configuration can't adequately feed a more modern graphics card fast enough to keep the GPU working.....this is what can happen if graphics card upgrades are done w\o taking into account of the system it is being put into. Been there, done that.
But what is happening here now is more than simply a faster vid card being used in a slower computer configuration...............
If we all don't just give up and walk away the actual cause of this issue will be found and fixed..........but this will require some patience and some cooperation w\ HTC from us to some extent.........if we care about the product being delivered. They can't see what we're seeing because they can't duplicate it on their setups and they aren't in front of our setups to see it then look into our setups to identify if the cause is either driver-related, hardward-related or client-related.........
This is why I would like to ask HTC if they could list the specific computer configurations that they are using (w\o giving up any specific things that is proprietary to their business) as this info could be used by some of us out here to then look into our setups to see if there is something that we can then identify and bring to their attention to help them w\ this. If this is something that they would not like to do then no biggie, just a suggestion to try to help identify the cause to then bring about the resolution to the cause...............
What Randy1 is asking for has some merit............thus my response.
