Deriving Application-Specific Operating Parameters for Backwards Compatibility

Abstract

To provide a system and a method that provides backward compatibility for applications / titles designed for older versions of a computer system.SOLUTION: In a method 10 for deriving application-specific operating parameters during a testing phase in which an application runs on a legacy system, the application is run on a legacy system 12 and, for each code block 14, performance information is recorded or derived 16. Running the application may include, e.g., loading a capture and letting it run without input or playing through a specific area of a game. The method includes analyzing the performance information 18, and combining selected performance information to determine a set of performance characteristics 19, which may then be saved or transferred 20.SELECTED DRAWING: Figure 1A

Description

[Technical field]

[0001] [Priority claim] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 315,315, filed March 30, 2016, the entire contents of which are incorporated herein by reference. This application also claims the benefit of U.S. Provisional Patent Application No. 62 / 315,345, filed March 30, 2016, the entire contents of which are incorporated herein by reference. This application also claims the benefit of U.S. Provisional Patent Application No. 15 / 466,759, filed March 22, 2017, the entire contents of which are incorporated herein by reference. This application also claims the benefit of U.S. Provisional Patent Application No. 15 / 466,769, filed March 22, 2017, the entire contents of which are incorporated herein by reference.

[0002] Aspects of the present disclosure relate to the execution of computer applications on a computer system, and in particular to a system or method for providing backward compatibility to applications / titles designed for older versions of a computer system. [Background technology]

[0003] When a new computer architecture is released, it is desirable for applications written for previous versions of the architecture to run flawlessly on the new architecture. This capability is often referred to as "backward compatibility." Implementing backward compatibility involves emulating the target legacy device on the new host architecture, so that the new architecture can execute instructions of programs written for the legacy device. Computer architectures change over time to take advantage of technological advances in buses, clock speeds, processor architectures, caching, standards, and the like. When one computer architecture is replaced by a newer architecture, the older architecture becomes the so-called legacy architecture. Throughout the course of its development, software applications such as network protocols, user interfaces, audio processing, device drivers, graphics processing, messaging, word processors, spreadsheets, database programs, games, and other applications are written for the legacy architecture. Such legacy software still has value to its users even when they upgrade to the new architecture. Thus, there is a need to be able to run legacy software on the new architecture.

[0004] Differences in performance of hardware components between the new device and the legacy device may cause synchronization errors on the new device, which may cause the legacy application to crash or produce incorrect output when running on the new device architecture. Such performance differences may arise, for example, from differences in hardware architecture between the new device and the legacy device. Summary of the Invention

[0005] It is within this context that aspects of the present disclosure arise. [Brief description of the drawings]

[0006] [Figure 1A] FIG. 13 is a flow diagram illustrating the derivation of application specific operating parameters according to an aspect of the present disclosure. [Figure 1B] FIG. 13 is a flow diagram illustrating real-time adjustment of application-specific operating parameters according to an aspect of the present disclosure. [Figure 2A] 1 is a block diagram illustrating an example of a central processing unit (CPU) core that may be configured to operate in a backward compatibility mode, according to an aspect of the present disclosure. [Figure 2B] FIG. 2 is a block diagram illustrating an example of a possible multi-core architecture for a CPU, in accordance with an aspect of the present disclosure. [Diagram 3] FIG. 1 is a block diagram of a device having a CPU configured to operate in a backward compatibility mode, according to an aspect of the disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] [Introduction] To address issues that arise when running legacy applications on new devices due to differences in hardware behavior, the new hardware can be adapted to run the legacy applications.

[0008] During the testing phase, the legacy application is executed on the legacy device with the legacy architecture and performance information is collected. Examples of performance information include the number of ALU instructions or memory operations per unit time, and average parallel processing hardware scheduling unit (e.g., wavefront) occupancy or lifetime. Performance information may be measured directly (ALU and memory operations) by executing the game and application on the legacy device and reading counters. Alternatively, performance information may be derived from reading such counters, or other data output, as part of the measurement process. As an example of such derivation, average wavefront occupancy and lifetime may be derived from measurements when the wavefront starts and stops. The combined performance data for a particular application, e.g., a particular video game, is referred to herein as a performance characteristic for that application. The performance characteristics determined for an application during the testing phase may be used as a baseline for running the same application on a new system to ensure backward compatibility.

