AUTOMATED DATA-DRIVEN SYSTEM TO OPTIMIZE OVERCLOCKING

A processing device includes an automated overclocking system and a processor. The automated overclocking system is data-driven and includes an inference engine that executes a machine learning model configured to generate a first output based on a current configuration of the processing device. The first output includes a first set of overclocking parameters. The processor is configured to adjust one or more operating characteristics of at least one component of the processing device based on the first set of overclocking parameters.

BACKGROUND

Overclocking allows the operating speed of a processing unit, such as a central processing unit (CPU) or a graphics processing unit (GPU), to be increased. For example, a manufacturer typically establishes a default clock rate for a processing unit based on the processing unit's physical limitations. This standard clock rate provides a consistent time period used throughout the processing unit and determines the rate that operations are performed. The clock rate of the processing unit can be increased, i.e., overclocked, beyond the standard clock rate to increase the processing unit's performance. The processing unit's operating voltage can also be increased as part of the overclocking process to maintain operational stability at accelerated speeds. Although overclocking has the benefit of increased performance, the risk of the processing unit becoming unreliable or failing also increases.

DETAILED DESCRIPTION

Overclocking of a processing unit, such as a CPU or a GPU, typically involves increasing the processing unit's standard clock rate. The operating voltage of the processing unit can also be increased to provide stability while operating at the resulting higher clock rate. End-users generally have two options for overclocking a processing unit, manual overclocking and automated overclocking. In manual overclocking, the user provides specified overclocking parameters, such as clock rate/frequency and voltage settings. However, as the user-specified parameters may be too aggressive for the processing unit, manual overclocking often increases the risk of thermal/power throttling, system instability, or system failures including timeout detection and recovery (TDR) events, kernel-level failures, hard/soft hangs, system shutdowns, and the like.

In automated overclocking, a heuristic approach based on trial-and-error is typically used to determine a set of conservative parameters that are provided to the user. For example, a suite of pre-defined light workloads are executed in the background and the overclocking ceiling is iteratively increased until a failure is reached, at which point the trial-and-error process reverts to the last stable overclocking ceiling. However, the trial-and-error approach is time intensive, and iteratively increasing the overclocking ceiling until reaching a failure can result in TDR events or system crashes, which leads to a poor user experience. Also, the algorithm(s) implemented by the heuristic approach typically provides a very conservative estimate for a safe overclocking ceiling, and does not generate an optimal set for real world workloads when overclocking is enabled. If the workload used to determine the setting is not comprehensive enough, this may yield a “false” sense of security with high clocks, while a different workload that touches this critical path will cause an issue. In such scenarios, the end user will not be able to achieve the maximum performance (e.g., high frame rates) in some real-world workloads. Moreover, the resulting overclocking ceiling is determined once and set for all workloads so that, for a given machine, each workload is subject to the same overclocking ceiling (i.e., a “static ceiling”). Stated differently, the overlocking settings determined by most automated overlocking processes are global and usually cannot be fine-tuned for a specific workload, including run-time conditions such as temperature.

Accordingly, the present disclosure describes implementations of systems and methods for automated data-driven optimization of overclocking that address the problems detailed above associated with manual and automated overclocking. In at least some implementations, an automated overclocking system implements one or more techniques to select the optimal overclocking ceiling for each user system (client) using a data-driven model. Unlike other automated overclocking approaches that are based on trial-and-error, the automated overclocking system described herein offers an improved user experience by minimizing the risk of system crashes and instabilities. For example, the overclocking parameters determined by the automated overclocking system are not pre-defined. Instead, the overclocking parameters are adapted to the end user's specifications and dynamically adjusted based on the workloads. The dynamic overclocking ceiling provided by the automated overclocking system is advantageous for the current moment-in-time state/configuration of the user system since the ceiling can account for influential real-time parameters, such as temperature.

In at least some implementations, the data-driven model is trained on different user system configurations and workload characteristics such that optimal overclocking settings/parameters are predicted using information aggregated across system configurations and workload characteristics. Stated differently, the automated overclocking system is able to determine optimal overclocking parameters for multiple user systems even if their system configurations and workload characteristics differ from each other. In at least some implementations, the overclocking parameters determined for a specified user system are optimized with respect to stability, power, performance, performance-per-watt, a combination thereof, or the like, which provides an improved user experience by avoiding (or at least minimizing) TDRs, system instabilities, and system crashes while setting the clocks.

The techniques described herein for data-driven optimization of automated overlocking, are, in different implementations, employed at any of a variety of devices that include components (e.g., CPUs, GPUs, accelerated processing units (APUs), processor cores, compute units, and the like) capable of being overclocked.FIG.1is a block diagram of one such example device100(also referred to herein as processing device100) according to some implementations. It is noted that the number of components of the processing device100varies from implementation to implementation. In at least some implementations, there is more or fewer of each component/subcomponent than the number shown inFIG.1. It is also noted that the processing device100, in at least some implementations, includes other components not shown inFIG.1. Additionally, in other implementations, the processing device100is structured in other ways than shown inFIG.1. Also, components of the processing device100are implemented as hardware, circuitry, firmware, software, or any combination thereof. In some implementations, the processing device100includes one or more software, hardware, circuitry, and firmware components in addition to or different from those shown inFIG.1.

