Not claiming to understand this completely, but the same problem exists with Nvidia hardware and drivers.
Also, if it is not related to the AH3 client, wouldn't it be a common problem with other games and DX11? Is it?
Here is a snippet of my Fury X's vitals in which I captured a screen freeze occurance after I had reset MSI AB to record GPU usage% in real form instead of in unified form (simply put unified time is an avg of the GPU usage% real time graphing) so you can clearly see the GPU usage% going to as low as 0% quite frequently (very, very little to no GPU activity) while under an actual AHIII Dx11 gaming use. The screen pause is due to the AMD driver somehow attempting to put the GPU to sleep due to a lack of work for the GPU to do (why the GPU clock speed drop along w\ the GPU FPS drop along w\ the GPU frametiming spike) after a certain amount of time in milliseconds in which the GPU usage% stays at 0. Once the GPU receives some work the driver then wakes the GPU back up then the screen resumes again. Since the rest of the system is still functioning normally (the vid card and driver are as well) you do not get a .dmp file as the OS\AHIII hasn't detected a hard fault occurance. I believe this is also happening w\ Nvidia hardware as well as both use a GPU power\clock speed control scheme (AMD PowerTune\Nvidia GPU Boost) that calculates using driver fed info as to the graphics draw\rendering\AA levels being used and neither does a good job at GPU control when the graphics loads are light.............
Since resetting my MSI AB graphs to show GPU usage % in real time, EVERY screen freeze seen since then is ALWAYS initiated by the GPU usage dropping to 0% (you can see on the graph that the GPU is doing this a LOT). My vid card's Fiji GPU supports ULPS (ultra low power state) which will be invoked when the drivers detect very low GPU loads to save power. Most of the time this shows up when AMD cards are set up in Crossfire (puts the 2nd vid card to sleep) but this "could" have been in effect on my single vid card thus my test by shutting this down and then seeing that this didn't stop the freezes so this indicates to me that this issue is an issue w\ AMD's PowerTune GPU control (Nvidia has a similar GPU control scheme called GPU Boost) which is implemented at the hardware level of the GPU but is fed info thru the drivers so that it can perform it's calculations to "optimize" the GPU.
None of these GPU control schemes whether Nvidia or AMD were tuned to provide decent control when the GPU's are LIGHTLY loaded....only HEAVILY loaded. Since AHIII is using the latest graphics techniques (post processing that offloads the GPU of the heavy rendering\AA work is 1 of them) and is multithreaded to boot, especially when being ran thru Dx11 API, can take much better advantage of Dx11's multithreading capabilities thus can spread out this work much more effectively across multi-core CPU's and can take much better advantage of a GPU's ability to process graphics calls in parallel by breaking up game graphics draw\rendering\AA calls into many threads instead of staying single threaded, this can tend to reduce the necessary amount of CPU\GPU processing time needed to do the same amount of work being multithreaded using multi-cored hardware vs single threaded which cannot take advantage of multi-cored hardware. This is just 1 of the attributes that Dx11 API brings to the table over Dx9 API that can lend to what I'm seeing occur on my box. There are others as well.
It is this lower CPU\GPU loading while under an AHIII game load under Dx11 that is the source of all of this going on (I can say w\ a fairly high degree of accuracy that this is the issue on my box from all the testing that I have done and the evidence provided) and the severity of the issue will depend on the specific computer configuration that AHIII is being run on. This is MUCH more prevalent when the game is running under Dx11 vs Dx9. On my box when I run the very same AHIII game client software using the exact same game settings both in-game and driver level under Dx9 I see none of these issues happening at all.....which points even more specifically to the differences between how the 2 MS Dx API's are handling\processing the game threads (not the AHIII client software itself) that the vid card drivers are then interpreting to then instruct the GPU to process.....the GPU operating loads while running the same AHIII game client software are VERY different w\ Dx9 showing a much heavier CPU\GPU game load than when under Dx11. If the issue was the AHIII game client itself the same issues should show up regardless of which Dx API it ran under. This is not the case on my box.
This can only be really fixed thru the vid card drivers to better control the GPU when they are under light game loads. HTC "could" "fix" this themselves by coding the game to more heavily load the CPU\GPU but that is really counterproductive for a game developer to fix an issue that is really for the vid card driver engineers to address (this is what they, Nvidia & AMD, are actually doing for most of the Tier 1 game developers big game titles so that their games run smoothly on their hardware......but last I checked HTC isn't on either's preferred list to get driver stack development support to ensure that AHIII runs smoothly). So IOW's, not all is equal w\ other game coding and driver support under any Dx API, much less Dx11..........just as not all is equal w\ the computer platforms this game is being used on which can either expose or hide certain anomalies in all aspects of computing from the software developer thru to the user.
This is really a 2-way aspect to be taken into context............not just a 1-sided affair in reality. The result of all my testing has shown for me that this issue rests on the AMD driver engineers to solve for AHIII as it is currently being used w\ Dx11.......which may not happen. At least they can't say they weren't notified as I have sent in a bug notice to AMD concerning this game's issues running on their products\drivers and have gotten a return email that says that they have received it.................all I can do as a user at this point. I have effectively removed all other aspects on my end by either proving that a particular part isn't the cause OR have found other parts of my full system to be in need of either a readjust or a replacement (readjusted Windows Power Plan to eliminate the GPU stutters being caused by my CPU going into low clocks\power state due to low CPU game loads triggering the Intel CEIST to cut CPU clocks\power; replaced a faulty ADSL modem\router w\ a much better unit that now provides full Gigabit LAN speeds, retuned both computer's NIC's to take full advantage of this then rerouted a spare phone line to get our fax machine off the ADSL line so our ADSL line is now a fully dedicated line for all Internet access only.....includes AHIII).
The only item left to solve on my end now is this intermittent screen pausing concerning AHIII and the results of my testing has shown that this issue is not w\ HTC's AHIII client software per se.
All HTC has done is worked their AHIII game code to the point of maximum efficiency, especially under Dx11, that is now starting to show up these types of anomalies that IMHO are the result of lower than "normal" game CPU\GPU loading relative to the Dx API it is run under.
This graph I presented below is pretty telling from my POV....................