[0009] The performance of an application on the new device may be closely matched to the performance of the same application on the legacy device by adjusting the operating parameters of the new device. Examples of operating parameters include the clock frequency of the new device, the number of available general purpose registers (GPRs), instruction initiation rate, etc., among others. The application may be repeatedly run on the new system while adjusting its operating parameters to tune the application-specific performance characteristics. After a sufficient number of tests on the new system, one may analyze how the performance characteristics of the application on the new system converge as the operating parameters are changed. A new set of operating parameters may be generated based on the convergence analysis. This process may be repeated until the operating parameters are optimally set for the application on the new system. To further optimize, one may tune the execution of the new hardware to see if the application can run faster on the new hardware without causing it to fail.

[0010] [Determination of application-specific performance characteristics] FIG. 1A illustrates a method 10 for deriving application-specific operating parameters during a testing phase in which an application runs on a legacy system. The application is executed 12 on the legacy system and for each code block 14, performance information is recorded or derived 16. Running the application may include, for example, loading a capture and running it without input, or playing through a particular game area. The performance information includes key performance metrics and other performance information. Key performance metrics refer to a subset of performance information that is most important when the application runs on a new system. Key performance metrics are those that must be met when the application runs on new hardware. Examples of key performance metrics include, but are not limited to, frames per second (e.g., for video-intensive applications such as video games) and instructions per cycle (IPC) binned into program counter (PC) ranges.

[0011] Other performance information includes, but is not limited to, PC block residence, number of arithmetic logic unit (ALU) instructions issued per unit time (CPU and GPU), number of memory operations issued per unit time (CPU and GPU), average parallel processing hardware scheduling unit (e.g., wavefront, warp, or vector width) occupancy per unit time, average parallel processing hardware scheduling unit lifetime, average latency for memory operations, count of pixel outputs to render an object per unit time, and total active cycles during a frame (ALU count is a specific example of this).

[0012] The performance information may include values ​​read directly from counters or values ​​derived from such or other information, such as counting clock cycles between events during program execution. The performance information may be further analyzed at 18 and selected performance information may be combined to determine a set of performance characteristics 19, which may then be stored or transferred 20.

[0013] Certain performance information values ​​may be stored in dedicated processor registers that track information related to the execution of an application. Examples of such values ​​include, but are not limited to, the program counter and counter values ​​such as counters for memory cycles, arithmetic logic unit (ALU) cycles, and pixels, among others. The program counter (PC), also called the instruction pointer (IP) in Intel x86 and Itanium microprocessors, and sometimes called the instruction address register (IAR), or instruction counter, is a processor register that indicates where the computer is in its program sequence.

[0014] As mentioned above, certain other performance information may be derived indirectly, such as the average parallel processing hardware scheduling unit (e.g., wavefront, warp, or vector width) occupancy per unit time, the average parallel processing hardware scheduling unit lifetime, the average latency for memory operations, and the count of pixel outputs for rendering an object per unit time. By way of example and not limitation, instructions per cycle (IPC) may be derived by dividing the difference between the initial and final program counter values ​​by the number of clock cycles between the initial and final program counter values. Determining the average parallel processing hardware scheduling unit lifetime may also involve detecting the invocations and completions of such scheduling units and counting the clock cycles between them. Similarly, determining the average occupancy per unit time of a parallel processing hardware scheduling unit is a matter of recording invocations and completions for a given time window and determining how many times it is running on average at any given time within that time window.

[0015] The term "parallel processing scheduling unit" is used here as a generic term that encompasses several different terms used by different processor hardware manufacturers to describe the concept of the smallest executable unit for parallel processing of code. For example, in the context of GPUs, parallel processing threads are bundled into what are sometimes called "warps" (for NVIDIA hardware) or "wavefronts" (for AMD hardware) as the most basic unit of scheduling. The difference is primarily the number of threads grouped together. Other equivalent definitions include "smallest executable unit code that can run", or "a unit that processes simultaneously with a single instruction across all of the threads in it", or "smallest size of data that is processed in a SIMD manner". For CPU hardware, the most basic level concept of parallelism is often called "vector width" (e.g., when using SSE instructions on Intel and AMD processors). For simplicity, the term "wavefront" will be used here as a proxy for "parallel processing scheduling unit". All threads within a wavefront execute the same instructions in lockstep, the only difference being the data that is operated on by the instructions.