In at least some implementations, the processing device100includes, for example, a computer, a gaming device, a server, a handheld device, a set-top box, a television, a mobile phone, a tablet computer, a wearable computing device, or the like. The processing device100, in at least some implementations, includes one or more central processing units (CPU)102and one or more accelerated processing units (APUs), such as a graphics processing unit (GPU)104. Other examples of an APU include any of a variety of parallel processors, vector processors, coprocessors, general-purpose GPUs (GPGPUs), non-scalar processors, highly parallel processors, artificial intelligence (AI) processors, inference engines, machine learning processors, other multithreaded processing units, scalar processors, serial processors, or any combination thereof. The CPU102, in at least some implementations, includes one or more single-core or multi-core CPUs. In various implementations, the GPU104includes any cooperating collection of hardware and or software that perform functions and computations associated with accelerating graphics processing tasks, data-parallel tasks, nested data-parallel tasks in an accelerated manner with respect to resources such as conventional CPUs, conventional graphics processing units (GPUs), and combinations thereof.

In the implementation ofFIG.1, the CPU102and the GPU104are formed and combined on a single silicon die or package to provide a unified programming and execution environment. This environment enables the GPU104to be used as fluidly as the CPU102for some programming tasks. In other implementations, the CPU102and the GPU104are formed separately and mounted on the same or different substrates. It should be appreciated that processing device100, in at least some implementations, includes more or fewer components than illustrated inFIG.1. For example, the processing device100, in at least some implementations, additionally includes one or more input interfaces, non-volatile storage, one or more output interfaces, network interfaces, and one or more displays or display interfaces.

As illustrated inFIG.1, the processing device100also includes a system memory106, an operating system (OS)108, a communications infrastructure110, one or more applications112, a clock generation unit114, power supply circuitry116, and a cooling system,118. Access to system memory106is managed by a memory controller (not shown) coupled to system memory106. For example, requests from the CPU102or other devices for reading from or for writing to system memory106are managed by the memory controller. In some implementations, the one or more applications112include various programs or commands to perform computations that are also executed at the CPU102. The CPU102sends selected commands for processing at the GPU104. The operating system108and the communications infrastructure1010are discussed in greater detail below.

Within the processing device100, the system memory106includes non-persistent memory, such as dynamic random-access memory (not shown). In various implementations, the system memory106stores processing logic instructions, constant values, variable values during execution of portions of applications or other processing logic, or other desired information. For example, in various implementations, parts of control logic to perform one or more operations on CPU102reside within system memory106during execution of the respective portions of the operation by CPU102. During execution, respective applications, operating system functions, processing logic commands, and system software reside in system memory106. Control logic commands that are fundamental to operating system108generally reside in system memory106during execution. In some implementations, other software commands (e.g., a set of instructions or commands used to implement a device driver122) also reside in system memory106during execution of processing device100.

The clock generation unit114, in at least some implementations, includes one or more timing devices used to control the clock frequency sent to various components of processing device100. In one example, the clock generation unit114is capable of generating different frequencies for different groups of components in, including generating different (independent) frequencies for the various “cores” of the CPU102, the APU,104, a combination thereof, or the like. The power supply circuitry116supplies power (i.e., voltage) to the various components of the processing device100. The cooling system118is coupled to the CPU102, the GPU104, a combination thereof, or the like. When present, the cooling system118is used to control the temperature(s) of the CPU102, the GPU104, and the like. In at least some implementations, the cooling system118includes one or more fans for circulating and exhausting air, a liquid circulating system, a combination thereof, or the like. The cooling system118regulates, in at least some implementations, regulates only for one or more of the CPU102or GPU104, while in other implementations, the cooling system118regulates temperatures for the entire processing device100.

The input-output memory management unit (IOMMU)124is a multi-context memory management unit. As used herein, context is considered the environment within which the kernels execute and the domain in which synchronization and memory management is defined. The context includes a set of devices, the memory accessible to those devices, the corresponding memory properties, and one or more command-queues used to schedule execution of a kernel(s) or operations on memory objects. The IOMMU124includes logic to perform virtual to physical address translation for memory page access for devices, such as the GPU104. In some implementations, the IOMMU124also includes, or has access to, a translation lookaside buffer (TLB) (not shown). The TLB is implemented in a content addressable memory (CAM) to accelerate translation of logical (i.e., virtual) memory addresses to physical memory addresses for requests made by the GPU104for data in system memory106.

In various implementations, the communications infrastructure110interconnects the components of the processing device100. Communications infrastructure110includes (not shown) one or more of a peripheral component interconnect (PCI) bus, extended PCI (PCI-E) bus, advanced microcontroller bus architecture (AMBA) bus, advanced graphics port (AGP), or other such communication infrastructure and interconnects. In some implementations, communications infrastructure110also includes an Ethernet network or any other suitable physical communications infrastructure that satisfies an application's data transfer rate requirements. Communications infrastructure110also includes the functionality to interconnect components, including components of the processing device100.

A driver, such as device driver122, communicates with a device (e.g., GPU104) through an interconnect or the communications infrastructure110. When a calling program invokes a routine in the device driver122, the device driver122issues commands to the device. Once the device sends data back to the device driver122, the device driver122invokes routines in an original calling program. In general, device drivers are hardware-dependent and operating-system-specific to provide interrupt handling required for any necessary asynchronous time-dependent hardware interface. In some implementations, a compiler126is embedded within device driver122. The compiler126compiles source code into program instructions as needed for execution by the processing device100. During such compilation, the compiler126applies transforms to program instructions at various phases of compilation. In other implementations, the compiler126is a standalone application. In various implementations, the device driver122controls operation of the GPU104by, for example, providing an application programming interface (API) to software (e.g., applications112) executing at the CPU102to access various functionality of the GPU104.

The CPU102includes (not shown) one or more of a control processor, field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or digital signal processor (DSP). The CPU102executes at least a portion of the control logic that controls the operation of the processing device100. For example, in various implementations, the CPU102executes the operating system108, the one or more applications112, and the device driver122. In some implementations, the CPU102initiates and controls the execution of the one or more applications112by distributing the processing associated with one or more applications112across the CPU102and other processing resources, such as the GPU104.

