I've been suffering from an issue with occasional dropped frames in AMS2 for as long as I can remember. The display rendering stops for a fraction of a second and then continues normally, which is very distracting when racing in VR. It could be 10 minutes or 2 hours between glitches so it's been very difficult to pin down. I have finally managed to capture a event trace of it, which is shown below: The blue spikes at the top of the graph show the GPU utilisation from AMS2 rendering each frame. The left and right of this graph show normal rendering spikes, which are 11ms apart for the 90fps my VR headset uses. The gap in the middle of the graph shows where it has stopped rendering for ~245ms, causing the problem I'm experiencing. Most of the remaining rows in the image show the work being peformed by each worker thread inside the AMS2 process, which is filled with colour whenever the thread is active. Most threads have a small amount of work to do each frame, so there are regular patterns of narrow lines rather than solid blocks. In the centre section of about half the threads is a gap matching the gap in the GPU graph above. So AMS2 has stopped a lot of its processing during this time. At the bottom of the image is the Steam main process with one of the threads highlighted in yellow. This thread is busy for almost exactly the same time period that AMS2 has stopped, which seem very suspicious! Most of the AMS2 threads are blocked waiting for other AMS2 threads to finish processing, and one of them is waiting on an event to be set by the yellow thread in the Steam process. Here are the (inverted) call stacks showing this delay: The stack on the left is the AMS2 side, which has called into steamclient64.dll. This is probably calling a Steamworks API interface that was returned from steam_api64.dll. During the call it hits a WaitForSingleObjectEx call, which blocks the thread waiting on an event. The stack on the right shows the yellow thread in Steam, which does some processing and then calls SetEvent to indicate it is done, releasing the waiting AMS2 thread. The column of figures on the right shows that one of the waits in the current graph time period took 248ms to complete, which matches the length of the glitch. So it looks like AMS2 is using the Steamworks API from a thread that won't tolerate Steam being slow to respond. I can't currently see the function it's calling due to lack of public symbols in the trace. The other 4 calls made in the graph time window took only 42us on average so it's usually very fast to respond, but it only takes one slow call to interrupt the game experience. I could do some further digging but it's probably easier for Reiza to debug directly, since they know what they're calling from where and have full symbols.
Its a shame that such an informative post has no acknowledgement from Reiza. I'd love the intermittent lag spikes to be a thing of the past. Really enjoying the game otherwise.
Welcome to the forums No acknowledgement doesn't mean they didn't see it or put it on their to-do list, it's always been like that. It would be a lot of time spent on acknowledging issue reports across the whole forum that can be spent better.
Though such a highly technical and detailed post that was obviously made by a developer could well see a brief acknowledgment to make sure it will not be forgotten into oblivion.
@CrimsonEminence Sorry to at you directly, but you were helpful drawing attention to another issue to the devs. Perhaps you could give some feedback here, even if just to say they have seen the original post. The hitching issue really is reducing enjoyment of the game and hasn't gone away in 1.5