[0016] Other operational information may be derived from the operational register values ​​in several different ways. For example, IPC may be derived by sampling a counter that contains the total number of instructions being executed during program execution. As an example, this counter may be sampled every N cycles. An IPC value may be derived from the initial total executed instructions value (TIEi) and the subsequent value (TIEi+N) after N cycles from (TIEi+N-TIEi) / N. In practice, IPC values ​​for a given section of an application (e.g., a block of code) may be binned by the PC range for that particular section. Furthermore, each PC range within an application may therefore have different potential behaviors and correspondingly different IPC values. It is therefore useful to associate IPC values ​​with identified sections of program code, for example, by code block number.

[0017] PC block residence refers to the block of application code currently being executed, and may be more relevant to a CPU than a GPU since GPUs typically execute multiple code portions simultaneously. PC block residence may be derived by sampling the PC every N cycles and counting the number of times the samples fall within the same block of code.

[0018] The issue frequency of ALU or memory operations may be derived by detecting the issue of such operations and counting the number of such operations issued over a given time window. Similarly, a count of pixel outputs for rendering an object per unit time may be derived by counting the pixel outputs over a given time window. Latency, such as cache latency or memory operation latency, may be derived by detecting the issue and completion of cache read / write and / or memory access instructions and counting the clock cycles between issue and completion.

[0019] Recording / deriving performance information at 16 may include detecting busy waits. Busy waits are typically implemented as a short loop. From a counter's perspective, this will look like the PC is staying (and repeating) within a very small range, and there will be some type of memory read or IO read operation occurring each time through the loop. It is conceivable that the IPC may be large because of the loop, but more realistically the IPC is likely to be small since the time in the loop will be dominated by waiting for the results of the memory or IO operation to return. Busy waits may be detected by looking for times where the PC stays within a very small range, and that time is dominated by waiting for the memory or IO operation to complete. Busy waits tend to cause drift in IPC and other performance information measurements. Because the time spent in busy waits is unpredictable, measurements taken during busy waits may be removed from the performance information as part of the process of determining performance characteristics at 18. By doing so, subsequent processes of adjusting operating parameters will not be affected by the presence of busy waits.

[0020] Analyzing the recorded or derived performance information at 18 generally involves narrowing down the performance information to a useful set of performance characteristics 19 that broadly characterize the behavior of the running application, including, but not limited to, one or more key performance metrics and other performance information useful for subsequent determination of operating parameters, as described below.

[0021] The performance characteristic determination step 18 may determine which performance information values ​​are useful for adjusting an operating parameter, for example, by determining through multivariate analysis the correlation between key performance information values ​​and changes in the operating parameter when many different performance information values ​​may change in response to changes in a given operating parameter.

[0022] [Parameter adjustment process] 1B illustrates a method 30 of adjusting the execution of a legacy application to optimize operating parameters when the application runs on a new system. The new system may use the performance characteristics 19 to adjust one or more operating parameters in real time as the legacy application executes (32). For each code block 34, performance information is derived 36, for example as described above. If one or more key performance metrics are not within the bounds at 38, one or more operating parameters may be iteratively adjusted 40 until they are within the bounds. Once the key performance metrics are within the bounds at 38, the operating parameters may be updated 42 and optimized by further adjustments 40. The updated / optimized operating parameter data 43 may be stored or transferred 44.

[0023] The term "operational parameters" generally refers to aspects of application execution on the novel system that may be adjusted to affect performance information including key performance metrics. Examples of operational parameters may include, but are not limited to, clock frequencies for the CPU, GPU, or memory, instruction firing rates, ALU and / or memory operation firing rates, resources such as general purpose registers (GPRs), wavefront slots, read and store queue sizes, feature invalidation, cache parameters (e.g., cache size, number of ways, number of banks, etc.), wavefront firing rates, pixel output rates from the render backend, memory operation stalls.