The GPU104executes commands and programs for selected functions, such as graphics operations and other operations that are particularly suited for parallel processing. In general, GPU104is frequently used for executing graphics pipeline operations, such as pixel operations, geometric computations, and rendering an image to a display. In some implementations, GPU104also executes compute processing operations (e.g., those operations unrelated to graphics such as video operations, physics simulations, computational fluid dynamics, etc.), based on commands or instructions received from the CPU102. For example, such commands include special instructions that are not typically defined in the instruction set architecture (ISA) of the GPU104. In some implementations, the GPU104receives an image geometry representing a graphics image, along with one or more commands or instructions for rendering and displaying the image. In various implementations, the image geometry corresponds to a representation of a two-dimensional (2D) or three-dimensional (3D) computerized graphics image.

In various implementations, the GPU104includes one or more compute units, such as one or more processing cores128(illustrated as128-1and128-2) that include one or more single-instruction multiple-data (SIMD) units130(illustrated as130-1to130-4) that are each configured to execute a thread concurrently with execution of other threads in a wavefront by other SIMD units130, e.g., according to a SIMD execution model. The SIMD execution model is one in which multiple processing elements share a single program control flow unit and program counter and thus execute the same program but are able to execute that program with different data. The processing cores128are also referred to as shader cores or streaming multi-processors (SMXs). The number of processing cores128implemented in the GPU104is configurable. Each processing core128includes one or more processing elements such as scalar and or vector floating-point units, arithmetic and logic units (ALUs), and the like. In various implementations, the processing cores128also include special-purpose processing units (not shown), such as inverse-square root units and sine/cosine units.

Each of the one or more processing cores128executes a respective instantiation of a particular work item to process incoming data, where the basic unit of execution in the one or more processing cores128is a work item (e.g., a thread). Each work item represents a single instantiation of, for example, a collection of parallel executions of a kernel invoked on a device by a command that is to be executed in parallel. A work item executes at one or more processing elements as part of a workgroup executing at a processing core128.

The GPU104issues and executes work-items, such as groups of threads executed simultaneously as a “wavefront”, on a single SIMD unit130. Wavefronts, in at least some implementations, are interchangeably referred to as warps, vectors, or threads. In some implementations, wavefronts include instances of parallel execution of a shader program, where each wavefront includes multiple work items that execute simultaneously on a single SIMD unit130in line with the SIMD paradigm (e.g., one instruction control unit executing the same stream of instructions with multiple data). A scheduler132is configured to perform operations related to scheduling various wavefronts on different processing cores128and SIMD units130and performing other operations to orchestrate various tasks on the GPU104.

To reduce latency associated with off-chip memory access, various GPU architectures include a memory cache hierarchy (not shown) including, for example, L1 cache and a local data share (LDS). The LDS is a high-speed, low-latency memory private to each processing core128. In some implementations, the LDS is a full gather/scatter model so that a workgroup writes anywhere in an allocated space.

The parallelism afforded by the one or more processing cores128is suitable for graphics-related operations such as pixel value calculations, vertex transformations, tessellation, geometry shading operations, and other graphics operations. A graphics processing pipeline134accepts graphics processing commands from the CPU102and thus provides computation tasks to the one or more processing cores128for execution in parallel. Some graphics pipeline operations, such as pixel processing and other parallel computation operations, require that the same command stream or compute kernel be performed on streams or collections of input data elements. Respective instantiations of the same compute kernel are executed concurrently on multiple SIMD units130in the one or more processing cores128to process such data elements in parallel. As referred to herein, for example, a compute kernel is a function containing instructions declared in a program and executed on an accelerated processing device (APD) processing core128. This function is also referred to as a kernel, a shader, a shader program, or a program.

In at least some implementations, the processing device100further includes an automated overclocking (OC) system120. It should be understood that althoughFIG.1shows the automated OC system120as being implemented as a standalone component of the processing device100, in at least some implementations, the automated OC system120is implemented by one or more of the processing units, such as the CPU102or the GPU104, or is comprised of one or more one or more components of the processing device100, such as those shown inFIG.3. As described in greater detail below, the automated OC system120performs data-driven overclocking that is optimized for a current stat (e.g., configuration) of the processing device100. The automated OC system120determines, using a data-driven model, overclocking parameters that are adapted to the configuration of the processing device100and also dynamically adjusted based on the workloads of the processing device100.

For example,FIG.2shows an example of a clock domain200, which includes a default clock domain202and a overclocking domain204. The default clock domain202includes minimum default clock rate206and a maximum default clock rate208for a component (e.g., CPU102, GPU104, or memory106) of the processing device100set by the manufacturer. The overclocking domain204includes clock rates that are above the default clock rates set by the manufacturer. A conservative overclocking domain210applies overclocking parameters that improve performance of the component being overclocked with less risk of system instability and failure, whereas an aggressive overclocking domain212applies overclocking parameters that improve the performance of the component over the conservative overclocking domain210but also increases the risk of system instability and failure. However, the conservative overclocking domain210and the aggressive overclocking domain212usually apply a clock rate that is under a maximum overclocked clock rate214. As described above, conventional automated overlocking mechanisms typically identify the maximum “safe” overclocking ceiling216at the border of the conservative overclocking domain210and the aggressive overclocking domain212. However, although this ceiling216is safe (i.e., less risk of system instability and failure), it is not necessarily optimal for the device. In contrast, the automated overclocking system120described herein provides a user with the option of selecting either the conservative overclocking domain210or the aggressive overclocking domain212and uses one or more data-driven models to optimize the target overclocking ceiling (e.g., optimized conservative OC ceiling218or optimized aggressive OC ceiling220) according to the configuration of the processing device100and the current workloads of the processing device100. In at least some implementations, the overclocking parameters are also optimized with respect to stability, power, performance, performance-per-watt, a combination thereof, or the like. The automated OC system120, in at least some implementations, applies the optimized overclocking parameters to, for example, adjust the clock rate supplied by the clock generation unit114to one or more components (e.g., CPU102, GPU104, or memory106) of the processing device100, adjust power budgets and the power supplied by the power supply circuitry116, adjust the cooling settings (also referred to herein as thermal management settings) of the cooling system118, adjust memory settings, a combination thereof, or the like.

