Abstract: A system gives application developers and other users access to the real-time power consumption data of the hardware they are running on. In some embodiments, the system can provide an application programming interface (API). The system also provides a way for users to declare what is their maximum power limit they want to stay under. This could be combined as an OS setting that users, or cloud hardware managers, can enable, which will tell the application it is running in this power-capped mode. The application will then use the real-time power consumption data to see how close it is consuming to the specified cap. When the real-time power consumption data meets one or more criteria with respect to a specified cap, the application can dynamically adjust one or more operations to keep the power consumption of itself under the specified cap.

Abstract: Techniques for GPU self throttling are described. In one or more embodiments, timing information for GPU frame processing is obtained using a timeline for the GPU. This may occur by inserting callbacks into the GPU processing timeline. An elapsed time for unpredictable work that is inserted into the GPU workload is determined based on the obtained timing information. A decision is then made regarding whether to “throttle” designated optional/non-critical portions of the work for a frame based on the amount of elapsed time. In one approach the elapsed time is compared to a configurable timing threshold. If the elapsed time exceeds the threshold, work is throttled by performing light or no processing for one or more optional portions of a frame. If the elapsed time is less than the threshold, heavy processing (e.g., “normal” work) is performed for the frame.

Abstract: Techniques for GPU self throttling are described. In one or more embodiments, timing information for GPU frame processing is obtained using a timeline for the GPU. This may occur by inserting callbacks into the GPU processing timeline. An elapsed time for unpredictable work that is inserted into the GPU workload is determined based on the obtained timing information. A decision is then made regarding whether to “throttle” designated optional/non-critical portions of the work for a frame based on the amount of elapsed time. In one approach the elapsed time is compared to a configurable timing threshold. If the elapsed time exceeds the threshold, work is throttled by performing light or no processing for one or more optional portions of a frame. If the elapsed time is less than the threshold, heavy processing (e.g., “normal” work) is performed for the frame.

Abstract: Multiple vehicles being simulated at multiple devices are coordinated across a network as part of a shared gaming experience. Participating devices initially synchronize a time base using a designated host device. During game play, local devices simulate local vehicles. Local devices also produce predicted vehicle states for the local vehicles and transmit the predicted vehicle states to remote devices with regard to network latency. Remote devices in turn produce interpolated vehicle states from the predicted vehicles states and then render the vehicles using the interpolated vehicle states. Interpolation values may also be employed to maintain the synchronized time base. Additionally, the interpolations may be tuned, especially with respect to collisions, by a glancing collisions handler, a dragging collisions effectuator, and/or a remote vehicle damage agent.