[0024] Algorithm matching refers to using an algorithm from a legacy system architecture to perform an operation on a new system instead of a new and improved algorithm written for the new system architecture. An example of such algorithm matching is using a branch predictor for the legacy system to perform branch prediction on the new system. In this example, the algorithm matching parameters include parameters used in the legacy algorithm.

[0025] Other operational parameters may also include parameters related to resource limitations (e.g., as described in U.S. patent application Ser. No. 14 / 810,361, filed July 27, 2015, which is incorporated herein by reference), as well as parameters related to algorithm matching, feature disabling, and latency or throughput matching (e.g., as described in U.S. patent application Ser. No. 14 / 810,334, filed July 27, 2015, which is incorporated herein by reference).

[0026] The adjustment of the operational parameters at 40 may be simple, for example, setting the number of general purpose registers (GPRs) on the new hardware to the same number as the legacy hardware. Alternatively, the new hardware may use legacy algorithms for certain operations, or features of the new hardware may be disabled for operation of legacy applications. Execution may be adjusted to match the latency on the new system to that of the legacy hardware.

[0027] Adjusting the operating parameters may be more complicated due to architectural differences between the legacy and new hardware. In some cases, more resources may be allocated on the new hardware than on the original hardware, for example, by setting a slightly higher number of GPRs.

[0028] Table I below lists non-limiting examples of application specific operating parameters, how they are derived, and how they may be adjusted.

[0029] [Table 1]

[0030] The resulting updated operating parameters 43 may include a lower limit for each item of application-specific performance information, above which the performance metrics of the legacy application running on the legacy hardware are consistently met. With further testing on the new hardware, each item of application-specific performance information may further include an upper limit, above which the legacy application no longer functions properly or the key performance metrics of the legacy application are no longer met on the new system. The application-specific performance information may correspond to the information in Table II below.

[0031] [Table 2]

[0032] In the example shown in Table II, there is a set of upper and lower bounds for the performance information for each code block in the legacy program. This information can be used in subsequent operation of the legacy game on the new hardware. Such subsequent operation can proceed as described in FIG. 1B, with the new hardware adjusting execution to maintain the performance information between the minimum and maximum values.

[0033] The derivation and tuning of the operating parameters may be related to the hardware features shown in Figures 2A-2B and 3. Figure 2A shows a generalized architecture of a CPU core 100. The CPU core 100 typically includes a branch prediction unit 102 that attempts to predict whether a branch will be taken, and also (if taken) the branch's destination address. To the extent that these predictions are accurate, the efficiency of speculatively executed code will increase, and therefore more accurate branch predictions are highly desirable. The branch prediction unit 102 may include highly specialized subunits such as a return address stack 104 that tracks return addresses from subroutines, an indirect target array 106 that tracks the destinations of indirect branches, and a branch target buffer 108 and its associated prediction logic that tracks the past history of branches to more accurately predict their resulting addresses.

[0034] The CPU core 100 typically includes an instruction fetch and decode unit 110, which includes an instruction fetch unit 112, an instruction byte buffer 114, and an instruction decode unit 116. The CPU core 100 also typically includes several instruction-related caches and an instruction translation lookaside buffer (ITLB) 120. These may include an ITLB cache hierarchy 124 that caches virtual addresses to physical address translation information such as page table entries, page directory entries, etc. This information is used to translate the virtual addresses of instructions to physical addresses so that the instruction fetch unit 112 can load instructions from the cache hierarchy. By way of example and not limitation, program instructions may be cached according to a cache hierarchy that includes a level 1 instruction cache (L1 I-cache) 122 present within the core, and other cache levels 176 external to the CPU core 100. Using the physical address of the instruction, these caches are first searched for the program instructions. If the instructions are not found, they are loaded from the system memory 101. In some architectures, there may also be a micro-op cache 126 that contains decoded instructions, as described below.