FIG.3is a block diagram illustrating one example of a high-level overview of the automated OC system120. In this example, the automated OC system120includes at least one processor302(e.g., one or more of the CPU102or GPU104ofFIG.1, APUs, or any other processing or coprocessing units with overclocking capabilities), a user interface304, an operating system306(e.g., the OS108ofFIG.1), a processor software interface308, and a prediction unit310. In at least some implementations, the user interface304is a graphical or non-graphical user interface presented to the user of the processing device100that presents various options to the user associated with the overclocking process performed by the automated OC system120. Stated differently, the user interface304allows the user to interact with the automated OC system120. The user enables, disables, and fine tunes the overclocking of one or more device components by providing user-specified OC parameters301through the user interface304. For example, the user selects a conservative overclocking domain option or an aggressive overclocking domain option presented in the user interface304. The conservative overclocking domain option configures the automated OC system120to provide optimized overclocking ceiling218within the conservative overclocking domain210, whereas the aggressive overclocking domain option configures the automated OC system120to provide an optimized overclocking ceiling220within the aggressive overclocking domain212. As such, the user is able to choose to have more conservative overlocking parameters applied to the device component(s) for less intense workloads or have more aggressive overclocking parameters applied for more intense workloads, thereby allowing the user to balance the risk of system failures or instability with potential performance gains. In at least some implementations, the user-specified OC parameters301indicate additional user overclocking preferences, such as optimizing the performance-per-watt of the processing device100.

In at least some implementations, the OS306(or another component) obtains input, such as system information303, to be used by the automated OC system120for determining optimized parameters for overclocking one or more components of the processing device100. The system information303, in at least some implementations includes static macro-level features that are relatively static and are not influenced by applications executing on the processing device100. Examples of the system information303include one or more of system-related configurations312, workload characteristics314, hardware specifications316. The system-related configurations312include configuration information related to the CPU102and the GPU104(e.g., the current clock rate, the current supplied power (e.g., voltage), and the like), the system memory106, the current display settings, the graphics and display capabilities, chipset information, the current system temperature, the current power settings, the current settings of the cooling system118, the capabilities of the cooling system118, a combination thereof, or any other relevant information that can be used as input to (or output from) the prediction unit310described below. The workload characteristics314include any information related to the current or expected workload of the processing device100, such as current processing/compute unit (e.g., CPU, GPU, processing core, etc.) utilization, user mode driver information, types of application currently executing or installed on the processing device100, and the like. The workload characteristics314, in at least some implementations, are used as input to the prediction unit310for fine-tuning the overclocking optimization process based on real world use cases. The hardware specifications316include information such as CPU/GPU model information, overclocking support, core count, base clock speed, thermal design power (TPD), and other specification and capability information.

The processor software interface308, in at least some implementations, refers to drivers, such as kernel mode, user mode, and firmware components, as well as software development kit (SDK) libraries. The processor software interface308collects and passes system information303(e.g., the system-related configurations312, workload characteristics314, hardware specifications316, and the like), to the prediction unit310, and receives the resulting output305generated by the prediction unit310.

The prediction unit310is a data-driven prediction unit that is artificially intelligent and capable of performing machine learning tasks. In at least some implementations, the prediction unit310is implemented separate from or as part of the processor302as hardware, separate fixed-function circuitry, firmware, software operating on the processor302or another processor, or any combination thereof. The prediction unit310receives the system information303from the processor software interface308and, in at least some implementations, also receives the user-specified OC parameters301. As described below, the prediction unit310uses the system information303to find a set of overclocking parameters/settings318(e.g., clocks, power budget, cooling system settings, a combination thereof, or the like) that are selected and optimized for the processing device100. The prediction unit310passes an inference output305including the optimized overclocking parameters318to the processor software interface308. The processor software interface308then interacts with the processor302to apply the optimized overclocking parameters318. Stated differently, the processor software interface308interacts with the processor302to adjust one or more operating characteristics (e.g., clock rate, power/voltage, cooling, or the like) of at least one component (e.g., CPU102, GPU104, memory106, power supply circuitry116, or the like) of the processing device100. For example,FIG.3shows that the optimized overclocking parameters318are applied to one or more of the clock(s) (e.g., CPU clock, GPU clock, APU clock, memory clock, or the like) generated by the clock generation unit(s)114, the power supplied by the power supply circuitry116, the cooling solution provided by the cooling system118, or the like. In at least some implementations, the kernel mode driver and the firmware of the processor software interface308applies the optimized overclocking parameters318for processing units, such as the GPU104.

In at least some implementations, the automated OC system120performs one or more of the processes described herein (e.g., obtaining the system information303, training one or more models422(FIG.4), using the models422to determine one or more overclocking parameters, and the like) in response to receiving a request from a user to perform automated overclocking or in response detecting one or more specified events. For example, if the automated OC system120detects an event (e.g., loading a new game, changing levels within a game, changing display resolution, or the like) that changes the configuration of the processing device100, the automated OC system120dynamically reconfigures one or more overclocking parameters318, such as clock rates, for the processing device100.

