Dynamic runtime data collection and performance tuning

1. A method for dynamic performance monitoring and tuning a device while the device is executing an application, comprising:

collecting, by performance counters embedded in device hardware, data of a subset of performance events which are high-level performance events, wherein the high-level performance events indicate alternative causes for a performance bottleneck;

identifying, based on real-time analysis of the data, a first performance event among the high-level performance events for causing the performance bottleneck during the continuous execution of the application;

re-configuring, during the continuous execution of the application, the device hardware such that the same performance counters are used to collect additional data of a next subset of the performance events, wherein the next subset includes lower-level performance events that are under the first performance event in a hierarchical structure and indicate additional alternative causes more specific than the alternative causes; and

tuning the performance of the device with respect to a second performance event identified among the lower-level performance events during the continuous execution of the application,

wherein the performance events are organized in the hierarchical structure with the high-level performance events at a top of the hierarchical structure, and wherein the same performance counters operate at one level of the hierarchical structure at a time from the top toward bottom of the hierarchical structure.

2. The method of claim 1 , further comprising:

monitoring a plurality of indicators of workload change when executing the application; and

resetting data collection and execution of the application when one or more of the indicators indicate a workload change.

3. The method of claim 2 , wherein resetting the data collection further comprises:

restarting data collection when one or more of the indicators indicate a workload change.

4. The method of claim 2 , wherein the indicators include at least one of: a vertex count, a pixel count, and a shader context.

5. The method of claim 1 , wherein the high-level performance events includes compute unit utilization events and memory latency events.

6. The method of claim 1 , wherein the identifying and re-configuring are performed by an embedded software driver that runs in a kernel mode.

7. The method of claim 1 , wherein the identifying and re-configuring are performed by an embedded software daemon that runs in a user mode.

8. The method of claim 1 , wherein collecting the data further comprises:

resetting the performance counters in the device hardware;

configuring the performance counters to collect the data of the high-level performance events into a buffer space; and

retrieving the data from the buffer space after a polling interval.

9. A device to perform dynamic performance monitoring and tuning, comprising:

one or more processors operative to execute an application;

device hardware including performance counters operative to collect, during continuous execution of the application, data of a subset of performance events which are high-level performance events, wherein the high-level performance events indicate alternative causes for a performance bottleneck;

a diagnostics module coupled to the device hardware, wherein the diagnostics module is operative to identify, based on real-time analysis of the data, a first performance event among the high-level performance events for causing the performance bottleneck during the continuous execution of the application; and

a re-configuration module coupled to the device hardware, wherein the re-configuration module is operative to re-configure, during the continuous execution of the application, the performance counters such that the same performance counters are used to collect additional data of a next subset of the performance events, wherein the next subset includes lower-level performance events that are under the first performance event in a hierarchical structure and indicate additional alternative causes more specific than the alternative causes,

wherein the one or more processors are operative to: tune the performance of the device with respect to a second performance event identified among the lower-level performance events during the continuous execution of the application, and

wherein the performance events are organized in the hierarchical structure with the high-level performance events at a top of the hierarchical structure, and wherein the same performance counters operate at one level of the hierarchical structure at a time from the top toward bottom of the hierarchical structure.

10. The device of claim 9 , further comprising a workload monitoring module operative to:

monitor a plurality of indicators of workload change when executing the application; and

reset data collection and execution of the application when one or more of the indicators indicate a workload change.

11. The device of claim 10 , wherein the workload monitoring module is further operative to restart data collection when one or more of the indicators indicate a workload change.

12. The device of claim 10 , wherein the indicators include at least one of: a vertex count, a pixel count, and a shader context.

13. The device of claim 9 , wherein the high-level performance events includes compute unit utilization events and memory latency events.

14. The device of claim 9 , wherein the one or more processors are operative to execute an embedded software driver that runs in a kernel mode to perform operations of the diagnostic module and the re-configuration module.

15. The device of claim 9 , wherein the one or more processors are operative to execute an embedded software daemon that runs in a user mode to perform operations of the diagnostic module and the re-configuration module.

16. The device of claim 9 , wherein the one or more processors include at least one of a graphics processing unit (GPU) and a central processing unit (CPU).