[0035] Once program instructions are fetched, they are typically placed in an instruction byte buffer 114 awaiting processing by the instruction fetch and decode unit 110. Decoding can be a very complex process. It is difficult to decode multiple instructions each cycle, and there may be restrictions on instruction alignment or instruction type that limit the number of instructions that can be decoded in one cycle. The decoded instructions may be placed in the micro-op cache 126, depending on the architecture (if one exists on newer CPUs), so that the decode stage can be bypassed for subsequent use of the program instructions.

[0036] The decoded instructions are typically passed to other units for dispatch and scheduling 130. These units may use a retire queue 132 to track the state of instructions throughout the remainder of the CPU pipeline. Additionally, due to the limited number of general purpose and SIMD registers available in many CPU architectures, register renaming may be performed, where physical registers 140 are allocated to represent logical (also called architectural) registers as they are encountered in the stream of instructions being executed. The physical registers 140 may include a single instruction multiple data (SIMD) register bank 142 and a general purpose (GP) register bank 144, which may be significantly larger in size than the number of logical registers available on a particular CPU architecture, which may result in significant performance improvements. After register renaming 134 is performed, the instructions are typically placed in a scheduling queue 136, from which several instructions may be selected each cycle (based on dependencies) for execution by the execution units 150.

[0037] Execution units 150 typically include SIMD pipes 152 that perform a number of parallel operations on multiple data fields contained in 128-bit or larger SIMD registers contained in SIMD register bank 142, an arithmetic logic unit (ALU) 154 that performs a number of logical, arithmetic, and miscellaneous operations on the GPRs contained in GP register bank 144, and an address generation unit (AGU) 156 that calculates addresses where memory is to be stored or loaded. There may be multiple instances of each type of execution unit, and the instances may have different capabilities, for example, a particular SIMD pipe 152 may be capable of performing floating point multiply operations but not floating point add operations.

[0038] Stores and loads are typically buffered in a store queue 162 and a load queue 164, so that many memory operations can be executed in parallel. To support memory operations, the CPU core 100 usually includes several data-related caches and a Data Translation Lookaside Buffer (DTLB) 170. A DTLB cache hierarchy 172 caches virtual addresses to physical address translations, such as page table entries, page directory entries, etc. This information is used to translate virtual addresses of memory operations to physical addresses so that data can be stored in or loaded from system memory. Data is typically cached in a level 1 data cache (L1 D-cache) 174 that resides within the core, and in other cache levels 176 that are external to the core 100.

[0039] According to certain aspects of the disclosure, a CPU may include multiple cores. By way of example and not limitation, FIG. 2B illustrates an example of a possible multi-core CPU 200 that may be used in conjunction with aspects of the disclosure. Specifically, the architecture of the CPU 200 may include M clusters 201-1...201-M, where M is an integer greater than 0. Each cluster may have N cores 202-1, 202-2...202-N, where N is an integer greater than 1. Aspects of the disclosure include embodiments in which different clusters have different numbers of cores. Each core may include one or more corresponding dedicated local caches (e.g., L1 instruction, L1 data, or L2 caches). Each of the local caches may be dedicated to a particular corresponding core, in the sense that it is not shared with any other core. Each cluster may also include a cluster-level cache 203-1...203-M, which may be shared among cores in the corresponding cluster. In some embodiments, the cluster-level caches are not shared by cores associated with different caches. Additionally, CPU 200 may include one or more upper level caches 204, which may be shared between clusters. To facilitate communication between cores within a cluster, clusters 201-1...202-M may include corresponding local buses 205-1...205-M coupled to each of the cores and to the cluster-level cache for the cluster. Similarly, to facilitate communication between clusters, CPU 200 may include one or more upper level buses 206 coupled to clusters 201-1...201-M and to upper level cache 204. In some implementations, upper level bus 206 may also be coupled to other devices, such as GPUs, memory, or memory controllers. In yet other implementations, upper level bus 206 may be connected to a device level bus that is connected to various devices in the system. In yet other implementations, upper level bus 206 may couple clusters 201-1...201-M to upper level cache 204. The device-level bus 208 may couple the upper-level cache 204 to other devices, such as a GPU, memory, or a memory controller.By way of example and not limitation, an implementation having such a device level bus 208 may occur, for example, when the upper level cache 204 is an L3 for all CPU cores but not for GPU use.