FIG.4illustrates a more detailed view of the prediction unit310. In the example shown inFIG.4, the prediction unit310includes an inference/runtime pipeline402, at least a portion404of the system memory106, and a training/communication pipeline406. The inference/runtime pipeline402includes a data aggregation unit408, a pre-processor410(illustrated as pre-processor410-1), an inference engine412and a post processor414. The training/communication pipeline406, in at least some implementations, includes a pre-processor410(illustrated as pre-processor410-2), a training engine416, and a communication protocol unit418. It is noted that the prediction unit310, in at least some implementations, includes other components not shown inFIG.4or includes components different from those shown inFIG.4.

The data aggregation unit408collects and aggregates relevant information, such as the system information303(e.g., the system-related configurations312, workload characteristics314, hardware specifications316, and the like) and the user-specified OC parameters301, received from the processor software interface308that will be used by the inference engine412. In at least some implementations, a copy of the system information303is stored in a portion404of the system memory106as training data420. In at least some implementations, the user-specified OC parameters301is also stored as training data420as well. The system information303is passed to the pre-processor410-1. The pre-processor410-1receives the system information303and performs one or more pre-processing operations to output a representation of the system information303(illustrated as processed system information401) that is consumable by the inference engine412. For example, the pre-processor410-1performs one-hot encoding of categorial features, normalizes floating point values by some empirical mean and standard deviation, a combination thereof, or the like. In at least some implementations, the user-specified OC parameters301is also passed to the pre-processor410-1and stored as part of the processed system information401.

The inference engine412, in at least some implementations, is an artificial intelligence engine that implements one or more machine learning based models422(also referred to herein as trained models422). In at least some implementations, the inference engine412is implemented as hardware, separate fixed-function circuitry, firmware, software operating on the processor302or another processor, or any combination thereof. As described below, the machine learning model(s)422is trained to determine one or more overclocking parameters318that are optimized for the processing device100. In at least some implementations, the inference engine412takes as input the processed system information401(also referred to herein as inference engine input401). However, in other implementations, the inference engine412takes the unprocessed system information303as input. In at least some implementations, the inference engine412also takes model metadata424as input. The model metadata424includes a model architecture(s), learned weights, any runtime settings, and the like for one or more machine learning models422implemented by the inference engine412. The model metadata424includes information used by the inference engine412for both local function fitting (e.g., fine-tuning a neural network) and local inference.

In at least some implementations, the model metadata424is generated/determined based on a training process performed by the training engine416. For example, the training engine416takes as input the training data420stored in the portion404of the system memory106. It should be understood that althoughFIG.4shows the training data420as being stored in a portion404of the system memory106, in other implementations, at least a portion of the training data420is stored in another location on the processing device100, in a location remote from the processing device100, a combination thereof, or the like. The training data420, in at least some implementations, includes one or more instances of system information303received from the processor software interface308at different points in time. In at least some implementations, the training data420also includes system profiling data405obtained by a system profiling unit426. In at least some implementations, the system profiling data405is dynamic lower-level data (e.g., compute unit utilization, bandwidth utilization, cache behavior, and the like) that is dependent on the application executing on the processing device100and is not necessarily deterministic. For example, as one or more application112execute on the processing device100, the system profiling unit426collects information about the processing device100, the hardware configurations (e.g., GPU, CPU, etc.), and the application itself and stores this system profiling data405as part of the training data420. In at least some implementations, the training data420also includes the user-specified OC parameters301. The training data420, in at least some implementations, is processed by the pre-processor410-2prior to being received by the training engine416. For example, the pre-processor410-2performs one or more pre-processing operations to output a representation of the system information303(illustrated as processed training data403) that is consumable by the training engine416. In one example, the pre-processor410-1performs one-hot encoding of categorial features, normalizes floating point values by some empirical mean and standard deviation, a combination thereof, or the like.

The training engine416takes as input the processed training data403(or unprocessed training data420) and current model metadata424and proceeds to fine-tune the current model metadata424based on the processed training data403(e.g., local data) using one or more machine learning techniques. In at least some implementations, at least part of training or fine-tuning the model metadata424includes performing one or machine learning techniques, such as supervised learning, unsupervised learning, reinforcement learning, semi-supervised learning, self-supervised learning, multi-instance learning, statistical inference (e.g., inductive learning, deductive inference, transductive learning, and the like), multi-task learning, active learning, online learning, transfer learning, ensemble learning, or the like to configure the model(s)422for training/configuring the models422and determining the overclocking parameters318. During the training process, the model422being trained learns one or more overclocking parameters (clocks, power budget, cooling system settings, a combination thereof, or the like) for one or more components (e.g., processing units, memory, cooling systems, and the like) of the processing device100. The model422, in at least some implementations, also learns how adjusting the overclocking parameters affects performance of the processing device100and individual components given the state of the processing device100represented by the training data420, if given overclocking parameters cause system failures or instabilities, if given overclocking parameters increase or decrease the likelihood of system failures or instabilities, and the like.

For example, in a configuration where the training engine416implements supervised learning to learn parameters for overclocking the clock rate of the GPU104, the model422being trained takes the system information303from the training data420as input and learns the clock rate that maximizes performance of the GPU104given the current state of the processing device100as represented by the system information303. In at least some implementations, the model422learns the clock rate that balances performance with system stability, the clock rate that maximizes the performance-per-watt of the processing device100, or the clock rate that satisfies some other criteria. In another example of supervised learning, the model422being trained takes the system information303from the training data420and a user-defined GPU clock rate as input and learns probability of failure (e.g., TDR or system crash) for the user-defined GPU clock rate. In an example where the training engine416implements reinforcement learning to learn parameters for overclocking the clock rate of the GPU104, the models implements a reward based on, for example, a measure of correctness to guide the model422on learning the overclocking parameters for the GPU104. For example, the model422takes the system information303from the training data420as input and outputs an overclocked clock rate for the GPU104along with a reward that combines, for example, the achieved peak frame rate with an indication of whether the overclocked clock rate resulted in a failure (e.g., TDR or system crash). The reward is then fed back into the model422and the model metadata424adjusted accordingly. After the training and fine-tuning is complete for the model422, the resulting model metadata424is then stored back into the portion404of system memory106to overwrite the previous model metadata424.

In at least some implementations, the training engine416generates multiple different sets of model metadata424. In these implementations, the training engine416trains multiple models422for each of a plurality of different configurations of the processing device100and stores their resulting model metadata424in the portion404of system memory106. For example, the training engine416trains a first model422for a first configuration of the processing device100in which the processing device100has a specified CPU and GPU, a set of graphics settings, and an executing application. The training engine416then stores the resulting model metadata424associated with the first trained model422. The training engine416also trains a second model422for a second configuration of the processing device100in which the processing device100has the specified CPU and GPU, a different set of graphics settings, and a different executing application. The training engine416then stores the resulting model metadata424associated with the second trained model422. As such, the inference engine412is able to implement different models422having different model metadata424depending on the current state of the processing device100.

In at least some implementations, the model metadata424of a trained model422is sent to a remote information processing system (e.g., a server428) for centralized or federated learning. For example, the communication protocol unit418sends the fine-tuned model metadata424and training data420to a server428for centralized learning. In another example, the communication protocol unit418sends only the fine-tuned model metadata424to the server428for federated learning. The server428, in at least some implementations, sends updated model metadata back to the processing device100and the prediction unit310stores the received model metadata as the current model metadata424in the portion404of the system memory106.

As indicated above, the inference engine412, in at least some implementations, takes the processed system information401and the model metadata424as input. The inference engine412uses the model metadata424to configure a corresponding model422for locally performing inference on the processed system information401using a runtime engine. For example, the inference engine412configures the one or more models422using the model metadata424, and inputs the processed system information401into the configured model(s)422. In at least some implementations, the inference engine412implements different models422that have been trained for different configurations of the processing device100, different user-specified OC parameters301(e.g., user-selected conservative overclocking domain, user-selected aggressive overclocking domain, stability optimized overclocking, power optimized overclocking, performance optimized overclocking, performance-per-watt optimized overclocking, and the like), and the like. The model(s)422performs one or more inference operations on the processed system information401and generates an inference output305, such as one or more overclocking parameters318(e.g., clocks, power budget, cooling system settings, a combination thereof, or the like) for at least one component of the processing device100. The one or more overclocking parameters318are referred to herein as being “optimized” for the processing device100because the one or more models422implemented by the inference engine412have been trained based on specific characteristics of the processing device100, such as system-related configurations312of the processing device100, workload characteristics314of the device, hardware specifications316of the device, and the like. The processor302or an execution unit (not shown) of the automated OC system120receives and applies the one or more overclocking parameters318, as described above with respect toFIG.3. In at least some implementations, the processor302or another processor local to or remote from the processing device100is the execution unit of the automated OC system120. In other implementations, the execution unit is fixed-function circuitry implemented at the processing device100, firmware implemented at the processing device100, or software executing on the processor302or another processor local to or remote from the processing device100.

As described above, the automated OC system120performs one or more machine learning operations. As such, in at least some implementations, one or more components of the automated OC system120are machine learning (ML) modules or include a ML module(s) that implement a neural network.FIG.5shows one example of an ML module500capable of being implemented as or by one or more components of the automated OC system120, such as the prediction unit310. The ML module500, in at least some configurations, implements one or more deep neural networks (DNNs) or other neural networks for determining overclocking parameters318that are optimized for the system configuration, workload characteristics, hardware specifications, user provided criteria/parameters301, a combination thereof, or the like of the processing device100. The ML module500, therefore, illustrates an example module for implementing one or more of these neural networks.

In the depicted example, the ML module500implements at least one deep neural network (DNN)502with groups of connected nodes (e.g., neurons and/or perceptrons) organized into three or more layers. The nodes between layers are configurable in a variety of ways, such as a partially connected configuration where a first subset of nodes in a first layer is connected with a second subset of nodes in a second layer, a fully connected configuration where each node in a first layer is connected to each node in a second layer, etc. A neuron processes input data to produce a continuous output value, such as any real number between 0 and 1. In some cases, the output value indicates how close the input data is to a desired category. A perceptron performs linear classifications on the input data, such as a binary classification. The nodes, whether neurons or perceptrons, can use a variety of algorithms to generate output information based upon adaptive learning. Using the DNN502, the ML module500performs a variety of different types of analysis, including single linear regression, multiple linear regression, logistic regression, stepwise regression, binary classification, multiclass classification, multivariate adaptive regression splines, locally estimated scatterplot smoothing, a combination thereof, and so forth.

In some implementations, the ML module500adaptively learns based on supervised learning. In supervised learning, the ML module500receives various types of input data as training data, such as the training data420ofFIG.4. The ML module500processes the training data to learn how to map the input to a desired output. As one example, the ML module500receives one or more of system-related configurations312for the processing device100, workload characteristics314of the processing device100, hardware specifications316of the processing device100, user-specified overclocking parameters/criteria301, a combination thereof, or the like as input and learns how to map this input training data to, for example, one or more overclocking parameters318.