[0040] In CPU 200, OS processing may occur primarily on one core or a subset of cores. Similarly, application level processing may occur primarily on a particular core or subset of cores. Individual application threads may be designated by the application to run on one core or a subset of cores. Because caches and buses are shared, the speed of processing by a given application thread may vary depending on the processing occurring by other threads (e.g., application threads or OS threads) running in the same cluster as the given application thread. Depending on the details of CPU 200, a core may be capable of executing only one thread at a time, or may be capable of executing multiple threads simultaneously ("hyper-threading"). In the case of a hyper-threaded CPU, the application may also specify which threads may run simultaneously with which other threads. The performance of a thread is affected by the specific processing performed by any other threads running on the same core.

[0041] 3, there is shown an illustrative example of a device 300 configured to operate in accordance with aspects of the present disclosure. According to aspects of the present disclosure, the device 300 may be an embedded system, a mobile phone, a personal computer, a tablet computer, a portable gaming device, a workstation, a gaming console, and the like.

[0042] The device 300 generally includes a central processing unit (CPU) 320, which may include one or more CPU cores 323 of the type shown in FIG. 1 and described above. The CPU 320 may include multiple such cores 323, in an arrangement such as that shown in CPU 200 of FIG. 2, and one or more caches 325. By way of example and not limitation, the CPU 320 may be part of an accelerated processing unit (APU) 310 that includes the CPU 320 and a graphics processing unit (GPU) 330 on a single chip. In alternative implementations, the CPU 320 and the GPU 330 may be implemented as separate hardware components on separate chips. The GPU 330 may also include two or more cores 332 and two or more caches 334, as well as (in some implementations) one or more buses to facilitate communication between the cores and caches and other components of the system. The buses may include an internal bus 317 for the APU 310, and an external data bus 390.

[0043] Device 300 may also include memory 340. Memory 340 may optionally include a main memory unit accessible to CPU 320 and GPU 330. CPU 320 and GPU 330 may each include one or more processor cores, e.g., a single core, two cores, four cores, eight cores, or more. CPU 320 and GPU 330 may be configured to access one or more memory units using an external data bus 390, and in some implementations it may be useful for device 300 to include two or more different buses.

[0044] The memory 340 may include one or more memory units in the form of integrated circuits providing addressable memory, e.g., RAM, DRAM, etc. The memory may include executable instructions configured to perform a method, such as the method of Fig. 5, upon execution for determining to operate the device 300 in a timing test mode when executing an application originally written for execution on a legacy CPU. Additionally, the memory 340 may include dedicated graphics memory for temporarily storing graphics resources, graphics buffers, and other graphics data for a graphics rendering pipeline.

[0045] CPU 320 may be configured to execute CPU code, which may include an operating system (OS) 321, or applications 322 (e.g., video games). The operating system may include a kernel that manages input / output (I / O) requests from software (e.g., applications 322) and converts them into data processing instructions for CPU 320, GPU 330, or other components of device 300. OS 321 may also include firmware, which may be stored in non-volatile memory. OS 321 may be configured to implement certain features that cause CPU 320 to operate in a timing test mode, as described in more detail below. CPU code may include a graphics application programming interface (API) 324 for issuing draw commands or calls to programs implemented by GPU 330 based on the state of applications 322. CPU code may also implement physics simulations and other functions. Portions of code for one or more of the OS 321 , applications 322 , or API 324 may be stored in memory 340 , a cache internal or external to the CPU, or a mass storage device accessible to the CPU 320 .

[0046] The device 300 may include a memory controller 315. The memory controller 315 may be a digital circuit that manages the flow of data to and from the memory 340. By way of example and not limitation, the memory controller may be an integral part of the APU 310, such as the example shown in FIG. 3, or may be a separate hardware component.