During a training procedure, the ML module500uses labeled or known data as an input to the DNN502. The DNN502analyzes the input using the nodes and generates a corresponding output. The ML module500compares the corresponding output to truth data and adapts the algorithms implemented by the nodes to improve the accuracy of the output data. Afterward, the DNN502applies the adapted algorithms to unlabeled input data to generate corresponding output data. The ML module500uses one or both of statistical analysis and adaptive learning to map an input to an output. For instance, the ML module500uses characteristics learned from training data to correlate an unknown input to an output that is statistically likely within a threshold range or value. This allows the ML module500to receive complex input and identify a corresponding output. In some implementations, a training process trains the ML module500on characteristics of overclocking (e.g., CPU clock rates, GPU clock rates, APU clock rates, memory clock rates, CPU voltages, GPU voltages, APU voltages, memory voltages, component temperatures, system temperatures, cooling system settings, a combination thereof, or the like). This allows the trained ML module500to receive input data specific to the processing device100(e.g. system-related configurations312, workload characteristics314, hardware specifications316, and user-specified OC parameters301) and determine overclocking parameters318that are optimized for the current or expected state of the processing device100.

In the depicted example, the DNN502includes an input layer504, an output layer506, and one or more hidden layers508positioned between the input layer504and the output layer506. Each layer has an arbitrary number of nodes, where the number of nodes between layers can be the same or different. That is, the input layer504can have the same number and/or a different number of nodes as output layer506, the output layer506can have the same number and/or a different number of nodes than the one or more hidden layer508, and so forth.

Node510corresponds to one of several nodes included in input layer504, wherein the nodes perform separate, independent computations. As further described, a node receives input data and processes the input data using one or more algorithms to produce output data. Typically, the algorithms include weights and/or coefficients that change based on adaptive learning. Thus, the weights and/or coefficients reflect information learned by the neural network. Each node can, in some cases, determine whether to pass the processed input data to one or more next nodes. To illustrate, after processing input data, node510can determine whether to pass the processed input data to one or both of node512and node514of hidden layer508. Alternatively or additionally, node510passes the processed input data to nodes based upon a layer connection architecture. This process can repeat throughout multiple layers until the DNN502generates an output using the nodes (e.g., node516) of output layer506.

A neural network can also employ a variety of architectures that determine what nodes within the neural network are connected, how data is advanced and/or retained in the neural network, what weights and coefficients the neural network is to use for processing the input data, how the data is processed, and so forth. These various factors collectively describe a neural network architecture configuration, such as the neural network architecture configurations briefly described above. To illustrate, a recurrent neural network, such as a long short-term memory (LSTM) neural network, forms cycles between node connections to retain information from a previous portion of an input data sequence. The recurrent neural network then uses the retained information for a subsequent portion of the input data sequence. As another example, a feed-forward neural network passes information to forward connections without forming cycles to retain information. While described in the context of node connections, it is to be appreciated that a neural network architecture configuration can include a variety of parameter configurations that influence how the DNN502or other neural network processes input data.

A neural network architecture configuration of a neural network can be characterized by various architecture and/or parameter configurations. To illustrate, consider an example in which the DNN502implements a convolutional neural network (CNN). Generally, a convolutional neural network corresponds to a type of DNN in which the layers process data using convolutional operations to filter the input data. Accordingly, the CNN architecture configuration can be characterized by, for example, pooling parameter(s), kernel parameter(s), weights, and/or layer parameter(s).

A kernel parameter indicates a filter size (e.g., a width and a height) to use in processing input data. Alternatively or additionally, the kernel parameter specifies a type of kernel method used in filtering and processing the input data. A support vector machine, for instance, corresponds to a kernel method that uses regression analysis to identify and/or classify data. Other types of kernel methods include Gaussian processes, canonical correlation analysis, spectral clustering methods, and so forth. Accordingly, the kernel parameter can indicate a filter size and/or a type of kernel method to apply in the neural network. Weight parameters specify weights and biases used by the algorithms within the nodes to classify input data. In some implementations, the weights and biases are learned parameter configurations, such as parameter configurations generated from training data. A layer parameter specifies layer connections and/or layer types, such as a fully-connected layer type that indicates to connect every node in a first layer (e.g., output layer506) to every node in a second layer (e.g., hidden layer508), a partially-connected layer type that indicates which nodes in the first layer to disconnect from the second layer, an activation layer type that indicates which filters and/or layers to activate within the neural network, and so forth. Alternatively or additionally, the layer parameter specifies types of node layers, such as a normalization layer type, a convolutional layer type, a pooling layer type, and the like.

While described in the context of pooling parameters, kernel parameters, weight parameters, and layer parameters, it will be appreciated that other parameter configurations can be used to form a DNN consistent with the guidelines provided herein. Accordingly, a neural network architecture configuration can include any suitable type of configuration parameter that a DNN can apply that influences how the DNN processes input data to generate output data.

The architectural configuration of the ML module500, in at least some implementations, is based on the current state of the processing device100including the current system configuration, workload(s), hardware specifications, user-specified OC parameters301, a combination thereof, or the like of the processing device100. For example, in a first configuration, the processing device100operates with a specified CPU clock rate, a specified GPU clock rate, a specified memory clock rate, a specified CPU voltage, a specified GPU voltage, a specified set of display settings, a specified set of cooling settings, one or more executing applications, a specific CPU model, a specific GPU model, a specified amount of random access memory (RAM), and the like. Thus, in this example, the ML module500is trained based on this first configuration of the processing device100. However, other configurations of the processing device100are possible as well. For example, in a second configuration, the user may have changed the GPU model, different applications may be executing, the temperature of the processing device100has changed, or the like. Thus, in this example, the ML module500is also trained based on one or more other configurations of the processing device100, such as the second configuration. Accordingly, in some implementations, the ML module500is configured to implement different neural network architecture configurations for different combinations of system-related configurations312, workload characteristics314, hardware specifications316, or the like. For example, the processing device100has access to one or more neural network architectural configurations for use depending on the current state of the processing device100relating to one or more of the system configuration, workload(s), hardware specification, or the like.

In at least some implementations, the device implementing the ML module500locally stores some or all of a set of candidate neural network architectural configurations that the ML module500can employ. For example, a component of the automated OC system120can index the candidate neural network architectural configurations by a look-up table (LUT) or other data structure that takes as inputs one or more parameters, such as one or more system-related configurations of the processing device100, workload characteristics of the processing device100, hardware specifications of the processing device100, a combination thereof, or the like, and outputs an identifier associated with a corresponding locally-stored candidate neural network architectural configuration that is suited for operation in view of the input parameter(s). As such, the ML module500allows components of the automated OC system120, such as the prediction unit310, to perform one or more machine learning operations for determining one or more overclocking parameters that are optimized for the processing device100.

FIG.6illustrates a flow diagram of a method600for training one or more machine learning models422to determine overclocking parameters for a current or expected configuration of a processing device100. It should be understood the processes described below with respect to method600have been described above in greater detail with reference toFIG.2toFIG.5. For purposes of description, the method600is described with respect to an example implementation at the processing device100ofFIG.1, but it will be appreciated that, in other implementations, the method600is implemented at processing systems having different configurations. Also, the method600is not limited to the sequence of operations shown inFIG.6, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, the method600can include one or more different operations that those shown inFIG.6.

At block602, the automated OC system120obtains system information303representing a current state of a processing device100. For example, the system information303includes one or more of system-related configurations312, workload characteristics314, hardware specifications316of the processing device100. In at least some implementations, at least part of the system information303is obtained by a system profiling unit426as described above with respect toFIG.4. At block604, a data aggregation unit408(or another component) of the automated OC system120stores a copy of the system information303in memory106as training data420.

At block606, a pre-processor410-2of the automated OC system120performs one or more pre-processing operations on the training data420to output a representation of the training data420that is consumable by a training engine416of the automated OC system120. In at least some implementations, the training data420is not pre-processed. At block608, the training engine416uses the training data420to train one or more machine learning models422for determining overclocking parameters318based on a current state of the processing device100. In at least some implementations, the training data420also includes user-specified OC parameters301, such as user request for overclocking one or more components of the processing device in a conservative overclocking domain or an aggressive overclocking domain. At block610, the training engine416stores the model metadata of the trained model422in, for example, a portion404of system memory106. The method600can then exit or return to block602for training additional models422or update previously trained models422.

FIG.7illustrates a flow diagram of a method700for performing automated overclocking of a processing device100according to one or more of the techniques described herein. It should be understood the processes described below with respect to method700have been described above in greater detail with reference toFIG.2toFIG.5. For purposes of description, the method700is described with respect to an example implementation at the processing device100ofFIG.1, but it will be appreciated that, in other implementations, the method700is implemented at processing systems having different configurations. Also, the method700is not limited to the sequence of operations shown inFIG.7, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some implementations, the method700can include one or more different operations that those shown inFIG.7.

At block702, the automated OC system120obtains system information303representing a current state of a processing device100. For example, the system information303includes one or more of system-related configurations312, workload characteristics314, hardware specifications316of the processing device100. In at least some implementations, at least part of the system information303is obtained by a system profiling unit426as described above with respect toFIG.4. The automated OC system120, in at least some implementations, receives user-specified OC parameters301in addition to the system information303. For example, the automated OC system120a graphical user interface304associated with the automated OC system120is presented to a user of the processing device100. The user is able to provide user-specified OC parameters301through the graphical user interface304, such as user-selected conservative overclocking domain, user-selected aggressive overclocking domain, stability optimized overclocking, power optimized overclocking, performance optimized overclocking, performance-per-watt optimized overclocking, and the like.

At block704, a pre-processor410-1of the automated OC system120performs one or more pre-processing operations on the system information303to output a representation of the system information303that is consumable by an inference engine412of the automated OC system120. In at least some implementations, the system information303is not pre-processed. At block706, the inference engine412receives as input the system information303representing the current configuration of the processing device. In at least some implementations, the inference engine412also receives the user-specified OC parameters301as input. At block708, the inference engine412generates an output305comprising a set of overclocking parameters318(e.g., clock rate settings, power settings, thermal management settings, memory settings, a combination thereof, or the like) associated with the at least one component based on the system information303(and the user-specified OC parameters301if received as input). For example, the inference engine412, in at least some implementations, implements a machine learning model422that takes the system information (and user-specified OC parameters301if available) as input and outputs the set of overclocking parameters318based thereon. The inference engine412, in at least some implementations, configures a neural network represented by the model422based on the input received by the inference engine412. In another example, the inference engine412selects a model422(or model metadata424) based on at least one of the system information303or user-specified OC parameters301. The inference engine412then implements the selected model422or configures a model422based on the selected model metadata424.

At block710, the automated OC system120or processor302adjusts one or more operating characteristics (e.g., clock rates, power/voltage, thermal/cooling settings, or the like) of the at least one component of the processing device100based on the set of the set of overclocking parameters318. At block712, the automated OC system120determines if the current configuration of the processing device100has changed. For example, the automated OC system120monitors the system information303for any changes. If the current configuration of the processing device100has not changed, the automated OC system120continues to monitor the current configuration for any changes. If the current configuration of the processing device100has changed, the method returns to block702where system information303representing the new configuration of the processing device100is processed. The processes described above with respect to blocks704to710are then repeated for the new configuration such that a new set of overclocking parameters318are determined at block708, and one or more operating characteristics of the at least one component are adjusted at block710based on the new set of overclocking parameters318.

Benefits, other advantages, and solutions to problems have been described above with regard to specific implementations. However, the benefits, advantages, solutions to problems, and any feature(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature of any or all the claims. Moreover, the particular implementations disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular implementations disclosed above may be altered or modified and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.