[0047] The device 300 may also include well-known support functions 350, which may communicate with other components of the system, for example, via a bus 390. Such support functions may include, but are not limited to, input / output (I / O) elements 352, one or more clocks 356, which may include separate clocks for each of the CPU 320, the GPU 330, and the memory 340, and one or more levels of cache 358, which may be external to the CPU 320 and the GPU 330. The device 300 may optionally include a mass storage device 360, such as a disk drive, a CD-ROM drive, a flash memory, a tape drive, a Blu-ray drive, etc., for storing programs and / or data. In one example, the mass storage device 360 ​​may accept a computer-readable medium 362, including a legacy application originally designed to run on a system with a legacy CPU. Alternatively, the legacy application 362 (or a portion thereof) may be stored in the memory 340 or may be partially stored in the cache 358.

[0048] The device 300 may also include a display unit 380 for presenting rendered graphics 382 prepared by the GPU 330 to a user. The device 300 may also include a user interface unit 370 for facilitating interaction between the system 100 and a user. The display unit 380 may be in the form of a flat panel display, a cathode ray tube (CRT) screen, a touch screen, a head mounted display (HMD), or other device capable of displaying text, numbers, graphical symbols, or images. The display 380 may display rendered graphics 382 that are processed according to various techniques described herein. The user interface 370 may include one or more peripherals, such as a keyboard, a mouse, a joystick, a light pen, a game controller, a touch screen, and / or other devices that may be used in conjunction with a graphical user interface (GUI). In some implementations, the state of the application 322 and the content on which the graphics are based may be determined at least in part by user input through the user interface 370, for example, when the application 322 includes a video game or other graphics-intensive application.

[0049] The device 300 may also include a network interface 372 to allow the device to communicate with other devices over a network. The network may be, for example, a local area network (LAN), a wide area network such as the Internet, a personal area network such as a Bluetooth® network, or other types of networks. Various of the components shown and described may be implemented in hardware, software, or firmware, or some combination of two or more thereof.

[0050] Table III below lists some non-limiting examples of how the specific hardware elements described above with respect to Figures 2A, 2B, and 3 can be used to determine performance information and corresponding operating parameters to adjust.

[0051] [Table 3]

[0052] Note that performance information recorded or derived when running a legacy application on a new device may not be able to meet or exceed the corresponding performance information for running the legacy application on the legacy device. For example, the average memory latency on the new device may be higher than the average memory latency measured on the legacy device regardless of how the operating parameters are adjusted. Knowing this type of performance information about the new system may be useful in adjusting the operating parameters, but should not be used in comparing the performance characteristics of applications running on the legacy and new devices. Only key performance metrics, such as but not limited to frames per second (FPS) and instructions per cycle (IPC), should be used in practice.

[0053] The process of adjusting operating parameters when an application runs on a new device to meet the key performance metrics of the same application running on a legacy device can be understood from the following example involving a video game. First, performance data is collected for the game running on the legacy device to determine its key performance metrics. The game is then run on the new device while adjusting the operating parameters of the new device. The performance of the new device can be measured by collecting the same performance information on the new device as was done when running the game on the legacy device, and then comparing the key performance metrics of the game running on the two devices. Although it may be desirable for the performance information for the new device to perfectly match the performance data from the legacy device, this may not be possible in practice. It is sufficient for the performance information on the new device to match the performance information on the legacy device as closely as possible. However, it is unacceptable for the key performance metrics on the new device to be worse than those on the legacy device, nor for an application or game to crash (typically due to synchronization issues) or produce erroneous output (for the same reasons).

[0054] In practical terms here, the first few times a game is run on a new device, the operational parameters will likely be set to be the same as on the legacy device. Once the game has been run enough on the new device and its operational parameters adjusted, the experience and data can be used to build heuristics that can be used for further games. The heuristics can be used to set initial values ​​for the operational parameters on the new device based on the performance characteristics of the game. The game will then be run on the new device and the operational parameters can be modified to better match the key performance metrics. All performance data measured on the new device can be used to help tune the operational parameters, not just the key performance metrics. Any adjustments made to the operational parameters can also be used to further refine the heuristics.

Claims

1. 1. A method for executing a legacy application on a non-legacy system, comprising: Setting operational parameters of the non-legacy system when executing the legacy application from one or more performance metrics and other performance information through a parameter tuning process for iteratively tuning operational parameters of the non-legacy system when executing the legacy application on the non-legacy system. A method comprising:

2. 2. The method of claim 1, wherein the parameter tuning process uses the one or more performance metrics determined from counting clock cycles between events during program execution.

3. 2. The method of claim 1, wherein the parameter tuning process uses the one or more performance metrics determined from values ​​stored in one or more dedicated processor registers that track information related to the execution of the application.

4. The method of claim 3 , wherein the value stored in the one or more dedicated processor registers comprises a counter value.

5. The method of claim 4 , wherein the counter value is a program counter value.

6. 5. The method of claim 4, wherein the counter value is a value of a counter for memory cycles, arithmetic logic unit (ALU) cycles, or a pixel.

7. The method of claim 1 , wherein the parameter tuning process uses the one or more performance metrics determined from a detected busy-weight.

8. The method of claim 1 , wherein the parameter tuning process uses the one or more performance metrics comprising frames per second.

9. 2. The method of claim 1, wherein the parameter tuning process uses the one or more performance metrics comprising instructions per cycle (IPC) binned into program counter (PC) ranges.

10. The method of claim 1, wherein the parameter tuning process iteratively adjusts the operating parameters of the non-legacy system until the one or more performance metrics are within a boundary range.

11. 2. The method of claim 1, wherein the parameter tuning process for iteratively tuning operating parameters of the non-legacy system includes adjusting an instruction firing rate until instructions per cycle (IPC) is within a bounded range.

12. 2. The method of claim 1, wherein the parameter tuning process for iteratively tuning operating parameters of the non-legacy system includes not allowing an arithmetic logic unit (ALU) operation every N cycles until an issue rate of ALU instructions is within a bounded range.

13. 2. The method of claim 1, wherein the parameter tuning process for iteratively tuning operating parameters of the non-legacy system includes not allowing a memory operation every N cycles until an issue frequency of the memory operations is within a bounded range.

14. 2. The method of claim 1, wherein the parameter tuning process for iteratively tuning operating parameters of the non-legacy system includes selectively allocating general purpose registers (GPRs) until an average wavefront occupancy or an average wavefront lifetime per unit time is within a bounded range.

15. 2. The method of claim 1, wherein the parameter tuning process for iteratively tuning the operating parameters of the non-legacy system includes throttle- ing a wave front activation rate until an average wave front occupancy rate or an average wave front lifetime per unit time is within a bound range.

16. 2. The method of claim 1, wherein the parameter tuning process for iteratively tuning operating parameters of the non-legacy system includes throttling a pixel output rate from a render backend of a GPU core until a number of pixel outputs for rendering an object per unit time is within a bounded range.

17. 2. The method of claim 1, wherein the parameter tuning process for iteratively tuning operational parameters of the non-legacy system includes stalling memory operations from completing until an average memory operation latency is within a bounded range.

18. 2. The method of claim 1, wherein the parameter tuning process for iteratively tuning operating parameters of the non-legacy system includes running a clock of the non-legacy system at different rates until a number of successful and unsuccessful branch predictions are within bounded ranges.

19. 2. The method of claim 1, wherein the parameter tuning process for iteratively tuning operating parameters of the non-legacy system includes matching a branch prediction algorithm of a legacy system until a number of branch prediction successes and failures are within bounded ranges.

20. 1. A system comprising a processor, a memory, and processor-executable instructions embodied in the memory, the instructions configured to implement a method of executing a legacy application on a non-legacy system, the method comprising: Setting operational parameters of the non-legacy system when executing the legacy application from one or more performance metrics and other performance information through a parameter tuning process for iteratively tuning operational parameters of the non-legacy system when executing the legacy application on the non-legacy system. Including, the system.

21. 1. A non-transitory computer readable medium having computer readable instructions embodied therein, the instructions configured to perform a method of executing a legacy application on a non-legacy system, the method comprising: Setting operational parameters of the non-legacy system when executing the legacy application from one or more performance metrics and other performance information through a parameter tuning process for iteratively tuning operational parameters of the non-legacy system when executing the legacy application on the non-legacy system. A non-transitory computer readable medium comprising:

Images