Circuit system and method for enhanced selection of performance monitoring

Abstract

Techniques for performance monitoring are described. In some examples, an apparatus (e.g., a processor) includes: execution circuitry for executing one or more instructions; a performance monitoring counter; a control register including a threshold field; and a performance monitor control circuit for incrementing the performance monitoring counter in response to a performance monitoring event of the one or more instructions being equal to but not greater than the threshold field.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. Provisional Patent Application Serial No. 63 / 541,712, filed on September 29, 2023, and entitled “Performance Monitoring,” which is incorporated herein by reference in its entirety. Background Art

[0003] Modern processors generally include performance monitoring capabilities, so that users with technical capabilities can perform debugging and code analysis functions. In some processors, a top-down microarchitecture analysis (TMA) methodology is provided to be used to identify software performance issues. This TMA methodology is a hierarchical organization of event-based indicators, which is a dominant performance bottleneck in the indicator identification application. Its purpose is to show on average the goodness of (one or more) processor pipelines being utilized when running applications. However, the current mechanism for accessing this information may suffer from lack of precision and / or resource impact. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Various examples according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0005] Figure 1 A block diagram of a portion of a processor according to some examples is illustrated.

[0006] Figure 2 A flow chart of a method according to some examples is illustrated.

[0007] Figure 3 is a block diagram illustrating a processor for generating and storing PEBS and NPEBS records according to an example.

[0008] Figure 4 An example of a process of generating and storing PEBS records in a memory buffer and storing the memory buffer to a PEBS trace file is illustrated.

[0009] Figure 5 An example of a process for programming a PEBS handler circuit to monitor processor performance and generate PEBS records to be stored in a PEBS memory buffer and then in a PEBS trace file is illustrated.

[0010] Figure 6 An example of an architectural performance monitoring layout of a Performance Event Select-x (PERFEVTSELx) MSR is illustrated.

[0011] Figure 7 An example of a logic table using some fields of the PERFEVTSELx MSR is shown.

[0012] Figure 8 An example computing system is illustrated.

[0013] Fig. 9 Illustrated is a block diagram of an example processor and / or system on a chip (SoC), which may have one or more cores and an integrated memory controller.

[0014] Fig.10 is a block diagram illustrating a computing system 1000 configured to implement one or more aspects of the examples described herein.

[0015] Fig.11A An example of a parallel processor is illustrated.

[0016] Fig. 11B An example of a block diagram of a partition unit is illustrated.

[0017] Fig. 11C An example of a block diagram of a processing cluster within a parallel processing unit is illustrated.

[0018] Fig.11D An example of a graphics multiprocessor is illustrated, where the graphics multiprocessor is coupled with a pipeline manager of a processing cluster.

[0019] Figures 12A-12C Additional graphics multiprocessors are illustrated according to examples.

[0020] Fig.13 A parallel computing system 1300 is illustrated according to some examples.

[0021] Figures 14A-14B Illustrated is a hybrid logical / physical view of a disaggregated parallel processor according to examples described herein.

[0022] Fig.15A is a block diagram illustrating both an example in-order pipeline and an example register renaming out-of-order issue / execution pipeline according to an example.

[0023] Fig. 15B is a block diagram illustrating both an example in-order architecture core and an example register renaming out-of-order issue / execution architecture core to be included in a processor according to an example.

[0024] Fig.16 Examples of execution unit circuitry (such as execution unit circuitry (s)) are illustrated.

[0025] Fig.17is a block diagram of a register architecture according to some examples.

[0026] Fig.18 An example of an instruction format is illustrated.

[0027] Fig.19 An example of an addressing information field is illustrated.

[0028] Fig. 20 An example of the first prefix is ​​illustrated.

[0029] Figures 21A-21D An example of how the R, X, and B fields of the first prefix are used is illustrated.

[0030] Figures 22A-22B An example of the second prefix is ​​illustrated.

[0031] Fig.23 An example of the third prefix is ​​illustrated.

[0032] Figures 24A-24B Thread execution logic including an array of processing elements employed in a graphics processor core is illustrated according to examples described herein.

[0033] Fig.25 Additional execution units according to examples are illustrated.

[0034] Fig.26 is a block diagram illustrating a graphics processor instruction format 2600 according to some examples.

[0035] Fig. 27 is a block diagram of another example of a graphics processor.

[0036] Fig.28A is a block diagram illustrating a graphics processor command format according to some examples.

[0037] Fig.28B is a block diagram illustrating a graphics processor command sequence according to an example.

[0038] Fig.29 is a block diagram illustrating converting binary instructions in a source ISA to binary instructions in a target ISA using a software instruction converter according to an example.

[0039] Fig.30 is a block diagram illustrating an IP core development system 3000 that may be used to fabricate an integrated circuit to perform operations according to some examples. DETAILED DESCRIPTION

[0040] In various examples, the processor may be configured with a plurality of dedicated or fixed counters of the performance monitoring unit to enable counting of raw events at the highest hierarchical level of a multi-level performance monitoring methodology (also referred to herein as a "performance monitoring arrangement," "performance monitoring organization," and "performance monitoring system"). While the examples are applicable to any performance monitoring arrangement, the specific implementations described herein are for A top-down microarchitecture analysis (TMA) methodology. In this methodology, there can be multiple levels of performance indicators that can be monitored from the highest level to the lowest level of the hierarchy. In different cases, there may be 2, 3, or more levels of performance indicators.

[0041] In one or more examples, a fixed set of counters may be provided, each counter being associated with a specific top-level performance indicator, such as TMA Level 1 (L1) according to the TMA methodology described above. In this way, the need to allocate programmable counters to count such indicator information or to obtain the information through performance indicator model (or machine) specific registers (MSRs) may be avoided.

[0042] With these counters, a low-cost mechanism is implemented to offload expensive programmable counters. These fixed counters reduce multiplexing by allowing specific top-level events to be collected together with programmable events (which may be programmed for lower-level events). These fixed counters are very accurate and fast to access because they provide raw counts and have a size that can trigger clearing overflows within a relatively long duration (e.g., about 400 seconds).

[0043] In one processor implementation, it can be assumed that there are N (e.g., 4) pipeline time slots available for each core in each clock cycle. Certain performance monitoring unit (PMU) events can be used to measure how well those pipeline time slots are utilized. In this implementation, each pipeline time slot available during the runtime of the application can be classified into one of four L1 categories (e.g., Front End Bound, Bad Speculation, Back End Bound, or Retiring) based on the occurrence of these PMU events during execution. In other cases, more or different L1 indicators can be maintained. In some cases, one of the four L1 categories may not be maintained in a fixed counter, but the L1 performance indicator can be derived from other L1 performance indicators, as further described below.

[0044] In contrast to the example of providing fixed counters for the highest hierarchy level of performance monitoring arrangement, other means of capturing TMA data have disadvantages. In the absence of examples and with a limited number of programmable counters, users can reuse events across multiple runs of workloads to obtain complete profiles and collect events at the lowest level of the hierarchy. TMA indicators can include dozens of events in total. This multiplexing process can introduce problems in the profile (thus requiring more time to collect) and sometimes also generate inconsistent data, because the behavior of each run of the workload may be different (e.g., based on other content, interruption rate, etc. running on the system). Examples may reduce or even avoid the need for multiplexing, thereby improving the fidelity of the profile.

[0045] Some processors may provide a performance indicator MSR (e.g., called PERF_METRICS MSR) that may provide a means of collecting TMA L1 data without using a programmable counter. However, the counter can only provide percentage information, such as the percentage of time slots in each category that falls into the TMAL1 category. But this PERF_METRICS interface has disadvantages. First, the access speed to the PERF_METRICS MSR is much slower than the access speed to the PMU counter. Although the programmable PMU counter can be read as fast as 10 cycles (e.g., using a read operation via a read performance monitoring counter instruction (RDPMC)), in some examples, reading the PERF_METRICS MSR takes about 100 cycles. In addition, in some examples, there is additional waiting time to obtain percentage information, because the processor collects raw counts based on the L1 indicator, and then divides each raw count by the total number of time slots in order to calculate the percentage to be returned for this MSR. In addition, in some examples, since more time slots are represented by each of the 8 bits that form the percentage of each L1 indicator, the accuracy of the L1 indicator degrades over time. To minimize the accumulation of this error, some tools clear the PERF_METRICS MSR each time the value is consumed. In some examples, this process may take about 500 cycles, and may typically occur once every millisecond, adding overhead to collecting the profile.

[0046] In an example, processor identification information may be accessed to indicate the presence of fixed performance monitoring counters, including the fixed counters described herein. In a specific example, software or other entities may discover the fixed counters described herein via execution of the CPUID instruction:

[0047] CPUID.0xA.ECX[7:4]=0b1111 (fixed counter bitmap).

[0048] In one or more examples, a set of four fixed counters may be provided to count four TMA L1 metrics. In other examples, more or fewer such fixed counters may be provided to count additional or different TMA Level 1 metrics. And in other examples, additional fixed counters may be provided for other levels of TMA metrics and / or other types of metrics. In one example, the following fixed counters may be assigned to the TMAL1 performance metric: FIXED_CTR4-TOPDOWN_BAD_SPECULATION (MSR 0x30D)

[0049] FIXED_CTR5-TOPDOWN_FE_BOUND(MSR 0x30E)

[0050] FIXED_CTR6-TOPDOWN_RETIRING(MSR 0x30F)

[0051] FIXED_CTR7-TOPDOWN_BE_BOUND(MSR 0x310)

[0052] Note that if any single counter is not supported, then in some examples the missing metric may be calculated from SLOTS-SUM(FixedCtr[7:4]), where SLOTS may be obtained from another fixed counter or via other means. In an example processor, there may be additional fixed counters to count additional events, including retired instructions, unstopped core clocks, unstopped timestamp counter clocks, time slots, and so forth.

[0053] In one or more examples, these counters are enabled and configured in response to a request from a given performance analysis software or other entity. In response to such a request, a field in one or more configuration registers may be set. The (one or more) configuration registers may include various bit fields for configuring these fixed counters. For example, a bit field may enable a counter, its overflow behavior, a user / operating system (OS) mode, etc. In one or more examples, in order to enable a given fixed counter, an enable indicator (e.g., PERF_GLOBAL_CTRL) of a global performance control register may be set. In addition, an overflow indicator (e.g., PER_GLOBAL_STATUS) of a global performance status register may be set to indicate overflow behavior. In addition, an in-use indicator (e.g., PERF_GLOBAL_INUSE) of a global performance in-use register may be set to indicate that the counter is active. In addition, an enable indicator (e.g., PEBS_ENABLE) of a processor event-based sampling enable register may be set.

[0054] In addition to configuring the fixed counters, a fixed counter configuration register (e.g., FIXED_CTR_CTRL) may also be written. In an example, a configuration field may be provided in this register for each fixed counter. The configuration field may store information to identify whether the counter is enabled for a given privilege level (e.g., user or OS, or both), and whether a performance monitoring interrupt (PMI) is raised in response to an overflow of the counter.

[0055] In some cases, the user may wish to determine the percentage of time slots in each L1 category. To determine this percentage, the total number of time slots can be collected by one of a variety of means. In one example, the TOPDOWN.SLOTS event can be obtained via a fixed counter or a programmable event (for example, this event may be: event ID 0xA4, umask 0x01). In the example of a fixed-width microarchitecture, the total time slots can be calculated by collecting the total cycles and multiplying by the time slots per cycle. Note that the time slots per cycle may vary by microarchitecture, but if the width is fixed, the width is enumerated in an ID register, such as CPUID.0xA.EDX[19:16] (otherwise it is 0, in which case the above technique can be used).

[0056] In yet another case, cycles may be collected via a fixed counter or a programmable CPU_CLK_UNHALTED.CORE event (eg, this event may be: event ID 0x3c, umask 0x00).

[0057] Reference now Figure 1 , which is a block diagram of a portion of a processor according to an example. Note that Figure 1 In FIG. 1 , processor 100 is shown at a high level and illustrates a general pipeline architecture of a processing engine such as a processor core. It should be understood that multiple pipelines may exist in one or more cores. Figure 1 At the high level shown, there is also a performance monitor 180, the details of which are described below.

[0058] exist Figure 1 In the example, the branch predictor 110 can predict whether the branch is taken or not taken based on the history of branch directions, and provide this information to the instruction cache 120. The instruction cache 120 is coupled to the instruction fetch circuit 130. The instruction fetch circuit 130 can fetch instructions from the instruction cache 120 or another storage device. In turn, the fetched instructions (which may be in the form of macroinstructions at this time) are provided to the decoder 140. In an example, the decoder 140 can decode each macroinstruction into one or more micro-operations.

[0059] Still reference Figure 1 , decoder 140 provides decoded instructions to register renamer 150, which may also perform allocation and scheduling operations to schedule incoming instructions for execution in execution circuit 160, as shown. Execution circuit 160 may include multiple execution units, such as integer and floating point units, to perform operations on incoming source operands. Results are provided via a write-back path of register file 170.

[0060] like Figure 1 As further shown in FIG. 1 , performance monitor 180 is coupled to the front end (FE) and back end (BE) of processor 100. It should be understood that in one or more implementations, performance monitor 180 may be a distributed hardware circuit including various storage devices (e.g., registers or other counters) to perform counting of various events or other operations under the control of control circuit 185. As shown, control circuit 185 may include (or be coupled to) a set of registers 188, which may include registers that may be used to enable and / or configure the fixed counters described herein (e.g., based on Figure 7 Configuration registers, control registers and / or status registers of the logic table 700 in the embodiment.

[0061] exist Figure 1 At a high level shown in , performance monitor 180 includes a set of fixed counters 182 (e.g., 182-0 through 182m) and a set of programmable counters 184 (e.g., 184n through 184p). Note that the counters may be external to performance monitor 180. In some examples, at least some of the fixed counters 182 may be provided to maintain the TMA level 1 counts described herein. Although the examples are not limited in this regard, in one or more examples, there may be 8 fixed counters, including 4 TMA level 1 counters and 4 additional counters that may count other events such as those described above. In one or more examples, each core may provide a separate set of fixed counters and programmable counters. And although in Figure 1 In , the various counters are typically shown in the performance monitor, but in some implementations, the counters may reside in the bus cluster unit or other location.

[0062] In different examples, there may be different numbers of programmable counters. In one example, there may be 8 programmable counters. In some examples, since fixed counters are provided for TMA Level 1 indicators, no programmable counters 184 need to be allocated for these indicators, thereby reducing the pressure on these programmable counters. It should be understood that although in Figure 1 The examples are shown at this high level, but many variations and alternatives are possible.

[0063] In some examples, the last branch record (LBR) insertion and / or removal event is countable (Event Select E4H, UMask 01H). For example, this event is counted when an LBR entry is inserted or removed. In some examples, an insertion means that an actual LBR buffer update has occurred, taking into account LBR configuration and filtering. In some examples, when a RET instruction retires in LBR call stack mode, the LBR entry is removed. Software may use this event in some uses, such as Profile Guided Optimization (PGO) for profiling collections across processors and in a virtualized environment.

[0064] In some examples, processors that support performance metrics may also support clearing them on read, e.g., if MSR PERF_CAPABILITIES.RDPMC_CLEAR_METRICS[bit 19] is set. In some examples, RDMPC is a read performance monitoring instruction that reads the contents of a particular counter. In some examples, the counter is referenced by the contents of a register. In some examples, the register is implicit (e.g., non-explicit).

[0065] When MSR FIXED_CTR_CTRL.METRICS_CLEAR_EN[bit 14] is set, the RDPMC instruction for ERF_METRICS—that is, when ECX = 0x2000'0000—clears the PERF_METRICS related resources and the fixed function performance monitoring counter 3 after a read is executed. When METRICS_CLEAR_EN is cleared, the read-only behavior is maintained.

[0066] Reference now Figure 2 , which is a flow chart of a method 200 according to an example. More specifically, as Figure 2 As shown, method 200 is a method for controlling the operation of one or more fixed and programmable counters of a performance monitor. In an example, method 200 can be performed at least in part by hardware circuitry (such as control circuitry 185 of the performance monitor). In other cases, method 200 can be performed by hardware circuitry in combination with firmware and / or software.

[0067] like Figure 2 As shown in FIG. 2 , method 200 begins at block 210 by enabling and configuring one or more TMA fixed counters. In an example, these counters may be responsive to one or more configuration registers (e.g., Figure 1188 in the register 188). In this way, each counter can be enabled and configured for a given operating mode. For example, in one use case, a performance monitoring tool can issue a request that causes a configuration register to be written.

[0068] Next at block 220, one or more programmable counters may be enabled and configured for the selected one or more events. For example, additional configuration register writes may be performed to associate different counters in the set of programmable counters with a given event. Then at block 225, both fixed counters and programmable counters (e.g., Figure 2 184n to 184p) can be enabled globally.

[0069] At this point, the various counters of the performance monitoring unit are configured for normal operation. Thus, a given application or other program of interest may begin execution. During such workload execution, at block 230, various counters may be updated based on the workload execution. For example, an event occurring during processor execution and associated with a particular top-down level 1 metric may cause an update of an associated fixed counter.

[0070] During workload execution, it may be determined whether any counter has overflowed at diamond 240. If so, control passes to block 260 where at least the counter, and possibly all counters, may be read and their values ​​stored in a storage device such as a performance log file (which may be stored in system memory, such as dynamic random access memory (DRAM)).

[0071] Control then passes to diamond 270 to determine whether the execution of the application (or the desired number of executions of the application for performance monitoring) is complete. If not, control passes back to block 230. Otherwise, when such execution has been completed, control passes to block 280 where the count values ​​may be provided to the requester. For example, a log file may be provided in a user-readable form to identify the various fixed and programmable counters and the corresponding count values ​​or other information present in each of these counters.

[0072] Still reference Figure 2 If instead no counter overflow is determined at diamond 240, control may pass to block 250 where it may be determined whether a given counter has reached a stopping point. For example, some counters may be programmed to count until a given value (threshold) is reached (e.g., a counter mask). After this occurs, control passes to block 260 as discussed above. It should be understood that although in Figure 2The examples of are shown at this high level, but many variations and alternatives are possible. For example, in other cases, one or more of the fixed counters may be read in response to a read performance monitoring counter instruction (e.g., RDPMC), which may be executed in a small number of cycles (e.g., 10).

[0073] Precise and Imprecise Event-Based Sampling (PEBS and NPEBS)

[0074] The performance monitoring capability employed in some examples may be based on three sets of event counters: fixed function counters, general purpose counters, and timed PEBS counters (e.g., Figure 3 337a-337n in the timing PEBS counters 337a-337n). In an example, three fixed function counters may be defined and implemented to count retired instructions, reference clocks, and core clocks. General purpose counters and timing PEBS counters may be defined and implemented as described below. In an example, any number of general purpose counters may each be associated with a corresponding timing PEBS counter. In an example, any number of timing PEBS counters may be used in conjunction with monitoring events (e.g., load STLB hits) that may not be defined and / or may not be selected as PEBS events according to previous PEBS architectures.

[0075] As used herein, a precise event is a performance event that is linked to a specific instruction or micro-operation in an instruction trace and occurs when the instruction or micro-operation retires. Such precise events may include, but are not limited to, retired instructions, retired branch instructions, cache references, or cache misses, to name a few examples. On the other hand, an imprecise event is a performance event that is either not linked to a specific instruction or micro-operation in an instruction trace, or may occur speculatively even when the instruction or micro-operation is not retired. For example, an imprecise event may include, but is not limited to, a reference clock tick, a core clock tick, a cycle when an interrupt is masked, to name a few examples.

[0076] In some examples, the performance of the processing device is monitored to manage events and measure their impact on performance. In some examples, the processing device tracks precise and imprecise events and uses a mechanism on the processing device to store architectural and microarchitectural metadata about the events in a non-intrusive manner without intervention of a performance monitoring interrupt (PMI).

[0077] The operation of the processing device may include the occurrence of multiple events that monitor system performance. An event may include any operation, occurrence, or action in a processor. In an example, an event is a response to a given instruction and data stream in the processing device. An event may be associated with architectural metadata including state information of the processing device, including but not limited to an instruction pointer, a timestamp counter, and register states. An event may also be a generic event (e.g., INST_RETIRED) that may be marked with a performance cost.

[0078] In an example, a performance counter is configured to count one or more types of events. When the counter is incremented or decremented, the software reads the counter at selected intervals to determine the number of events that have been counted between these intervals. The counter can be implemented in a variety of ways. In an example, the counter decrements from a positive starting value and overflows when the count reaches zero. In other examples, the counter starts with a zero value and increments the count of occurrences until it overflows at a specified value. In other examples, the counter starts with a negative value and increments until it overflows when it reaches zero. The performance counter can generate a performance record or a performance monitoring interrupt (PMI) when the counter overflows. In order to trigger an overflow, the counter can be preset to a modulus value: the modulus value can cause the counter to overflow after a certain number of events have been counted, which generates a PMI or performance record, such as a precise event-based sampling (PEBS) record.

[0079] As described further below, the performance record may include a performance cost or penalty metric that will help rank the criticality of events to performance. In an example, the cost may be measured by the push-out time caused by the event.

[0080] Examples may include new (e.g., not defined and / or selectable as PEBS events according to previous PEBS architectures) precise events (e.g., BR_MISP_RETIRED.PLUS_ONE (raised on the first instruction after a branch misprediction) for STLB hit retirement load / store) and / or upgrading events (MACHINE_CLEARS) to precise.

[0081] Tracking precise events There are several types of mechanisms for monitoring and managing various events. One type is a PEBS mechanism that functions to monitor and manage precise events. A precise event is a performance event that is linked to a specific instruction or micro-operation in an instruction trace and occurs when that instruction or micro-operation retires. Such precise events may include, but are not limited to, retired instructions, retired branch instructions, cache references, or cache misses, to name a few examples. The PEBS mechanism may include several components, such as an event selection (ES) control (e.g., Figure 3ES controls 350a-350c in the ES control, performance counters, PEBS enabling circuits, and PEBS handler circuits. The ES control can be programmed with an event identifier that causes the performance counter corresponding to the ES control to begin tracking a programmed event corresponding to the event identifier (e.g., counting occurrences of the programmed event).

[0082] The example may also include a PEBS enabling circuit of a processing device that controls when a PEBS record is generated. When the PEBS enabling circuit is activated, the PEBS record is stored in a memory of the PEBS handler circuit when a performance counter corresponding to the PEBS enabling circuit overflows. In an example, a user (e.g., software) may activate or set the PEBS enabling circuit. The PEBS record may include architectural metadata of the state of the system when the performance counter overflowed. Such architectural metadata may include, but is not limited to, an instruction pointer (IP), a timestamp counter (TSC), and register states. Thus, the PEBS record not only allows accurate profiling of the location of precise events in instruction tracing, but also provides additional information for software optimization, hardware optimization, performance tuning, and the like.

[0083] PEBS records may also include microarchitectural information that can measure the performance cost of an event. For example, in the case of MEM_LOAD_RETIRED.L3_MISS (demand load access misses L3 cache), the PEBS record may include a performance cost or penalty metric that will help rank the criticality of misses at different IPs.

[0084] Tracking Imprecise Events

[0085] The example may further utilize the PEBS mechanism to track and manage imprecise events of the processing device. An imprecise event is a performance event that is either not linked to a specific instruction or micro-operation in the instruction trace, or may occur speculatively even when the instruction or micro-operation is not retired. For example, an imprecise event may include, but is not limited to, a reference clock tick, a core clock tick, a cycle when an interrupt is masked, etc.

[0086] Some examples introduce a non-precise event based sampling (NPEBS) handler circuit of a processing device, which allows the NPEBS handler circuit to generate a programmed NPEBS record of inaccurate events and store the NPEBS record of inaccurate events in a PEBS memory buffer of the PEBS handler circuit.

[0087] In an example, the NPEBS record shares the same format as the PEBS record. In other examples, the format of the NPEBS record is different from the PEBS record.

[0088] The PEBS handler circuit and the NPEBS handler circuit may share some circuits. The NPEBS handler circuit may use resources of the PEBS handler circuit that differ from the PEBS handler circuit only in name. In an example, when the ES control is programmed with an imprecise event identifier, a performance counter associated with the ES control and the PEBS enable circuit tracks the programmed imprecise event. In an example, the NPEBS handler circuit is coupled to the PEBS enable circuit, and the PEBS enable circuit is coupled to the performance counter, so that when the performance counter overflows, the PEBS enable circuit causes the NPEBS handler circuit to generate an NPEBS record of the imprecise event. Thus, architectural metadata associated with the imprecise event is captured without the need for PMI.

[0089] In an example, the NPEBS handler circuit controls the timing of the generation of the NPEBS record for the imprecise event. In an example, the NPEBS record for the imprecise event is generated immediately upon an overflow of a performance counter that tracks the imprecise event. In other examples, the NPEBS record for the imprecise event is generated immediately after an overflow of a performance counter that tracks the imprecise event occurs (e.g., upon execution of a next subsequent instruction). In an example, the NPEBS handler circuit stores the NPEBS record for the imprecise event in a memory storage device of the NPEBS handler circuit.

[0090] Some examples include compact circuits and are therefore implemented as an integrated part of a wide range of processing units without causing significant increases in cost and power consumption. Some examples are programmable circuit logic and are used to track and manage different types of imprecise events on the same circuit logic. The NPEBS handler circuit can also be expanded to track multiple processing units. The NPEBS handler circuit can be shared by multiple applications running on the same processor and managed by an operating system (OS) or a virtual machine as a shared resource.

[0091] Exemplary Processor for Generating and Storing PEBS and NPEBS Records

[0092] Figure 3 is a block diagram illustrating a processor for generating and storing PEBS and NPEBS records according to an example. Figure 3 Any or all of the blocks shown in may represent circuitry and / or logic in a performance management unit (PMU) of a processor. In some examples, the PMU supports timed PEBS and hybrid enumeration architectures via CPUID.

[0093] The CPUID leaf enhances the enumeration of PMU capabilities. Specifically, in some examples, the CPUID sub-leaf accommodates future PMU extensions, hybrid resources are exposed by core type, bitmap hybrid enumeration using generic counter availability, bitmap hybrid enumeration using fixed counter availability, and new architectural PMU capabilities can be exposed via CPUID.

[0094] exist Figure 3 , a core 302 of a multi-core processor (e.g., having one or more performance cores and one or more efficiency cores—other cores 390 and 393 are shown and may be performance cores or efficiency cores) includes an NPEBS handler circuit 306 and a PEBS handler circuit 308 (e.g., performance monitor 180), the PEBS handler circuit 308 having one or more memory storage devices 330a to 330n (which may be implemented as physical memory storage devices such as buffer instructions). The PEBS handler circuit 308 may also include a performance monitoring interrupt (PMI) component 332 as described above. In addition, the processor core 302 may include one or more event selection (ES) controls 334a to 334n, which correspond to one or more general performance counters 336A-336n and further correspond to one or more PEBS enable circuits 338A-338n (the details of which are described above). In some implementations, the PEBS enable circuits 338A-338n may be located in a single control register (e.g., a machine specific register or MSR). In some examples, the performance core(s) and the efficiency core(s) share an instruction set architecture. In some examples, the performance core(s) and the efficiency core(s) have different instruction set architectures.

[0095] In addition, Figure 3 In the example shown, fixed function counters 360a-360c are used to apply PEBS, NPEBS and precise distribution of retired instructions (PDIR) operations. In the example, three fixed function counters 360a-360c are defined and implemented to count retired instructions, reference clocks and core clocks. However, it will be appreciated that the underlying principles of the present invention are not limited to any particular number of fixed function counters or any particular fixed function counter implementation.

[0096] As mentioned, the processor core 302 can execute an instruction stream that can be embedded with event markers that can be placed on the bus / interconnect structure 304. The execution of a segment of instructions can constitute one or more imprecise events. An imprecise event is a performance event that is either not linked to a specific instruction or micro-operation in the instruction trace, or can occur speculatively even when the instruction or micro-operation is not retired. Such imprecise events can include, but are not limited to, reference clocks, core clocks, and cycles, to name a few examples. In an example, the imprecise event is generated by the processor core 302. In an example, the imprecise event is generated external to the processor core 302 and transmitted to the processor via the bus / interconnect structure 304.

[0097] In the example, Figure 3 The illustrated event selection (ES) controls 350a-c perform similar operations to the ES controls 334a-c described above, but the ES controls 350a-c correspond to fixed-function performance counters 360a-c and further correspond to PEBS enable circuits 370a-c associated with the fixed-function counters 360a-c. In the example, the PEBS enable circuits 338a-338n and 370a-c are located in a single control register.

[0098] In one example, the programming of the ES controls 350a-c causes the performance counters 360a-c corresponding to the programmed ES controls to track the occurrence of specific programmed imprecise / precise events. In some examples, any event that is not defined as a precise event is considered an imprecise event. In one example, the ES controls 350a-c are programmed by an executing application. In another example, a user programs the ES controls 350a-c using imprecise / precise event identifiers.

[0099] When the ES controls 350a-c are programmed with event identifiers, the performance counters 360a-c corresponding to the ES controls 350a-c are incremented or decremented at each occurrence of the programmed event. The PEBS enabling circuits 370a-c corresponding to the ES controls 350a-c and the fixed-function performance counters 360a-c can be set (e.g., activated, flag set, bit set to 3, etc.) to generate a PEBS record when the fixed-function performance counters 360a-c overflow, or if the counters are decremented, when the fixed-function performance counters 360a-c reach a value of 0. In one example, the PEBS enabling bit is set to enable the PEBS handler circuit 308 to generate a PEBS record when the fixed-function performance counters 360a-c that count events overflow or zero value. As discussed above, the PEBS record includes architectural metadata of the state of the system at the overflow or zero value of the fixed-function performance counters 360a-c. The architectural metadata may include, but is not limited to, for example, IP, TSC, or register state.

[0100] In one example, NPEBS handler circuit 306 is coupled to PEBS enable circuits 370a-c such that when fixed function performance counters 360a-c overflow or reach a zero value, NPEBS handler circuit 306 causes PEBS enable circuits 370a-c to generate a PEBS record of the event. In some examples, NPEBS handler circuit 306 controls the timing of the generation of the PEBS record of the event. For example, in one example, NPEBS handler circuit 306 causes PEBS enable circuits 370a-c to generate a PEBS record of the event immediately upon an overflow or zero value of a performance counter 360a-c that tracks and counts programming events.

[0101] In another example, the NPEBS handler circuit 306 causes the PEBS enable circuit 370a-c to generate a PEBS record for the event immediately after an overflow or zero value of a fixed function performance counter 360a-c that tracks and counts programmed events occurs. In this example, the PEBS record is generated after the next instruction to retire (i.e., after the completion of the next instruction in the instruction trace that triggered the fixed function performance counter 360a-c to overflow or run to zero). In one example, the PEBS record generated by the PEBS handler circuit 308 for the event is stored in the memory storage device 330 of the PEBS handler circuit 308. Therefore, architectural metadata associated with the event can be captured without utilizing PMI. In one example, the PMI component 332 collects the PEBS records stored in the (one or more) memory storage devices 330a-330n of the PEBS handler circuit 308. The PMI component 332 can collect the PEBS records stored in the memory storage devices 330a-330n immediately. In another example, the PMI component 332 is delayed in immediately collecting the PEBS records in the memory storage devices 330a-330n. The interface may be provided as an MSR.

[0102] Applying PEBS / NPEBS / PDIR to fixed function counters 360a-c provides similar benefits as adding those features to general purpose counters 336a-n, but allows the freedom to use the general purpose counters for other activities. These and other benefits and additional features of examples of the present invention are discussed below.

[0103] The performance capability control register 380 (eg, PERF_CAPABILITIES MSR) enhances the enumeration of PMU non-architectural features. For the hybrid part, the register 380 includes fields that each contribute to indicating whether the report is common or hybrid across core types. The format example is as follows.

[0104]

[0105]

[0106] Exemplary Process for Generating and Storing PEBS Recordings

[0107] Figure 4An example of the operation 400 of a process for generating PEBS records and storing them in a memory buffer and storing the memory buffer to a PEBS trace file is illustrated. After starting, at 402, the PMU counter is set to -N. Starting with a negative value, the PMU counter in this example increments each time a PEBS record is generated until it reaches zero (0). In an alternative example not shown, the PMU counter is set to +N and decrements each time a PEBS record is generated. At 404, a number N of PEBS records are generated and stored in a PEBS memory buffer. At 406, N PEBS records 410 are stored in a PEBS trace file 414. This step is also illustrated as 230, showing the N PEBS records being stored in the PEBS trace file 414. At 408, the PEBS trace file is post-processed, after which the process ends.

[0108] Figure 5 An example of a process for programming a PEBS handler circuit to monitor processor performance and generate PEBS records to be stored in a PEBS memory buffer and then in a PEBS trace file is illustrated. After starting, at 502, a PMU counter is programmed to count function calls, such as BR_INST_RETIRED and NEAR_CALL_PS events, and overflow after N calls. At 504, the PEBS handler circuit is programmed to generate a PEBS record after each overflow, the PEBS record being configured to contain architectural metadata including state information of the processor, including but not limited to instruction pointers, timestamp counters and register states, and performance costs. Configuration of processor information monitored by the PEBS and stored in a PEBS data record. At 506, the PEBS handler circuit is enabled. At 508, a PEBS record is generated when the counter overflows and is stored in the PEBS memory buffer. At 510, a check is made to see if the PEBS memory buffer is full, if not, return to block 508, and if yes, proceed to block 512. At block 512, after the PEBS memory (eg, buffer) is filled, the PEBS memory contents are stored to a PEBS trace file. The process then ends.

[0109] In some examples, architectural performance monitoring is the range of counter MSRs in the 19xxH address range. This MSR range allows at least scaling the number of general purpose and fixed function counters beyond what is in current products. In addition, it places registers for the same counter closer to each other.

[0110] In some examples, legacy and new counters (such as those enumerated in CPUID.(EAX=23H,ECX=01H)) are supported within this address range.

[0111]

[0112] For general purpose counters (eg, performance counters 336 and / or programmable counters 184), PMC_GPn_CTRMSR holds the counter value with full width write support 1. The MSR address is 1900H+4*n. For example, the MSR address of the PMC_GP1_CTR MSR is 1904H.

[0113] The aliased register for the legacy counter is in MSR address 4C1H+n. The PMC_GPn_CFG_A MSR is the performance event select register at address 1901H+4*n. For example, the MSR address of PMC_GP1_CFG_A is 1905H. The aliased register for the legacy counter is in MSR address 186H+n

[0114] For the fixed function counters, the PMC_FXm_CTR MSR holds the counter value. The MSR address is 1980H+4*m. For example, the MSR address of IXED_CTR1 is 1984H. The alias registers for the legacy counters are in MSR address 309H+m. The available general purpose and fixed function counters are reported by CPUID.(EAX=23H,ECX=01H):EAX and CPUID.(EAX=23H,ECX=01H):EBX, respectively.

[0115] If enumerated by CPUID.(EAX=23H,ECX=0):EBX[bit 0], architectural performance monitoring can support the Unit Mask 2 (UMASK2) field in the PERFEVTSELx MSR. The UMASK2 field (e.g., bits 40 to 47) defines the conditions for detection of the selected event logic unit. The valid UMASK2 value for each event logic unit is specific to that unit. The new UMASK2 field can also be used in conjunction with UMASK. Figure 6 An example architectural performance monitoring layout (eg, unit mask 2 (UMASK2) field 608) of the PERFEVTSELx MSR is shown in FIG.

[0116] Automatic counter reloader logic (e.g., automatic counter reloader logic 190, or part of PEBS handler circuit 308) (circuitry, firmware, combinations thereof, etc.) provides software with a means of automatic counter reloading (ACR) to specify that for each supported counter, the performance monitor hardware should automatically reload the counter to a specified initial value when the selected counter overflows. This mechanism enables software to sample based on the relative rates of two (or more) events, such that sampling (PMI or PEBS) is performed only when the rate of one event exceeds a certain threshold relative to the rate of the other event. Common examples may include sampling only when the IPC (instructions per cycle) drops below a threshold or the MPKI (mispredictions per 1000 instructions) exceeds a threshold. In some examples, the threshold is user configurable.

[0117] ACR Discovery and Interface

[0118] CPUID.(EAX=23H,ECX=2):EAX indicates which programmable counters support ACR. If a programmable counter (PMCx) supports ACR, the associated PMCx_RELOAD_CFG MSR and PERFEVTSELx_EXT MSR are supported. Similarly, CPUID.(EAX=23H,ECX=2):EBX indicates which fixed counters support ACR, and each fixed counter with ACR support has a corresponding FIXED_CTRx_RELOAD_CFG MSR and FIXED_CTRx_CTRL_EXT MSR.

[0119] For a given counter PMCx, the bit fields in PMCx_RELOAD_CFG can have the following meanings:

[0120] If PMCi=1 and PMCi_RELOAD_CFG.PREVENT_RELOAD=0, then the counter PMCx is loaded with the reload value in PERFEVTSELx_EXT[31:0] when PMCi overflows.

[0121] If FIXED_CTRi = 1 and FIXED_CTRi_RELOAD_CFG.PREVENT_RELOAD = 0, then the counter PMCx is loaded with the reload value in PERFEVTSELx_EXT[31:0] when FIXED_CTRi overflows. If PREVENT_RELOAD = 1, then no counter is allowed to reload based on PMCx overflow. Overrides PMCx = 1 set in any *_RELOAD_CFG MSR.

[0122] In some examples, if the counters are frozen (PERF_GLOBAL_STATUS.COUNTERS_FROZEN=1), or if PMCx has overflowed (PERF_GLOBAL_STATUS.PMCx_OVF=1), the ACR will not reload PMCx. If PMI or PEBS is taken due to a counter overflow, the PMIISR or PEBS record can record the unmodified counter value before reloading the counter. In a race condition where the period of PMCx overflow is the same as the period of the counter configured to reload PMCx on overflow, PMCx will not be reloaded and PMCx_OVF will be set.

[0123] For counters that reload themselves (e.g., PMCx_RELOAD_CFG.PMCx=1), the overflow bit (PERF_GLOBAL_STATUS.PMCx_OVF) will never be set. Instead, upon overflow, the counter will be reloaded immediately; therefore, it is never in the overflow state. There are exceptions associated with PEBS.

[0124] This behavior is similar to the reload of a fixed counter. For FIXED_CTRx, the reload value is stored in FIXED_CTRx_EXT[31:0], and which counters cause a reload of FIXED_CTRx is configured in FIXED_CTRx_RELOAD_CFG.

[0125] In some examples, ACR reloads are not guaranteed to be accurate; in some cases, a small number of events may be lost during the time between a counter overflow and a counter reload. When an overflow of a single counter is configured to reload multiple counters, those counters are guaranteed to be reloaded simultaneously.

[0126] For counters that are configured to utilize ACR to reload the counter and take PEBS on overflow, the counter reload action will be taken only after the PEBS record has been written. This ensures that any counter value captured in the PEBS record reflects the value before the reload occurred. Because some latency is associated with PEBS record generation, this may result in more lost counts due to more time passing between counter overflow and counter reload.

[0127] For counters that are configured to reload themselves and take PEBS on overflow, the overflow bit (in PERF_GLOBAL_STATUS) associated with that counter will be set from the time the counter overflowed to the time the PEBS record was written. This is needed to ensure that the PEBS record is not lost due to a VM exit taken during record generation. Once the record is written, the overflow bit will be cleared and the counter reloaded.

[0128] When an ACR is reloaded with counters that support Precise Distribution (PDIST), the PDIST behavior is lost. With Pdist, PEBS records are generated exactly when the instruction or operation that caused the counter to overflow completes (no "wait for next occurrence" by default). Pdist is supported by selected counters, and only if those counters are programmed to count selected precise events.

[0129] The following table provides detailed examples of some MSRs.

[0130]

[0131]

[0132] Certain architecture performance monitoring (PerfMon) tools include a set of performance monitoring counters and performance event selection registers. Certain examples herein add an "equal" (EQ) flag (e.g., as bit 36 ​​of the PERFEVTSELx MSR), for example, such that when the EQ flag is set (e.g., set to 1) and the inverted counter mask (INV) flag is cleared (e.g., set to zero), the comparison of the threshold is evaluated to be true if the selected performance monitoring event is equal to the specified counter mask (Cmask) value. In some examples, when the EQ flag is set (e.g., set to 1) and the INV flag is set (e.g., set to 1), the comparison is evaluated to be true if the event is less than the Cmask value and the event is not zero. In some examples, if Cmask is zero, the EQ flag is ignored. In some examples, the equal field is referred to as a zero behavior ("Z") field.

[0133] Additionally or alternatively, some examples herein add an additional (e.g., 8-bit) unit mask field (e.g., added to bits 47:40 of the PERFEVTSELx MSR), also referred to as "UnitMask2". In some examples, this is enumerated in new feature bits 0x21.0.EBX[0]. In some examples, the UMASK2 field (e.g., bits 40 to 47) bits define the conditions for detection of a selected event logic unit. In some examples, the valid UMASK2 value for each event logic unit is specific to that unit. In some examples, the second UMASK2 field may also be used in conjunction with the first UMASK field, e.g., as Figure 6 shown.

[0134] In some examples, the IA32_PERFEVTSELx MSRs start at address 186H and occupy a contiguous block of the MSR address space. In some examples, each performance event select register is paired with a corresponding performance counter, for example, in the 0C1H address block. Note that the number of IA32_PERFEVTSELx MSRs may be different from the number of physical counters present on the hardware, for example, because an agent running at a higher privilege level (e.g., a virtual machine monitor (VMM)) may not expose all counters. In some examples, CPUID.0AH:EAX[23:16] is used to report the bit width of the IA32_PMCx MSR, for example, the number of valid bits for a read operation. In some examples, on a write operation, the lower order 32 bits of the MSR can be written with any value, and the high order bits are sign extended from the value of bit 31. In some examples, the bit field layout of the IA32_PERFEVTSELx MSR is architecturally defined.

[0135] Figure 6 An example of an architectural performance monitoring layout of a PERFEVTSELx MSR 600 is illustrated. In some examples, the PERFEVTSELx MSR 600 is 64 bits wide (e.g., as shown) or 32 bits wide. In some examples, Figure 1 Control register 185 and / or Figure 3 The control register 380 in utilizes the format of MSR 600.

[0136] In some examples, the PERFEVTSELx MSR 600 includes an event selection field, such as bits 0-7 of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the event selection field allows selection of an event logic unit for detecting microarchitectural conditions. In some examples, the set of values ​​for this field is architecturally defined, such as each value corresponds to an event logic unit used with architectural performance events. In some examples, CPUID.0AH:EAX is used to query the number of architectural events. The processor may only support a subset of predefined values.

[0137] In some examples, the PERFEVTSELx MSR 600 includes a unit mask (UMASK) field, such as bits 8-15 of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the unit mask field bits define the conditions detected by the selected event logic unit. In some examples, the effective UMASK value for each event logic unit is specific to that unit. In some examples, for each architectural performance event, its corresponding UMASK value defines a specific microarchitectural condition. In some examples, the predefined microarchitectural conditions associated with the architectural event may not apply to a given processor, for example, the processor then only reports a subset of the predefined architectural events. In some examples, the predefined architectural events are listed in the following table. In some examples, support for predefined architectural events is enumerated using CPUID.0AH:EBX.

[0138]

[0139] Table 1: Example UMask and event selection encoding for predefined architectural performance events

[0140] In some examples, PERFEVTSELx MSR 600 includes a user mode (USR) field (e.g., a bit or flag), such as bit 16 of PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the user mode field specifies that selected microarchitectural conditions are counted when the processor (e.g., a core or logical processor) operates at privilege level 1, 2, or 3. This flag can be used with the OS flag.

[0141] In some examples, PERFEVTSELx MSR 600 includes an operating system mode (OS) field (e.g., a bit or flag), such as bit 17 of PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the operating system mode field specifies that selected microarchitectural conditions are counted when the processor (e.g., a core or logical processor) operates at privilege level 0 (e.g., OS or kernel level). This flag can be used with the USR flag.

[0142] In some examples, the PERFEVTSELx MSR 600 includes an edge detection (E) field (e.g., a bit or flag), such as bit 18 of the PERFEVTSELx MSR 600 (e.g., bit index 0 to 63). In some examples, the edge detection field enables (when set) edge detection of selected microarchitectural conditions. In some examples, the processor (e.g., a core or logical processor) counts the number of transitions from de-asserted to asserted for any condition that may be expressed by the other fields. In some examples, the mechanism does not allow for distinguishing back-to-back assertions. In some examples, the mechanism allows software to measure not only the fraction of time spent in a particular state, but also the average length of time spent in such a state (e.g., the time spent waiting for an interrupt to be serviced).

[0143] In some examples, the PERFEVTSELx MSR 600 includes a pin control (PC) field (e.g., a bit or flag), such as bit 19 of the PERFEVTSELx MSR 600 (e.g., bit index 0 to 63). In some examples, the pin control field bit is reserved (not writable). In other examples, when a performance monitoring event occurs (e.g., and when the pin control field bit is cleared), the processor (e.g., a core or logical processor) (e.g., when the pin control field bit is set) triggers the PMi pin and increments the counter, and when the counter overflows, the processor (e.g., a core or logical processor) triggers the PMi pin. In some examples, the toggling of the pin is defined as the assertion of the pin followed by the de-assertion of a single bus clock.

[0144] In some examples, the PERFEVTSELx MSR 600 includes a (e.g., advanced programmable interrupt controller (ACIP)) interrupt enable (INT) field (e.g., a bit or flag), such as bit 20 of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the (e.g., ACIP) interrupt enable field, when set, causes a processor (e.g., a core or logical processor) to generate an exception through its local interrupt controller (e.g., APIC) when a counter overflows.

[0145] In some examples, the PERFEVTSELx MSR 600 includes an any thread (any) field (e.g., a bit or flag), such as bit 21 of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the any thread field is used for any processor (e.g., a processor core) that includes two or more logical processors. In some examples, when the any thread field is set to one, it enables counting of associated event conditions that occur across all logical processors sharing the processor core (e.g., including matching the thread's current privilege level (CPL) to the OS / USR setting of IA32_PERFEVTSELx). In some examples, when the any thread field is set to zero, the counter increments only the associated event condition that occurs in the logical processor that programs the IA32_PERFEVTSELx MSR (e.g., including matching the thread's CPL to the OS / USR setting of IA32_PERFEVTSELx). In some examples, each fixed function performance counter IA32_FIXED_CTRx (e.g., starting at MSR address 309H) is configured by a (e.g., 4-bit) control block in the IA32_PERF_FIXED_CTR_CTRL MSR. In some examples, the control block also allows thread specificity configuration using the "any thread" bit of fixed function counters 0, 1, and 2.

[0146] In some examples, the PERFEVTSELx MSR 600 includes an enable counter (EN) field (e.g., a bit or flag), such as bit 22 of the PERFEVTSELx MSR 600 (e.g., bit index 0 to 63). In some examples, the enable counter field enables performance counting in a corresponding performance monitoring counter when set, for example, and when cleared, the corresponding counter is disabled. In some examples, the event logic unit of the UMASK is disabled (e.g., by setting IA32_PERFEVTSELx[bit 22]=0) before writing to IA32_PMCx.

[0147] In some examples, the PERFEVTSELx MSR 600 includes an invert counter mask (INV) field (e.g., a bit or flag) 604, such as bit 23 of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the invert field 604, when set, inverts the counter mask (CMASK) comparison so that greater than or equal to and less than comparisons can be made (e.g., set to zero if greater than or equal to, and set to 1 if less than). In some examples, if the counter mask (CMASK) is programmed to zero, the INV flag is ignored. In some examples, the INV field is set as shown in the reference numeral 604. Figure 7 The logic table 700 in is used as discussed above.

[0148] In some examples, the PERFEVTSELx MSR 600 includes a counter mask (CMASK) field (e.g., bits) 606, e.g., bits 24-31 of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the counter mask field 606 (e.g., when the field is not zero) causes a processor (e.g., a core or logical processor) to compare the mask (e.g., a threshold indicated by the mask) to an event count of a detected microarchitectural condition, e.g., during a single cycle. In some examples, if the event count is greater than or equal to the mask, the counter is incremented by 1, e.g., otherwise the counter is not incremented. In some examples, the mask allows software to characterize a microarchitectural condition that may count multiple occurrences per cycle (e.g., two or more retired instructions per clock; or bus queue occupancy). In some examples, if the counter mask field is 0, the counter is incremented by the event count associated with the multiple occurrences per cycle. In some examples, the CMASK field is as described in reference to Figure 7 The logic table 700 in is used as discussed above.

[0149] In some examples, the PERFEVTSELx MSR 600 includes an in transaction region (IN_TX) field (e.g., a bit or flag), such as bit 32 of the PERFEVTSELx MSR 600 (e.g., bit index 0 to 63). In some examples, the in transaction region field, when set, causes the counter to include only counts that occur inside a transaction region, regardless of whether the region is aborted or committed. In some examples, this bit can be set only when the processor supports hardware lock elision (HLE) or restricted transactional memory (RTM).

[0150] In some examples, the PERFEVTSELx MSR 600 includes an intra-transaction exclude abort (IN_TXCP) field (e.g., a bit or flag), such as bit 33 of the PERFEVTSELx MSR 600 (e.g., bit index 0 to 63). In some examples, the intra-transaction exclude abort field, when set, causes the counter to not include counts that occur inside an aborted transaction region. In some examples, this bit can be set only when the processor supports HLE or RTM. In some examples, this bit can only be set for IA32_PERFEVTSEL2.

[0151] In some examples, the PERFEVTSELx MSR 600 includes an adaptation record (AR) field (e.g., a bit or flag), such as bit 34 of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the adaptation record field, when set, causes generation of an adaptive PEBS record (e.g., when set, modifies sample information included in the PEBS record based on the configuration of the (e.g., separate) MSR).

[0152] In some examples, the PERFEVTSELx MSR 600 includes an LBR event logging enable (LEL) field (e.g., a bit or flag), such as bit 35 of the PERFEVTSELx MSR 600 (e.g., bit index 0 to 63). In some examples, the LBR event logging enable field, when set, enables occurrences of selected events to be additionally logged in a new LBR field (e.g., the IA32_LBR_INFO.PMCx_CNT field). In some examples, the two-bit field represents the number of occurrences of the event since the last operation retirement for which an LBR entry was recorded, saturated at a value of 3.

[0153] In some examples, the PERFEVTSELx MSR 600 includes an equal (EQ) field 602 (e.g., a bit or flag), such as bit 36 ​​of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, when the EQ flag 602 is set (e.g., set to 1) (e.g., and the inverted counter mask (INV) flag 604 is cleared (e.g., set to zero)), the comparison of the threshold is evaluated to be true if the selected performance monitoring event is equal to the specified counter mask (CMask) 606 value. In some examples, when the EQ flag 602 is set (e.g., set to 1) (e.g., and the INV flag 604 is set (e.g., set to 1)), the comparison is evaluated to be true if the event is less than the CMask 606 value and the event is not zero. In some examples, if CMask is zero, the EQ flag is ignored. In some examples, the equal field is referred to as a zero behavior ("Z") field. In some examples, the EQ field is referred to as a zero behavior ("Z") field. Figure 7 The logic table 700 in is used as discussed above.

[0154] In some examples, some events may run out of available cell mask bits, such as cache events or retired branch types. Figure 6 UMASK and UMASK2 in are useful techniques to synthesize new events without wasting additional counters, for example, setting L0_HIT and L1_HIT UMasks for MEM_LOAD_RETIRED gives the total data cache (e.g., data cache unit (DCU)) hits.

[0155] In some examples, the PERFEVTSELx MSR 600 includes a second unit mask (UMASK2) field 608, such as bits 40-47 of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63). In some examples, the second unit mask (UMASK2) field 608 (i) allows indication of more / additional events and / or allows more events, and / or (ii) allows Figure 6 Combine with other UMASKs in to synthesize new events.

[0156] In some examples, the value "N" (e.g., a threshold) stored in the counter mask (CMASK) field 606 causes a performance monitor (e.g., a counter for monitored events) to increment (or decrement) a counter when greater than or equal to "N" number of those monitored events (e.g., any of the events discussed herein) occur, for example, in the same cycle. In some examples, this helps count certain pipeline conditions, such as FETCH.UOPS:CMASK=6 counting when peak fetch bandwidth is reached in a 6-wide core.

[0157] In some examples, instead, invert counter mask (INV) flag 604 is set (e.g., to 1) so that a performance monitor (e.g., a counter for monitored events) increments (or decrements) a counter when less than "N" number of events occur, e.g., in the same cycle. In some examples, this helps count certain pipeline conditions, e.g., FETCH.UOPS:CMASK=1:INV=1 counts starvation cycles (e.g., fetched micro-operations (uops) are not delivered).

[0158] However, some patterns are difficult to express directly, e.g., cycles that are less than N but greater than 0, or cycles that have exactly N occurrences. In some examples, "FETCH.UOPS:CMASK=1–FETCH.UOPS:CMASK=6" counts fetch bandwidth (BW) cycles (e.g., a suboptimal number of uops delivered), e.g., as a metric in top-down profiling, but this requires using two counters and subtractions, which means they cannot be sampled, and also wastes scarce counter resources in some examples.

[0159] To overcome these problems, some examples herein utilize the equals field 602 to implement Figure 7 700. In some examples, the equals field 602 is referred to as a zero behavior ("Z") field. In some examples, the PERFEVTSELx MSR 600 includes an equals (EQ) field (e.g., a bit or flag) 602, such as bit 36 ​​of the PERFEVTSELx MSR 600 (e.g., bit indexes 0 to 63).

[0160] Figure 7 The diagram shows the use of the PERFEVTSELx MSR (for example, Figure 6 600). In some examples, in a (eg, single) control register (eg, Figure 1 188 in the control register 188) using the equal field (e.g., Figure 6EQ bit 602 in ), the invert counter mask field (e.g., Figure 6 INV bit 604 in ) and counter mask field 606 (e.g., Figure 6 The CMASK field 606 in the _A_CONTENT_SCHEMA_01_01_01_01_01_02_01_02_03_01_03 ... Figure 1 In some examples, incrementing is mentioned, but it should be understood that in other examples, the counter can be decremented. In some examples, the counter is incremented and / or decremented by a value of 1.

[0161] Although eight modes (eg, eight rows) are depicted in logic table 700 (eg, truth table), it should be understood that one mode or any combination of modes may be implemented for performance monitoring.

[0162] In some examples, the first mode, the third mode, the fifth mode, and the seventh mode (e.g., as shown in the corresponding rows of the logic table 700) are indicated by the EQ flag 602 being cleared (e.g., set to zero). In some examples, the counter mask (CMASK) field 606 is cleared (e.g., set to zero) so that the EQ flag 602 and the INV flag 604 are ignored, such as to cause the corresponding counter to be incremented (e.g., by 0) for each occurrence "X" of the corresponding (e.g., selected) performance monitoring event. Figure 1 Performance monitor 180 in ).

[0163] In some examples, the second mode (e.g., as shown in the corresponding row of the logic table 700) is indicated by the EQ flag 602 being cleared (e.g., set to zero), the inverted counter mask (INV) flag 604 being cleared (e.g., set to zero), and the counter mask (CMASK) field 606 being set to a non-zero value "N" (e.g., an integer), so that the corresponding counter is incremented (e.g., by a value of "N") only when the corresponding (e.g., selected) performance monitoring event count (e.g., in a single cycle) is equal to or greater than the specified counter mask (CMask) 606 value. Figure 1 Performance monitor 180 in ).

[0164] In some examples, a fourth mode (e.g., as shown in a corresponding row of logic table 700) is indicated by EQ flag 602 being cleared (e.g., set to zero), inverted counter mask (INV) flag 604 being set (e.g., set to 1), and counter mask (CMASK) field 606 being set to a non-zero value "N" (e.g., an integer), such that the corresponding counter is incremented (e.g., by a value greater than or equal to 0) only when the corresponding (e.g., selected) performance monitoring event count (e.g., in a single cycle) (including zero) is less than the specified counter mask (CMask) 606 value. Figure 1 Performance monitor 180 in ).

[0165] In some examples, the sixth mode (e.g., as shown in the corresponding row of logic table 700) is indicated by the EQ flag 602 being set (e.g., set to 1), the inverted counter mask (INV) flag 604 being cleared (e.g., set to zero), and the counter mask (CMASK) field 606 being set to a non - zero value "N" (e.g., an integer), such that the corresponding counter increments only when the corresponding (e.g., selected) performance monitoring event count (e.g., in a single cycle) equals the specified counter mask (CMask) 606 value (e.g., by the performance monitor 180 in Figure 1 ). (e.g., but does not increment if the event count is greater than or less than the CMask value).

[0166] In some examples, the eighth mode (e.g., as shown in the corresponding row of logic table 700) is indicated by the EQ flag 602 being set (e.g., set to 1), the inverted counter mask (INV) flag 604 being set (e.g., set to 1), and the counter mask (CMASK) field 606 being set to a non - zero value "N" (e.g., an integer), such that the corresponding counter increments only when the corresponding (e.g., selected) performance monitoring event count (e.g., in a single cycle) is greater than zero and less than the specified counter mask (CMask) 606 value (e.g., within the specified range of values) (e.g., by the performance monitor 180 in Figure 1 ). (e.g., but does not increment if the event count is zero or greater than the CMask value).

[0167] In some examples, the performance counter (e.g., the MSR for controlling the performance counter) has a counter mask (CMask) 606 field to express a threshold number of events in a cycle. In some examples, the equals bit 602 (e.g., the EQ bit or z bit) [e.g., bit 36] is used to change the zero behavior (e.g., when EQ = 1, Cmask = N, INV = 0: count cycles when increment == N; when EQ = 1, Cmask = N, INV = 1: count cycles when increment < N and increment > 0 (e.g., where the INV bit only applies to CMASK, and the EQ bit only applies when CMASK is non - zero). In some examples, EQ = 0 maintains legacy behavior.

[0168] In some examples, this functionality is enumerated in the new feature bit 0x21.0.EBX[1] (e.g., shown in the corresponding row(s) of logic table 700). In some examples, the use of the EQ bit allows expressing certain (e.g., common) modes with one counter, and the EQ bit enables sampling constructs with multiple counters.

[0169] Some examples utilize the instruction formats described herein. Some instructions support 8-bit immediate values. Some instructions support 32-bit immediate values. Some examples are implemented in one or more computer architectures, cores, accelerators, etc. Some examples are generated or are IP cores. Some examples utilize emulation and / or translation.

[0170] At least some examples of the disclosed technology may be described in view of the following examples:

[0171] In a first set of examples, an apparatus (e.g., a processor) includes: an execution circuit for executing one or more instructions; a performance monitoring counter; a control register including a threshold field; and a performance monitor control circuit for incrementing the performance monitoring counter in response to a performance monitoring event of the one or more instructions being equal to but not greater than the threshold field. In some examples, the threshold field is a counter mask field of the control register. In some examples, the control register includes a mode field, and the performance monitor control circuit is used to increment the performance monitoring counter in response to the mode field being set to a first mode in response to the performance monitoring event being equal to but not greater than the threshold field. In some examples, the mode field set to the first mode includes an equal field of the control register set to 1 and an invert field of the control register set to 0. In some examples, in response to the mode field of the control register being set to a second mode, the performance monitor control circuit is used to increment the performance monitoring counter in response to the performance monitoring event being greater than zero and less than (e.g., but not equal to) the threshold field. In some examples, the mode field set to the second mode includes an equal field of the control register set to 1 and an invert field of the control register set to 1. In some examples, the control register includes a first cell mask field in a first half of the control register and a second cell mask field in a second half of the control register.

[0172] In another set of examples, a method includes: executing one or more instructions by an execution circuit of a processor; setting a threshold field of a control register of the processor; and incrementing a performance monitoring counter by a performance monitor control circuit of the processor in response to a performance monitoring event of the one or more instructions being equal to but not greater than the threshold field. In some examples, the threshold field is a counter mask field of the control register. In some examples, the method further includes setting a mode field of the control register to a first mode, wherein the incrementing by the performance monitor control circuit in response to a performance monitoring event being equal to but not greater than the threshold field is in response to the mode field being set to the first mode. In some examples, setting the mode field to the first mode includes setting an equal field of the control register to 1 and setting an invert field of the control register to 0. In some examples, the method further includes: setting a mode field of the control register to a second mode; and incrementing a performance monitoring counter by the performance monitor control circuit in response to the mode field being set to the second mode in response to a performance monitoring event being greater than zero and less than the threshold field. In some examples, setting the mode field to the second mode includes setting an equal field of the control register to 1 and setting an invert field of the control register to 1. In some examples, the control register includes a first cell mask field in a first half of the control register and a second cell mask field in a second half of the control register.

[0173] In yet another set of examples, an apparatus (e.g., a processor) includes: a memory; an execution circuit for executing one or more instructions on data accessed in the memory; a performance monitoring counter; a control register including a threshold field; and a performance monitor control circuit for incrementing the performance monitoring counter in response to a performance monitoring event of the one or more instructions being equal to but not greater than the threshold field. In some examples, the threshold field is a counter mask field of the control register. In some examples, the control register includes a mode field, and the performance monitor control circuit is used to increment the performance monitoring counter in response to the mode field being set to a first mode in response to the performance monitoring event being equal to but not greater than the threshold field. In some examples, the mode field set to the first mode includes an equal field of the control register set to 1 and an invert field of the control register set to 0. In some examples, in response to the mode field of the control register being set to a second mode, the performance monitor control circuit is used to increment the performance monitoring counter in response to the performance monitoring event being greater than zero and less than (e.g., but not equal to) the threshold field. In some examples, the mode field set to the second mode includes an equal field of the control register set to 1 and an invert field of the control register set to 1. In some examples, the control register includes a first cell mask field in a first half of the control register and a second cell mask field in a second half of the control register.

[0174] Exemplary architectures, systems, etc., in which the above may be used are described in detail below.

[0175] Example Architecture

[0176] The example computer architecture is described in detail below. Other system designs and configurations for laptop, desktop and handheld personal computers (PCs), personal digital assistants, engineering workstations, servers, disaggregated servers, network devices, network hubs, switches, routers, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices known in the art are also suitable. In general, various systems or electronic devices that can incorporate processors and / or other execution logic disclosed herein are generally suitable.

[0177] Example System

[0178] Figure 8An example computing system is illustrated. Multiprocessor system 800 is an interface system and includes multiple processors or cores, including a first processor 870 and a second processor 880 coupled via an interface 850, such as a point-to-point (PP) interconnect, structure and / or bus. In some examples, the first processor 870 and the second processor 880 are homogeneous. In some examples, the first processor 870 and the second processor 880 are heterogeneous. Although example system 800 is shown as having two processors, the system can have three or more processors, or can be a single processor system. In some examples, the computing system is a system on chip (SoC). Processors 870 and 880 are shown as including integrated memory controller (IMC) circuit systems 872 and 882, respectively. Processor 870 also includes interface circuits 876 and 878; similarly, second processor 880 includes interface circuits 886 and 888. Processors 870, 880 can exchange information via interface 850 using interface circuits 878, 888. IMCs 872 and 882 couple processors 870, 880 to respective memories, namely memory 832 and memory 834, which may be portions of main memory locally attached to the respective processors.

[0179] Processors 870, 880 can each exchange information with a network interface (NW I / F) 890 via individual interfaces 852, 854 using interface circuits 876, 894, 886, 898. Network interface 890 (e.g., one or more of an interconnect, bus, and / or fabric, and in some examples a chipset) can optionally exchange information with a coprocessor 838 via interface circuit 892. In some examples, coprocessor 838 is a special-purpose processor, such as, for example, a high-throughput processor, a network or communication processor, a compression engine, a graphics processor, a general-purpose graphics processing unit (GPGPU), a neural network processing unit (NPU), an embedded processor, etc.

[0180] A shared cache (not shown) may be included in either processor 870, 880, or external to both processors but connected to the processors via an interface such as a PP interconnect, such that if the processors are placed in a low power mode, local cache information of either or both processors may be stored in the shared cache.

[0181] The network interface 890 can be coupled to the first interface 816 via the interface circuit 896. In some examples, the first interface 816 can be an interface such as a peripheral component interconnect (PCI) interconnect, a PCI Express interconnect, or another I / O interconnect. In some examples, the first interface 816 is coupled to a power control unit (PCU) 817, which can include circuit systems, software, and / or firmware to perform power management operations with respect to the processors 870, 880, and / or the coprocessor 838. The PCU 817 provides control information to a voltage regulator (not shown) so that the voltage regulator generates an appropriate regulated voltage. The PCU 817 also provides control information to control the generated operating voltage. In various examples, the PCU 817 can include various power management logic units (circuitry systems) to perform hardware-based power management. Such power management can be completely controlled by the processor (e.g., controlled by various processor hardware and can be triggered by workload and / or power, thermal or other processor constraints), and / or power management can be performed in response to an external source (such as a platform or power management source or system software).

[0182] The PCU 817 is illustrated as existing as logic separate from the processor 870 and / or the processor 880. In other cases, the PCU 817 may execute on a given core or cores (not shown) of the processor 870 or 880. In some cases, the PCU 817 may be implemented as a microcontroller (dedicated or general purpose) or other control logic configured to execute its own dedicated power management code (sometimes referred to as P-code). In still other examples, the power management operations to be performed by the PCU 817 may be implemented external to the processor, such as by a separate power management integrated circuit (PMIC) or another component external to the processor. In still other examples, the power management operations to be performed by the PCU 817 may be implemented within the BIOS or other system software.

[0183] Various I / O devices 814 may be coupled to the first interface 816 along with a bus bridge 818, which couples the first interface 816 to the second interface 820. In some examples, one or more additional processors 815, such as a coprocessor, a high-throughput multi-integrated core (MIC) processor, a GPGPU, an accelerator (such as a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor, are coupled to the first interface 816. In some examples, the second interface 820 may be a low pin count (LPC) interface. Various devices may be coupled to the second interface 820, including, for example, a keyboard and / or mouse 822, a communication device 827, and a storage circuit system 828. The storage circuit system 828 may be one or more non-transitory machine-readable storage media as described below, such as a disk drive or other mass storage device, which may include instructions / codes and data 830, and in some examples may implement a storage device 828. In addition, an audio I / O 824 may be coupled to the second interface 820. Note that other architectures besides the point-to-point architecture described above are also possible. For example, instead of a point-to-point architecture, a system such as multiprocessor system 800 may implement a multi-point interface or other such architecture.

[0184] Example core architectures, processors, and computer architectures.

[0185] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) a general-purpose in-order core intended for general-purpose computing; 2) a high-performance general-purpose out-of-order core intended for general-purpose computing; 3) a special-purpose core intended primarily for graphics and / or scientific (throughput) computing. Different processor implementations may include: 1) a CPU including one or more general-purpose in-order cores intended for general-purpose computing and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor including one or more special-purpose cores intended primarily for graphics and / or scientific (throughput) computing. Such different processors produce different computer system architectures, which can include: 1) a coprocessor on a chip separate from the CPU; 2) a coprocessor on a separate die in the same package as the CPU; 3) a coprocessor on the same die as the CPU (in which case such coprocessors are sometimes referred to as dedicated logic (such as integrated graphics and / or scientific (throughput) logic) or dedicated cores); and 4) a system on a chip (SoC), which can be included on the same die as the described CPU (sometimes referred to as (one or more) application cores or (one or more) application processors), the above coprocessors, and additional functionality. An example core architecture is described next, followed by a description of an example processor and computer architecture.

[0186] Fig. 9 A block diagram of an example processor and / or SoC 900 is illustrated, which may have one or more cores and an integrated memory controller. The solid lined box illustrates a processor 900 having a single core 902(A), a system agent unit circuitry 910, and a set of one or more interface controller unit circuitry 916, while the optional addition of the dashed lined box illustrates an alternative processor 900 having multiple cores 902(A)-(N), a set of one or more integrated memory controller unit circuitry 914 in the system agent unit circuitry 910, dedicated logic 908, and a set of one or more interface controller unit circuitry 916. Note that the processor 900 may be Figure 8 One of the processors 870 or 880 or the coprocessors 838 or 815.

[0187] Thus, different implementations of processor 900 may include: 1) a CPU having dedicated logic 908, which is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and which has cores 902(A)-(N), which are one or more general-purpose cores (e.g., general-purpose in-order cores, general-purpose out-of-order cores, a combination of both); 2) a coprocessor having cores 902(A)-(N), which are a large number of dedicated cores intended primarily for graphics and / or scientific (throughput); and 3) a coprocessor having cores 902(A)-(N), which are a large number of general-purpose in-order cores. Thus, processor 900 may be a general-purpose processor, a coprocessor, or a dedicated processor, such as, for example, a network or communication processor, a compression engine, a graphics processor, a GPGPU (general-purpose graphics processing unit), a high-throughput multi-integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. The processor 900 may be part of and / or may be implemented on one or more substrates using any of a variety of process technologies, such as, for example, complementary metal oxide semiconductor (CMOS), bipolar CMOS (BiCMOS), P-type metal oxide semiconductor (PMOS), or N-type metal oxide semiconductor (NMOS).

[0188] The memory hierarchy includes one or more levels (one or more) of cache unit circuitry 904(A)-(N) within the cores 902(A)-(N), a set of one or more shared cache unit circuitry 906, and external memory (not shown) coupled to a set of integrated memory controller unit circuitry 914. The set of one or more shared cache unit circuitry 906 may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, such as a last level cache (LLC), and / or combinations thereof. While in some examples, the interface network circuitry 912 (e.g., a ring interconnect) interfaces with the dedicated logic 908 (e.g., integrated graphics logic), the set of (one or more) shared cache unit circuitry 906, and the system agent unit circuitry 910, alternative examples use any number of well-known techniques to interface with these units. In some examples, coherency is maintained between the cores 902(A)-(N) and one or more of the (one or more) shared cache unit circuitry 906. In some examples, interface controller unit circuitry 916 couples core 902 to one or more other devices 918, such as one or more I / O devices, storage, one or more communication devices (e.g., wireless networking, wired networking, etc.), and the like.

[0189] In some examples, one or more of the cores 902(A)-(N) are capable of multithreading. System agent unit circuitry 910 includes those components that coordinate and operate the cores 902(A)-(N). System agent unit circuitry 910 may include, for example, power control unit (PCU) circuitry and / or display unit circuitry (not shown). The PCU may be or may include logic and components and / or dedicated logic 908 (e.g., integrated graphics logic) required to regulate the power state of the cores 902(A)-(N). The display unit circuitry is used to drive one or more externally connected displays.

[0190] The cores 902(A)-(N) may be homogeneous in terms of instruction set architecture (ISA). Alternatively, the cores 902(A)-(N) may be heterogeneous in terms of ISA; that is, a subset of the cores 902(A)-(N) may be able to execute an ISA, while other cores may only be able to execute a subset of that ISA or another ISA.

[0191] Fig.101 is a block diagram illustrating a computing system 1000 configured to implement one or more aspects of the examples described herein. The computing system 1000 includes a processing subsystem 1001 having one or more processors 1002 and a system memory 1004 communicating via an interconnect path, which may include a memory hub 1005. The memory hub 1005 may be a separate component within a chipset component, or may be integrated within one or more processors 1002. The memory hub 1005 is coupled to an I / O subsystem 1011 via a communication link 1006. The I / O subsystem 1011 includes an I / O hub 1007, which may enable the computing system 1000 to receive input from one or more input devices 1008. In addition, the I / O hub 1007 may enable a display controller (which may be included in one or more processors 1002) to provide output to one or more display devices 1010A. In some examples, one or more display devices 1010A coupled to I / O hub 1007 may include local, internal, or embedded display devices.

[0192] The processing subsystem 1001 includes, for example, one or more parallel processors 1012 coupled to a memory hub 1005 via a bus or other communication link 1013. The communication link 1013 can be one of any number of standard-based communication link technologies or protocols, such as but not limited to PCI Express, or can be a vendor-specific communication interface or communication structure. The one or more parallel processors 1012 can form a parallel or vector processing system in a computational concentration that can include a large number of processing cores and / or processing clusters, such as a multi-integrated core (MIC) processor. For example, the one or more parallel processors 1012 form a graphics processing subsystem that can output pixels to one of the one or more display devices 1010A coupled via the I / O hub 1007. The one or more parallel processors 1012 can also include a display controller and a display interface (not shown) to enable direct connection to one or more display devices 1010B.

[0193] Within the I / O subsystem 1011, a system storage unit 1014 may be connected to the I / O hub 1007 to provide a storage mechanism for the computing system 1000. An I / O switch 1016 may be used to provide an interface mechanism to enable connections between the I / O hub 1007 and other components, such as a network adapter 1018 and / or a wireless network adapter 1019 that may be integrated into the platform, and various other devices that may be added via one or more plug-in devices 1020. The plug-in device(s) 1020 may also include, for example, one or more external graphics processor devices, graphics cards, and / or computing accelerators. The network adapter 1018 may be an Ethernet adapter or another wired network adapter. The wireless network adapter 1019 may include one or more of the following: Wi-Fi, Bluetooth, near field communication (NFC), or other network devices including one or more wireless radio devices.

[0194] The computing system 1000 may include other components not explicitly shown, including USB or other port connections, optical storage drives, video capture devices, etc., which may also be connected to the I / O hub 1007. Fig.10 The communication paths interconnecting the various components in the system may be implemented using any suitable protocol, such as a PCI (Peripheral Component Interconnect) based protocol (e.g., PCI Express), or any other bus, or point-to-point communication interface and / or protocol(s), such as NVLink high-speed interconnect, Compute Express Link™ (CXL), or any other bus ... TM ) (e.g., CXL.mem), Infinity Fabric (IF), Ethernet (IEEE 802.3), Remote Direct Memory Access (RDMA), InfiniBand (InfiniBand), Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Quick UDP Internet Connection (QUIC), RDMA over Converged Ethernet (RoCE), Intel Quick Path Interconnect (QPI), Intel Ultra Path Interconnect (UPI), Intel System-on-Chip Fabric (IOSF), Omnipath, HyperTransport, Advanced Microcontroller Bus Architecture (AMBA) Interconnect, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G and variants thereof, or a wired or wireless interconnect protocol known in the art. In some examples, data may be copied or stored to a virtualized storage node using a protocol such as Non-Volatile Memory Express (NVMe) (NVME-oF) or NVMe over Fabric.

[0195] One or more parallel processors 1012 may be incorporated into a circuit system optimized for graphics and video processing (including, for example, video output circuits) and constitute a graphics processing unit (GPU). Alternatively or additionally, as described in more detail herein, one or more parallel processors 1012 may be incorporated into a circuit optimized for general-purpose processing while retaining the underlying computing architecture. The components of the computing system 1000 may be integrated with one or more other system elements on a single integrated circuit. For example, one or more parallel processors 1012, a memory hub 1005, (one or more) processors 1002, and an I / O hub 1007 may be integrated into a system-on-chip (SoC) integrated circuit. Alternatively, the components of the computing system 1000 may be integrated into a single package to form a system in package (SIP) configuration. In some examples, at least a portion of the components of the computing system 1000 may be integrated into a multi-chip module (MCM), which may be interconnected with other multi-chip modules into a modular computing system.

[0196] It will be appreciated that the computing system 1000 shown herein is illustrative, and variations and modifications are possible. The connection topology, including the number and arrangement of bridges, the number of (one or more) processors 1002, and the number of (one or more) parallel processors 1012, may be modified as desired. For example, the system memory 1004 may be connected to the (one or more) processors 1002 directly rather than through a bridge, while other devices communicate with the system memory 1004 via the memory hub 1005 and the (one or more) processors 1002. In other alternative topologies, the (one or more) parallel processors are connected to the I / O hub 1007 or directly to one of the one or more processors 1002, rather than to the memory hub 1005. In other examples, the I / O hub 1007 and the memory hub 1005 may be integrated into a single chip. It is also possible that two or more sets of (one or more) processors 1002 are attached via multiple slots, which can be coupled to two or more instances of (one or more) parallel processors 1012.

[0197] Some of the specific components shown herein are optional and may not be included in all implementations of computing system 1000. For example, any number of plug-in cards or peripherals may be supported, or some components may be eliminated. In addition, some architectures may be specific to the Fig.10 Different terminology is used for components similar to those illustrated in FIG. 1004. For example, memory hub 1005 may be referred to as a north bridge in some architectures, while I / O hub 1007 may be referred to as a south bridge.

[0198] Fig.11AAn example of a parallel processor 1100 is illustrated. The parallel processor 1100 may be a GPU, a GPGPU, etc. as described herein. The various components of the parallel processor 1100 may be implemented using one or more integrated circuit devices, such as a programmable processor, an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA). The illustrated parallel processor 1100 may be Fig.10 One or more of the parallel processor(s) 1012 shown in FIG.

[0199] The parallel processor 1100 includes a parallel processing unit 1102. The parallel processing unit includes an I / O unit 1104 that enables communication with other devices, including other instances of the parallel processing unit 1102. The I / O unit 1104 can be directly connected to other devices. For example, the I / O unit 1104 is connected to other devices via the use of a hub or switch interface (such as, a memory hub 1005). The connection between the memory hub 1005 and the I / O unit 1104 forms a communication link 1013. Within the parallel processing unit 1102, the I / O unit 1104 is connected to a host interface 1106 and a memory crossbar 1116, wherein the host interface 1106 receives commands related to performing processing operations and the memory crossbar 1116 receives commands related to performing memory operations.

[0200] When the host interface 1106 receives the command buffer via the I / O unit 1104, the host interface 1106 can direct the work operations for executing those commands to the front end 1108. In some examples, the front end 1108 is coupled with a scheduler 1110, which is configured to distribute commands or other work items to the processing cluster array 1112. The scheduler 1110 ensures that the processing cluster array 1112 is properly configured and in a valid state before the task is distributed to the processing clusters in the processing cluster array 1112. The scheduler 1110 can be implemented via firmware logic executed on a microcontroller. The microcontroller-implemented scheduler 1110 can be configured to perform complex scheduling and work distribution operations at coarse and fine granularity, thereby achieving fast preemption and context switching of threads executed on the processing cluster array 1112. Preferably, the host software can confirm the workload for scheduling on the processing cluster array 1112 via one of a plurality of graphics processing doorbells. In other examples, polling for new workloads or interrupts may be used to identify or indicate the availability of work to be performed.The workload may then be automatically distributed across the processing cluster array 1112 by the scheduler 1110 logic within the scheduler microcontroller.

[0201] The processing cluster array 1112 may include up to "N" processing clusters (e.g., cluster 1114A, cluster 1114B to cluster 1114N). Each cluster 1114A-1114N in the processing cluster array 1112 may execute a large number of concurrent threads. The scheduler 1110 may use various scheduling and / or work distribution algorithms to assign work to the clusters 1114A-1114N in the processing cluster array 1112, which may vary depending on the workload generated for each type of program or calculation. Scheduling may be handled dynamically by the scheduler 1110, or may be partially assisted by compiler logic during the compilation of program logic configured for execution by the processing cluster array 1112. Optionally, different clusters 1114A-1114N in the processing cluster array 1112 may be assigned to process different types of programs or to perform different types of calculations.

[0202] Processing cluster array 1112 may be configured to perform various types of parallel processing operations. For example, processing cluster array 1112 is configured to perform general-purpose parallel computing operations. For example, processing cluster array 1112 may include logic for performing processing tasks including filtering of video and / or audio data, performing modeling operations including physical operations, and performing data transformations.

[0203] Processing cluster array 1112 is configured to perform parallel graphics processing operations. In such examples where parallel processor 1100 is configured to perform graphics processing operations, processing cluster array 1112 may include additional logic for supporting the execution of such graphics processing operations, including but not limited to texture sampling logic for performing texture operations, and tessellation logic and other vertex processing logic. In addition, processing cluster array 1112 may be configured to execute graphics processing related shader programs, such as but not limited to vertex shaders, tessellation shaders, geometry shaders, and pixel shaders. Parallel processing unit 1102 may transfer data from system memory via I / O unit 1104 for processing. The transferred data may be stored in on-chip memory (e.g., parallel processor memory 1122) during processing, and then the data may be written back to system memory.

[0204] In examples where parallel processing units 1102 are used to perform graphics processing, scheduler 1110 may be configured to divide the processing workload into tasks of approximately equal size to better achieve the distribution of graphics processing operations to multiple clusters 1114A-1114N in processing cluster array 1112. In some of these examples, portions of processing cluster array 1112 may be configured to perform different types of processing. For example, a first portion may be configured to perform vertex shading and topology generation, a second portion may be configured to perform tessellation and geometry shading, and a third portion may be configured to perform pixel shading or other screen space operations to produce a rendered image for display. Intermediate data generated by one or more of clusters 1114A-1114N may be stored in a buffer to allow the intermediate data to be transferred between clusters 1114A-1114N for further processing.

[0205] During operation, the processing cluster array 1112 may receive processing tasks to be executed via the scheduler 1110, which receives commands defining the processing tasks from the front end 1108. For graphics processing operations, the processing tasks may include indices of data to be processed (e.g., surface (patch) data, primitive data, vertex data, and / or pixel data) and state parameters and commands defining how the data is to be processed (e.g., what program is to be executed). The scheduler 1110 may be configured to fetch an index corresponding to a task, or may receive an index from the front end 1108. The front end 1108 may be configured to ensure that the processing cluster array 1112 is configured to a valid state before a workload specified by an incoming command buffer (e.g., a batch buffer, a push buffer, etc.) is initiated.

[0206] Each of the one or more instances of the parallel processing unit 1102 may be coupled to a parallel processor memory 1122. The parallel processor memory 1122 may be accessed via a memory crossbar switch 1116, which may receive memory requests from the processing cluster array 1112 and the I / O unit 204. The memory crossbar switch 1116 may access the parallel processor memory 1122 via a memory interface 1118. The memory interface 1118 may include a plurality of partition units (e.g., partition unit 1120A, partition unit 1120B, through partition unit 1120N), each of which may be coupled to a portion (e.g., a memory cell) of the parallel processor memory 1122. The number of partition units 1120A-1120N may be configured to be equal to the number of memory cells, such that a first partition unit 1120A has a corresponding first memory cell 1124A, a second partition unit 1120B has a corresponding second memory cell 1124B, and an Nth partition unit 1120N has a corresponding Nth memory cell 1124N. In other examples, the number of partition units 1120A-1120N may not be equal to the number of memory devices.

[0207] The memory units 1124A-1124N may include various types of memory devices, including dynamic random access memory (DRAM) or graphics random access memory, such as synchronous graphics random access memory (SGRAM), including graphics double data rate (GDDR) memory. Optionally, the memory units 1124A-1124N may also include 3D stacked memory, including but not limited to high bandwidth memory (HBM). Those skilled in the art will appreciate that the specific implementation of the memory units 1124A-1124N may vary and may be selected from one of a variety of conventional designs. Rendering targets such as frame buffers or texture maps may be stored across the memory units 1124A-1124N, allowing the partition units 1120A-1120N to write portions of each rendering target in parallel to efficiently use the available bandwidth of the parallel processor memory 1122. In some examples, local instances of the parallel processor memory 1122 may be excluded to facilitate the use of a unified memory design of the system memory in conjunction with the local cache memory.

[0208] Optionally, any of the clusters 1114A-1114N in the processing cluster array 1112 has the capability to process data to be written to any of the memory units 1124A-1124N within the parallel processor memory 1122. The memory crossbar 1116 may be configured to transmit the output of each cluster 1114A-1114N to any partition unit 1120A-1120N or to another cluster 1114A-1114N, which may perform additional processing operations on the output. Each cluster 1114A-1114N may communicate with a memory interface 1118 via the memory crossbar 1116 to read from or write to various external memory devices. In one example having a memory crossbar switch 1116, the memory crossbar switch 1116 has connections to a memory interface 1118 to communicate with the I / O unit 1104, and has connections to a local instance of a parallel processor memory 1122, thereby enabling processing units within different processing clusters 1114A-1114N to communicate with system memory or other memory that is not local to the parallel processing unit 1102. In general, the memory crossbar switch 1116 may be able to separate traffic flows between the clusters 1114A-1114N and the partition units 1120A-1120N using virtual channels, for example.

[0209] Although a single instance of parallel processing unit 1102 is illustrated within parallel processor 1100, any number of instances of parallel processing unit 1102 may be included. For example, multiple instances of parallel processing unit 1102 may be provided on a single plug-in card, or multiple plug-in cards may be interconnected. For example, parallel processor 1100 may be a plug-in device, such as Fig.10Plug-in device 1020, which can be a graphics card (such as, including one or more GPUs, one or more memory devices, and a discrete graphics card of a device-to-device or network or structure interface). Different instances of parallel processing unit 1102 can be configured to interoperate even if different instances have different numbers of processing cores, different amounts of local parallel processor memory, and / or other configuration differences. Optionally, some instances of parallel processing unit 1102 can include higher precision floating point units relative to other instances. Systems incorporating one or more instances of parallel processing unit 1102 or parallel processor 1100 can be implemented in various configurations and form factors, including but not limited to desktop computers, laptop computers, or handheld personal computers, servers, workstations, game consoles, and / or embedded systems. An orchestrator can use one or more of the following to form a composite node for workload execution: deaggregated processor resources, cache resources, memory resources, storage resources, and networking resources.

[0210] In some examples, the parallel processing unit 1102 can be partitioned into multiple instances. Those multiple instances can be configured to execute workloads associated with different clients in an isolated manner, so that a predetermined quality of service can be provided for each client. For example, each cluster 1114A-1114N can be compartmentalized and isolated from other clusters, thereby allowing the processing cluster array 1112 to be divided into multiple computing partitions or instances. In this configuration, the workload executed on the isolated partition is protected from failures or errors associated with different workloads executed on different partitions. Partition units 1120A-1120N can be configured to enable dedicated and / or isolated paths to memory for clusters 1114A-1114N associated with corresponding computing partitions. This data path isolation enables computing resources within a partition to communicate with one or more assigned memory units 1124A-1124N without being disturbed by the activities of other partitions.

[0211] Fig. 11B is a block diagram of the partition unit 1120. The partition unit 1120 may be Fig.11A1120N. As illustrated, partition unit 1120 includes L2 cache 1121, frame buffer interface 1125, and ROP 1126 (raster operation unit). L2 cache 1121 is a read / write cache configured to perform load and store operations received from memory crossbar switch 1116 and ROP 1126. Read misses and urgent writeback requests are output by L2 cache 1121 to frame buffer interface 1125 for processing. Updates may also be sent to the frame buffer via frame buffer interface 1125 for processing. In some examples, frame buffer interface 1125 communicates with memory units in parallel processor memory (such as, for example, within parallel processor memory 1122). Fig.11A Partition unit 1120 may also additionally or alternatively interface with one of the memory units in the parallel processor memory via a memory controller (not shown).

[0212] In graphics applications, ROP 1126 is a processing unit that performs rasterization operations such as stenciling, z-testing, blending, etc. ROP 1126 then outputs processed graphics data, which is stored in graphics memory. In some examples, ROP 1126 includes or is coupled to CODEC 1127, which includes compression logic for compressing depth or color data written to memory or L2 cache 1121 and decompressing depth or color data read from memory or L2 cache 1121. The compression logic can be lossless compression logic that utilizes one or more of a variety of compression algorithms. The type of compression performed by CODEC 1127 can vary based on the statistical characteristics of the data to be compressed. For example, in some examples, delta color compression is performed on depth and color data on a per-tile basis. In some examples, CODEC 1127 includes compression and decompression logic that can compress and decompress computational data associated with machine learning operations. CODEC 1127 can, for example, compress sparse matrix data for sparse machine learning operations. CODEC 1127 can also compress sparse matrix data encoded in a sparse matrix format (e.g., coordinate list encoding (COO), compressed sparse rows (CSR), compressed sparse columns (CSC), etc.) to generate compressed and encoded sparse matrix data. The compressed and encoded sparse matrix data can be decompressed and / or decoded before being processed by a processing element, or a processing element can be configured to consume compressed, encoded, or compressed and encoded data for processing.

[0213] ROP 1126 may be included in each processing cluster (e.g., Fig.11A 114A-1114N) rather than being included in partition unit 1120. In this example, read and write requests for pixel data rather than pixel fragment data are transmitted through memory crossbar switch 1116. The processed graphics data can be displayed on a display device (such as, Fig.10 1010B), is routed for further processing by (one or more) processors 1002, or is routed for processing by Fig.11A One of the processing entities within the parallel processor 1100 further processes.

[0214] Fig. 11C is a block diagram of a processing cluster 1114 within a parallel processing unit. For example, a processing cluster is Fig.11A An instance of a processing cluster in the processing clusters 1114A-1114N. Processing cluster 1114 can be configured to execute many threads in parallel, wherein the term "thread" refers to an instance of a specific program executed on a specific set of input data. Optionally, a single instruction multiple data (SIMD) instruction issuance technology can be used to support the parallel execution of a large number of threads without providing multiple independent instruction units. Alternatively, a single instruction multiple thread (SIMT) technology can be used to support the parallel execution of a large number of threads that are generally synchronized using a common instruction unit that is configured to issue instructions to a processing engine set within each processing cluster in the processing cluster. Unlike the SIMD execution mechanism in which all processing engines typically execute the same instruction, SIMT execution allows different threads to more easily follow the divergent execution path through a given thread program. Those skilled in the art will understand that the SIMD processing mechanism represents a functional subset of the SIMT processing mechanism.

[0215] The operation of the processing cluster 1114 may be controlled via a pipeline manager 1132 that distributes processing tasks to SIMT parallel processors. The pipeline manager 1132 receives data from Fig.11AThe graphics multiprocessor 1134 is an exemplary embodiment of a SIMT parallel processor. However, various types of SIMT parallel processors of different architectures may be included in the processing cluster 1114. One or more instances of the graphics multiprocessor 1134 may be included in the processing cluster 1114. The graphics multiprocessor 1134 may process data, and the data crossbar 1140 may be used to distribute the processed data to one of a plurality of possible destinations, including other shader units. The pipeline manager 1132 may facilitate the distribution of processed data by specifying a destination for the processed data to be distributed via the data crossbar 1140.

[0216] Each graphics multiprocessor 1134 within a processing cluster 1114 may include an identical set of function execution logic (e.g., arithmetic logic units, load-store units, etc.). The function execution logic can be configured in a pipelined manner in which new instructions may be issued before previous instructions are completed. The function execution logic supports a variety of operations, including integer and floating point arithmetic, comparison operations, Boolean operations, bit shifts, and calculation of various algebraic functions. The same functional unit hardware may be utilized to perform different operations, and any combination of functional units may exist.

[0217] The instructions transmitted to the processing cluster 1114 constitute threads. A collection of threads executed across a collection of parallel processing engines is a thread group. A thread group executes the same program on different input data. Each thread within a thread group may be assigned to a different processing engine within the graphics multiprocessor 1134. A thread group may include fewer threads than the number of processing engines within the graphics multiprocessor 1134. When a thread group includes fewer threads than the number of processing engines, one or more of the processing engines may be idle during the cycle in which the thread group is being processed. A thread group may also include more threads than the number of processing engines within the graphics multiprocessor 1134. When a thread group includes more threads than the number of processing engines within the graphics multiprocessor 1134, processing may be performed in consecutive clock cycles. Optionally, multiple thread groups may be executed concurrently on the graphics multiprocessor 1134.

[0218] The graphics multiprocessors 1134 may include internal cache memory to perform load and store operations. Optionally, the graphics multiprocessors 1134 may forgo the internal cache and use cache memory (e.g., level 1 (L1) cache 1148) within the processing cluster 1114. Each graphics multiprocessor 1134 also has a partition unit (e.g., Fig.11A1120N), which are shared between all processing clusters 1114 and can be used to transfer data between threads. Graphics multiprocessor 1134 can also access off-chip global memory, which can include one or more of local parallel processor memory and / or system memory. Any memory external to parallel processing unit 1102 can be used as global memory. Examples in which processing cluster 1114 includes multiple instances of graphics multiprocessor 1134 can share common instructions and data, which can be stored in L1 cache 1148.

[0219] Each processing cluster 1114 may include an MMU 1145 (memory management unit) configured to map virtual addresses to physical addresses. In other examples, one or more instances of MMU 1145 may reside in Fig.11A 1148. The MMU 1145 includes a set of page table entries (PTEs) for mapping virtual addresses to physical addresses of the slice, and optionally includes a cache line index. The MMU 1145 may include an address translation lookaside buffer (TLB) or cache that may reside within the L1 cache 1148 of the graphics multiprocessor 1134 or processing cluster 1114. The physical addresses are processed to distribute surface data access locality, thereby allowing efficient request interleaving between partition units. The cache line index can be used to determine whether a request for a cache line is a hit or a miss.

[0220] In graphics and compute applications, the processing clusters 1114 may be configured such that each graphics multiprocessor 1134 is coupled to a texture unit 1136 for performing texture mapping operations, such as determining texture sample locations, reading texture data, and filtering texture data. Texture data is read from an internal texture L1 cache (not shown), or in some examples, from an L1 cache within the graphics multiprocessor 1134 and retrieved from an L2 cache, local parallel processor memory, or system memory, as desired. Each graphics multiprocessor 1134 outputs processed tasks to a data crossbar 1140 to provide the processed tasks to another processing cluster 1114 for further processing, or to store the processed tasks in an L2 cache, local parallel processor memory, or system memory via a memory crossbar 1116. A preROP 1142 (pre-rasterization operation unit) is configured to receive data from the graphics multiprocessor 1134, direct the data to ROP units, which may communicate with partition units (e.g., as described herein) as described herein. Fig.11AThe partition units 1120A-1120N) are positioned together. The preROP 1142 unit can perform optimizations for color blending, organize pixel color data, and perform address translation. It will be appreciated that the core architecture described herein is illustrative and that variations and modifications are possible. Any number of processing units (e.g., graphics multiprocessors 1134, texture units 1136, preROPs 1142, etc.) may be included within a processing cluster 1114. Further, although only one processing cluster 1114 is shown, the parallel processing units as described herein may include any number of examples of processing clusters 1114. Optionally, each processing cluster 1114 may be configured to operate independently of other processing clusters 1114 using separate and different processing units, L1 caches, L2 caches, etc.

[0221] Fig.11D An example of a graphics multiprocessor 1134 is shown, where the graphics multiprocessor 1134 is coupled to a pipeline manager 1132 of a processing cluster 1114. The graphics multiprocessor 1134 has an execution pipeline that includes, but is not limited to, an instruction cache 1152, an instruction unit 1154, an address mapping unit 1156, a register file 1158, one or more general purpose graphics processing unit (GPGPU) cores 1162, and one or more load / store units 1166. The GPGPU cores 1162 and the load / store units 1166 are coupled to a cache memory 1172 and a shared memory 1170 via a memory and cache interconnect 1168. The graphics multiprocessor 1134 may additionally include a tensor and / or ray tracing core 1163 that includes hardware logic for accelerating matrix and / or ray tracing operations.

[0222] The instruction cache 1152 may receive an instruction stream to be executed from the pipeline manager 1132. The instructions are cached in the instruction cache 1152 and dispatched for execution by the instruction unit 1154. The instruction unit 1154 may dispatch the instructions as a thread group (e.g., a unit group (warp)), where each thread in the thread group is assigned to a different execution unit within the GPGPU core 1162. The instruction may access any of the local address space, the shared address space, or the global address space by specifying an address within the unified address space. The address mapping unit 1156 may be used to translate the address in the unified address space into different memory addresses that can be accessed by the load / store unit 1166.

[0223] The register file 1158 provides a collection of registers for the functional units of the graphics multiprocessor 1134. The register file 1158 provides temporary storage for operands for data paths of the functional units (e.g., GPGPU core 1162, load / store unit 1166) connected to the graphics multiprocessor 1134. The register file 1158 may be divided between each of the functional units so that each functional unit is assigned a dedicated portion of the register file 1158. For example, the register file 1158 may be divided between different groups of units executed by the graphics multiprocessor 1134.

[0224] The GPGPU cores 1162 may each include a floating point unit (FPU) and / or an integer arithmetic logic unit (ALU) for executing instructions of the graphics multiprocessor 1134. In some implementations, the GPGPU core 1162 may include hardware logic that may otherwise reside within the tensor and / or ray tracing core 1163. The GPGPU cores 1162 may be similar in architecture, or may be different in architecture. For example and in some examples, the first portion of the GPGPU core 1162 includes a single-precision FPU and an integer ALU, while the second portion of the GPGPU core includes a double-precision FPU. Optionally, the FPU may implement the IEEE 754-2008 standard for floating-point arithmetic, or implement variable-precision floating-point arithmetic. The graphics multiprocessor 1134 may additionally include one or more fixed-function or special-function units for performing specific functions, such as copying rectangles or pixel blending operations. One or more GPGPU cores in the GPGPU core may also include fixed or special-function logic.

[0225] GPGPU core 1162 may include SIMD logic capable of executing a single instruction to multiple sets of data. Optionally, GPGPU core 1162 may physically execute SIMD4, SIMD8, and SIMD16 instructions, and logically execute SIMD1, SIMD2, and SIMD32 instructions. SIMD instructions for GPGPU cores may be generated by a shader compiler at compile time, or automatically generated when executing a program written and compiled for a single program multiple data (SPMD) or SIMT architecture. Multiple threads of a program configured for a SIMT execution model may be executed via a single SIMD instruction. For example and in some examples, eight SIMT threads may be executed in parallel via a single SIMD8 logic unit, and these eight SIMT threads perform the same or similar operations.

[0226] The memory and cache interconnect 1168 is an interconnect network that connects each of the functional units of the graphics multiprocessor 1134 to the register file 1158 and to the shared memory 1170. For example, the memory and cache interconnect 1168 is a crossbar interconnect that allows the load / store unit 1166 to implement load and store operations between the shared memory 1170 and the register file 1158. The register file 1158 can operate at the same frequency as the GPGPU core 1162, so data transfers between the GPGPU core 1162 and the register file 1158 are very low latency. The shared memory 1170 can be used to enable communication between threads executed on the functional units within the graphics multiprocessor 1134. The cache memory 1172 can be used as a data cache, for example, to cache texture data passed between the functional unit and the texture unit 1136. The shared memory 1170 can also be used as a managed cached program. The shared memory 1170 and the cache memory 1172 can be coupled with the data crossbar 1140 to enable communication with other components of the processing cluster. Threads executing on GPGPU core 1162 can programmatically store data in shared memory in addition to the automatically cached data stored in cache memory 1172.

[0227] Figure 12A-12C Additional graphics multiprocessors are illustrated according to examples. Figure 12A-12B The graphics multiprocessors 1225 and 1250 are shown. Fig. 11C The graphics multiprocessor 1134 of FIG. 1134 is related to the graphics multiprocessor 1134 of FIG. 1134 and can be used in place of one of those graphics multiprocessors. Therefore, the disclosure of any feature combined with the graphics multiprocessor 1134 herein also discloses the corresponding combination with (one or more) graphics multiprocessors 1225, 1250, but is not limited thereto. Fig. 12C A graphics processing unit (GPU) 1280 is illustrated that includes a dedicated collection of graphics processing resources arranged as multi-core groups 1265A-1265N that correspond to graphics multiprocessors 1225, 1250. The illustrated graphics multiprocessors 1225, 1250 and multi-core groups 1265A-1265N may be streaming multiprocessors (SMs) that are capable of executing a large number of execution threads simultaneously.

[0228] Fig. 12A The graphics multiprocessor 1225 includes relative Fig.11DThe graphics multiprocessor 1225 may include multiple additional instances of execution resource units of the graphics multiprocessor 1134. For example, the graphics multiprocessor 1225 may include multiple instances of instruction units 1232A-1232B, register files 1234A-1234B, and (one or more) texture units 1244A-1244B. The graphics multiprocessor 1225 also includes multiple sets of graphics or compute execution units (e.g., GPGPU cores 1236A-1236B, tensor cores 1237A-1237B, ray tracing cores 1238A-1238B), and multiple sets of load / store units 1240A-1240B. The execution resource units have a common instruction cache 1230, texture and / or data cache memory 1242, and shared memory 1246.

[0229] The various components may communicate via the interconnect structure 1227. The interconnect structure 1227 may include one or more crossbar switches to enable communication between the various components of the graphics multiprocessor 1225. The interconnect structure 1227 is a separate high-speed network fabric layer on which each component of the graphics multiprocessor 1225 is stacked. The components of the graphics multiprocessor 1225 communicate with remote components via the interconnect structure 1227. For example, the cores 1236A-1236B, 1237A-1237B, and 1238A-1238B may each communicate with the shared memory 1246 via the interconnect structure 1227. The interconnect structure 1227 may arbitrate communications within the graphics multiprocessor 1225 to ensure fair bandwidth allocation between components.

[0230] Fig. 12B The graphics multiprocessor 1250 includes multiple sets of execution resources 1256A-1256D, where Fig.11D and Fig. 12A As shown in FIG. 1 , each set of execution resources includes multiple instruction units, register files, GPGPU cores, and load store units. Execution resources 1256A-1256D may work in concert with (one or more) texture units 1260A-1260D for texture operations while sharing instruction cache 1254 and shared memory 1253. For example, execution resources 1256A-1256D may share multiple instances of instruction cache 1254 and shared memory 1253 as well as texture and / or data cache memory 1258A-1258B. The various components may be communicated with via Fig. 12A The interconnect structure 1227 communicates with a similar interconnect structure 1252 .

[0231] Those skilled in the art will understand that Fig.10 , Figures 11A-11D as well as Figure 12A-12BThe architecture described in is illustrative and not limiting in scope of the current examples. Thus, the techniques described herein may be implemented on any appropriately configured processing unit without departing from the scope of the examples described herein, including but not limited to: one or more mobile application processors; one or more desktop or server central processing units (CPUs), including multi-core CPUs; one or more parallel processor units, such as Fig.11A and one or more graphics processors or special-purpose processing units.

[0232] The parallel processor or GPGPU described herein can be communicatively coupled to a host / processor core to accelerate graphics operations, machine learning operations, pattern analysis operations, and various general-purpose GPU (GPGPU) functions. The GPU can be communicatively coupled to the host processor / core via a bus or another interconnect (e.g., a high-speed interconnect, such as PCIe, NVLink, or other known protocols, standardized protocols, or proprietary protocols). In other examples, the GPU can be integrated on the same package or chip as the core and communicatively coupled to the core via an internal processor bus / interconnect (i.e., inside the package or chip). Regardless of the manner in which the GPU is connected, the processor core can assign work to the GPU in the form of a sequence of commands / instructions contained in a work descriptor. The GPU then uses a dedicated circuit system / logic to efficiently process these commands / instructions.

[0233] Fig. 12C A graphics processing unit (GPU) 1280 is illustrated that includes a dedicated set of graphics processing resources arranged as multi-core groups 1265A-1265N. Although details of only a single multi-core group 1265A are provided, it will be appreciated that other multi-core groups 1265B-1265N may be equipped with the same or similar set of graphics processing resources. Details described with respect to multi-core groups 1265A-1265 may also apply to any of the graphics multiprocessors 1134, 1225, 1250 described herein.

[0234] As illustrated, multi-core group 1265A may include a set of graphics cores 1270, a set of tensor cores 1271, and a set of ray tracing cores 1272. Scheduler / dispatcher 1268 schedules and dispatches graphics threads for execution on the various cores 1270, 1271, 1272. A set of register files 1269 stores operand values ​​used by cores 1270, 1271, 1272 when executing graphics threads. These register files may include, for example, integer registers for storing integer values, floating point registers for storing floating point values, vector registers for storing packed data elements (integer and / or floating point data elements), and slice registers for storing tensor / matrix values. Slice registers may be implemented as a combined set of vector registers.

[0235] One or more combined level 1 (L1) caches and shared memory units 1273 store graphics data locally within each multi-core group 1265A, such as texture data, vertex data, pixel data, light data, bounding volume data, etc. One or more texture units 1274 may also be used to perform texture operations, such as texture mapping and sampling. A level 2 (L2) cache 1275 shared by all multi-core groups 1265A-1265N or a subset of multi-core groups 1265A-1265N stores graphics data and / or instructions for multiple concurrent graphics threads. As illustrated, the L2 cache 1275 may be shared across multiple multi-core groups 1265A-1265N. One or more memory controllers 1267 couple the GPU 1280 to a memory 1266, which may be a system memory (e.g., DRAM) and / or a dedicated graphics memory (e.g., GDDR6 memory). Input / output (I / O) circuitry 1263 couples GPU 1280 to one or more I / O devices 1262, such as digital signal processors (DSPs), network controllers, or user input devices. On-chip interconnects may be used to couple I / O devices 1262 to GPU 1280 and memory 1266. One or more I / O memory management units (IOMMUs) 1264 of I / O circuitry 1263 couple I / O devices 1262 directly to system memory 1266. Optionally, IOMMU 1264 manages multiple sets of page tables for mapping virtual addresses to physical addresses in system memory 1266. I / O devices 1262, CPU(s) 1261, and GPU(s) 1280 may then share the same virtual address space.

[0236] In one implementation of the IOMMU 1264, the IOMMU 1264 supports virtualization. In this case, the IOMMU 1264 can manage a first set of page tables for mapping guest / graphics virtual addresses to guest / graphics physical addresses, and a second set of page tables for mapping guest / graphics physical addresses to system / host physical addresses (e.g., within system memory 1266). The base address of each of the first set of page tables and the second set of page tables can be stored in a control register and swapped out at context switch (e.g., so that the new context is provided with access to the relevant set of page tables). Although not described in detail in the prior art, the IOMMU 1264 can manage a first set of page tables for mapping guest / graphics virtual addresses to guest / graphics physical addresses, and a second set of page tables for mapping guest / graphics physical addresses to system / host physical addresses (e.g., within system memory 1266). Fig. 12C , but each of the cores 1270, 1271, 1272 and / or multi-core groups 1265A-1265N may include a translation lookaside buffer (TLB) for caching guest virtual to guest physical translations, guest physical to host physical translations, and guest virtual to host physical translations.

[0237] (One or more) CPU 1261, GPU 1280 and I / O device 1262 can be integrated on a single semiconductor chip and / or chip package. The illustrated memory 1266 can be integrated on the same chip, or can be coupled to a memory controller 1267 via an off-chip interface. In one implementation, memory 1266 includes GDDR6 memory that shares the same virtual address space as other physical system-level memory, although the basic principles described herein are not limited to this particular implementation.

[0238] Tensor core 1271 may include multiple execution units specifically designed to perform matrix operations, which are the basic computational operations for performing deep learning operations. For example, synchronous matrix multiplication operations can be used for neural network training and inference. Tensor core 1271 can perform matrix processing using various operand precisions, including single-precision floating point (e.g., 32 bits), half-precision floating point (e.g., 16 bits), integer words (16 bits), bytes (8 bits), and half bytes (4 bits). For example, a neural network implementation extracts features of each rendered scene, potentially combining details from multiple frames to construct a high-quality final image.

[0239] In a deep learning implementation, parallel matrix multiplication work can be scheduled for execution on the Tensor Core 1271. The training of neural networks in particular requires a large number of matrix dot product operations. To handle the inner product formulation of the N×N×N matrix multiplication, the Tensor Core 1271 can include at least N dot product processing elements. Before the matrix multiplication begins, a complete matrix is ​​loaded into the slice register, and for each of the N cycles, at least one column of the second matrix is ​​loaded. For each cycle, there are N dot products processed.

[0240] Depending on the specific implementation, matrix elements can be stored with different precisions, including 16-bit words, 8-bit bytes (e.g., INT8), and 4-bit nibbles (e.g., INT4). Different precision modes can be specified for the Tensor Core 1271 to ensure that the most efficient precision is used for different workloads (e.g., such as inference workloads, which can tolerate quantization to bytes and nibbles). Supported formats additionally include 64-bit floating point (FP64) and non-IEEE floating point formats, such as the bfloat16 format (e.g., Brain floating point), a 16-bit floating point format with one sign bit, eight exponent bits, and eight significand bits (seven of which are explicitly stored). An example includes support for a reduced precision tensor floating point (TF32) mode that performs calculations using the range of FP32 (8 bits) and the precision of FP16 (10 bits). Reduced precision TF32 operations can be performed on FP32 inputs and produce FP32 outputs with higher performance relative to FP32 and increased precision relative to FP16. In some examples, one or more 8-bit floating point formats (FP8) are supported.

[0241] In some examples, the tensor core 1271 supports a sparse operation mode for matrices in which the vast majority of values ​​are zero. The tensor core 1271 includes support for sparse input matrices encoded in sparse matrix representations (e.g., coordinate list encoding (COO), compressed sparse rows (CSR), compressed sparse columns (CSC), etc.). The tensor core 1271 also includes support for compressed sparse matrix representations in the case where the sparse matrix representation can be further compressed. Compressed matrix data, encoded matrix data, and / or compressed and encoded matrix data and associated compression and / or encoding metadata can be read by the tensor core 1271, and non-zero values ​​can be extracted. For example, for a given input matrix A, non-zero values ​​can be loaded from a compressed and / or encoded representation of at least part of matrix A. Based on the position of the non-zero value in matrix A (which can be determined from the index or coordinate metadata associated with the non-zero value), the corresponding value in the input matrix B can be loaded. Depending on the operation to be performed (e.g., multiplication), the loading of values ​​from the input matrix B can be bypassed if the corresponding value is a zero value. In some examples, the pairing of values ​​for certain operations (such as multiplication operations) can be pre-scanned by the scheduler logic, and only operations between non-zero inputs are scheduled. Depending on the dimensions of the matrices A and B and the operations to be performed, the output matrix C can be dense or sparse. In the case where the output matrix C is sparse and depending on the configuration of the tensor core 1271, the output matrix C can be output in a compressed format, sparse coding, or compressed sparse coding.

[0242] The ray tracing core 1272 can accelerate ray tracing operations for both real-time ray tracing and non-real-time ray tracing implementations. Specifically, the ray tracing core 1272 may include a ray traversal / intersection circuit system for performing ray traversals and identifying intersections between rays and primitives enclosed within a BVH volume using a bounding volume hierarchy (BVH). The ray tracing core 1272 may also include a circuit system for performing depth testing and culling (e.g., using a Z buffer or similar arrangement). In one implementation, the ray tracing core 1272 performs traversal and intersection operations in conjunction with the image denoising techniques described herein, at least part of which may be performed on the tensor core 1271. For example, the tensor core 1271 may implement a deep learning neural network to perform denoising on frames generated by the ray tracing core 1272. However, CPU(s) 1261, graphics core 1270, and / or ray tracing core 1272 may also implement all and / or portions of denoising and / or deep learning algorithms.

[0243] In addition, as described above, a distributed approach to denoising may be employed, wherein GPU 1280 is in a computing device coupled to other computing devices via a network or high-speed interconnect. In this distributed approach, the interconnected computing devices may share neural network learning / training data to improve the speed at which the entire system learns to perform denoising for different types of image frames and / or different graphics applications.

[0244] The ray tracing core 1272 can handle all BVH traversals and / or ray-primitive intersections, thereby saving the graphics core 1270 from being overloaded with thousands of instructions per ray. For example, each ray tracing core 1272 includes a first set of specialized circuit systems for performing bounding box tests (e.g., for traversal operations) and / or a second set of specialized circuit systems for performing ray-triangle intersection tests (e.g., intersecting rays that have been traversed). Thus, for example, multi-core group 1265A can simply initiate ray detection, and the ray tracing core 1272 independently performs ray traversals and intersections and returns hit data (e.g., hits, no hits, multiple hits, etc.) to the thread context. While the ray tracing core 1270 performs traversal and intersection operations, the other cores 1271, 1272 are freed up to perform other graphics or computational work.

[0245] Optionally, each ray tracing core 1272 may include a traversal unit for performing BVH test operations and / or an intersection unit for performing ray-primitive intersection tests. The intersection unit generates a "hit", "no hit", or "multiple hits" response, which it provides to the appropriate thread. During traversal and intersection operations, execution resources of other cores (e.g., graphics cores 1270 and tensor cores 1271) are freed up to perform other forms of graphics work.

[0246] In some examples described below, a hybrid rasterization / ray tracing approach is used in which the work is distributed between graphics core 1270 and ray tracing core 1272 .

[0247] The ray tracing core 1272 (and / or other cores 1270, 1271) may include hardware support for a ray tracing instruction set, such as Microsoft's DirectX Ray Tracing (DXR), which includes the DispatchRays command; and ray generation shaders, nearest hit shaders, any hit shaders, and miss shaders, which enable a unique set of shaders and textures to be assigned to each object. Another ray tracing platform that may be supported by the ray tracing core 1272, graphics core 1270, and tensor core 1271 is the Vulkan API (e.g., Vulkan version 1.1.85 and higher). However, it is to be noted that the basic principles described herein are not limited to any particular ray tracing ISA.

[0248] In general, each core 1272, 1271, 1270 may support a ray tracing instruction set including instructions / functions for one or more of the following: ray generation, nearest hit, any hit, ray-primitive intersection, per-primitive and hierarchy bounding box construction, miss, visit, and exceptions. More specifically, some examples include ray tracing instructions for performing one or more of the following functions:

[0249] Light Generation - Ray generation instructions can be executed for each pixel, sample, or other user-defined work assignment.

[0250] Recent Hits ——A nearest hit command can be executed to locate the closest intersection of a ray and a primitive within the scene.

[0251] Any hit - Any hit instruction identifies multiple intersections between rays and primitives within the scene, thereby potentially identifying a new closest intersection point.

[0252] intersect ——The intersection instruction performs a ray-primitive intersection test and outputs the result.

[0253] Per-element bounding box construction - This instruction builds a bounding box around a given primitive or group of primitives (e.g., when building a new BVH or other acceleration data structure).

[0254] miss - Indicates that the ray missed the scene or all geometry within a specified region of the scene.

[0255] visit ——Indicates the child volume that the ray will traverse.

[0256] abnormal - Includes various types of exception handlers (e.g., called for various error conditions).

[0257] In some examples, the ray tracing core 1272 can be adapted to accelerate general computing operations that can be accelerated using computing techniques similar to ray intersection tests. A computing framework can be provided that enables shader programs to be compiled into low-level instructions and / or primitives that perform general computing operations via the ray tracing core. Exemplary computing problems that can benefit from computing operations performed on the ray tracing core 1272 include calculations involving the propagation of beams, waves, rays, or particles in a coordinate space. Interactions associated with the propagation can be calculated relative to geometry or meshes in the coordinate space. For example, calculations associated with the propagation of electromagnetic signals through the environment can be accelerated using instructions or primitives executed via the ray tracing core. The refraction and reflection of the signal by objects in the environment can be calculated as a direct ray tracing analogy.

[0258] The ray tracing core 1272 can also be used to perform calculations that are not directly similar to ray tracing. For example, the ray tracing core 1272 can be used to accelerate mesh projection, mesh refinement, and volume sampling calculations. General coordinate space calculations, such as nearest neighbor calculations, can also be performed. For example, a set of points near a given point can be found by defining a bounding box around the given point in the coordinate space. The ray detection logic in the ray tracing core 1272 and the BVH can then be used to determine the set of intersections of the points in the bounding box. The intersection constitutes the origin and the nearest neighbor to the origin. The calculations performed using the ray tracing core 1272 can be performed in parallel with the calculations performed on the graphics core 1272 and the tensor core 1271. The shader compiler can be configured to compile a compute shader or other general graphics processing program into a low-level primitive that can be parallelized across the graphics core 1270, the tensor core 1271, and the ray tracing core 1272.

[0259] Manufacturing larger and larger silicon dies is challenging for a variety of reasons. As silicon dies get larger, manufacturing yields become smaller, and the process technology requirements for different components may be different. On the other hand, in order to have a high-performance system, key components should be interconnected through high-speed, high-bandwidth, low-latency interfaces. These conflicting requirements pose challenges to high-performance chip development.

[0260] The examples described herein provide techniques for decomposing the architecture of a system-on-chip integrated circuit into a plurality of different chiplets that can be packaged onto a common chassis. In some examples, a graphics processing unit or a parallel processor is composed of different silicon chiplets that are manufactured separately. A chiplet is an integrated circuit that is at least partially packaged, and the at least partially packaged integrated circuit includes different logic units that can be assembled into a larger package with other chiplets. A variety of chiplet collections with different IP core logic can be assembled into a single device. In addition, the chiplets can be integrated into a base die or base chiplet using active interposer technology. The concepts described herein enable interconnection and communication between different forms of IP within a GPU. IP development on different processes can be mixed. This avoids the complexity of converging multiple IPs to the same process, especially on large SoCs with several styles of IP.

[0261] Enabling the use of multiple process technologies improves time to market and provides a cost-effective way to create multiple product SKUs. For customers, this means getting products tailored to their requirements in a cost-effective and timely manner. In addition, disaggregated IP is easier to independently power gate, and components not used in a given workload can be turned off, reducing overall power consumption.

[0262] Fig.13A parallel computing system 1300 according to some examples is shown. In some examples, the parallel computing system 1300 includes a parallel processor 1320, which may be a graphics processor or a computing accelerator as described herein. The parallel processor 1320 includes a global logic unit 1301, an interface 1302, a thread dispatcher 1303, a media unit 1304, a set of computing units 1305A-1305H, and a cache / memory unit 1306. In some examples, the global logic unit 1301 includes global functions for the parallel processor 1320, including device configuration registers, a global scheduler, power management logic, etc. The interface 1302 may include a front-end interface for the parallel processor 1320. The thread dispatcher 1303 may receive a workload from the interface 1302 and dispatch threads of the workload to the computing units 1305A-1305H. If the workload includes any media operations, at least a portion of these operations may be performed by the media unit 1304. The media unit may also offload some operations to the compute units 1305A-1305H. The cache / memory unit 1306 may include cache memory (eg, L3 cache) and local memory (eg, HBM, GDDR) for the parallel processors 1320.

[0263] Figures 14A-14B Illustrated is a hybrid logical / physical view of a disaggregated parallel processor according to examples described herein. Fig.14A A de-aggregated parallel computing system 1400 is illustrated. Fig. 14B The diagram shows a chiplet 1430 of the de-aggregated parallel computing system 1400. Fig.14AAs shown, the disaggregated computing system 1400 may include a parallel processor 1420, wherein various components of the parallel processor SOC are distributed across multiple chiplets. Each chiplet may be a different IP core that is independently designed and configured to communicate with other chiplets via one or more common interfaces. The chiplets include, but are not limited to, computing chiplets 1405, media chiplets 1404, and memory chiplets 1406. Each chiplet may be manufactured separately using different process technologies. For example, the computing chiplet 1405 may be manufactured using the smallest or most advanced process technology available at the time of manufacturing, while the memory chiplet 1406 or other chiplets (e.g., I / O, networking, etc.) may be manufactured using larger or less advanced process technologies. The various chiplets may be bonded to the base die 1410 and configured to communicate with each other and with logic within the base die 1410 via an interconnect layer 1412. In some examples, the base die 1410 may include global logic 1401 (global logic 1401 may include scheduler 1411 and power management 1421 logic units), interface 1402, dispatch unit 1403, and interconnect fabric module 1408 coupled or integrated with one or more L3 cache banks 1409A-1409N. Interconnect fabric 1408 may be an inter-chiplet fabric integrated into the base die 1410. Logic chiplets may use fabric 1408 to relay messages between chiplets. In addition, L3 cache banks 1409A-1409N in the base die and / or L3 cache banks within memory chiplets 1406 may cache data read from DRAM chiplets within memory chiplets 1406 and transferred to the DRAM chiplets and the host's system memory.

[0264] In some examples, global logic 1401 is a microcontroller that can execute firmware to perform scheduler 1411 and power management 1421 functions for parallel processor 1420. The microcontroller executing the global logic can be customized for the target use case of parallel processor 1420. Scheduler 1411 can perform global scheduling operations for parallel processor 1420. Power management 1421 functions can be used to enable or disable individual chiplets within a parallel processor when those chiplets are not being used.

[0265] The various chiplets of parallel processors 1420 may be designed to perform specific functions that would be integrated into a single die in existing designs. A collection of compute chiplets 1405 may include a cluster of compute units (e.g., execution units, streaming multiprocessors, etc.) that include programmable logic for executing compute or graphics shader instructions. Media chiplets 1404 may include hardware logic for accelerating media encoding and decoding operations. Memory chiplets 1406 may include volatile memory (e.g., DRAM) and one or more SRAM cache memory banks (e.g., L3 banks).

[0266] like Fig. 14B As shown, each chiplet 1430 may include general-purpose components and specialized components. The chiplet logic 1436 within the chiplet 1430 may include specific components of the chiplet, such as an array of streaming multiprocessors, computing units, or execution units described herein. The chiplet logic 1436 may be coupled to an optional cache or shared local memory 1438, or a cache or shared local memory may be included within the chiplet logic 1436. The chiplet 1430 may include a fabric interconnect node 1442 that receives commands via an inter-chiplet structure. Commands and data received via the fabric interconnect node 1442 may be temporarily stored in an interconnect buffer 1439. Data transmitted to and received from the fabric interconnect node 1442 may be stored in the interconnect cache 1440. Power control 1432 and clock control 1434 logic may also be included within the chiplet. The power control 1432 and clock control 1434 logic may receive configuration commands via the structure, and dynamic voltage and frequency scaling may be configured for the chiplet 1430. In some examples, each chiplet can have independent clock and power domains and can be clock-gated and power-gated independently of other chiplets.

[0267] At least a portion of the components within the illustrated chiplet 1430 may also be included in an embedded Fig.14A 1410. For example, logic within the base die that communicates with the fabric may include a version of fabric interconnect node 1442. Base die logic that may be independently clocked or power gated may include a version of power control 1432 and / or clock control 1434 logic.

[0268] Thus, while various examples described herein use the term SOC to describe a device or system having a processor and associated circuitry (e.g., input / output (“I / O”) circuitry, power delivery circuitry, memory circuitry, etc.) monolithically integrated into a single integrated circuit (“IC”) die or chip, the present disclosure is not limited thereto. For example, in various examples of the present disclosure, a device or system may have one or more processors (e.g., one or more processor cores) and associated circuitry (e.g., input / output (“I / O”) circuitry, power delivery circuitry, etc.) arranged in a disaggregated collection of discrete dies, slices, and / or chiplets (e.g., one or more discrete processor core dies arranged near one or more other dies (such as memory dies, I / O dies, etc.)). In such disaggregated devices and systems, the various dies, slices, and / or chiplets may be physically and electrically coupled together by a packaging structure including, for example, various packaging substrates, interposers, active interposers, photonic interposers, interconnect bridges, etc. A disaggregated collection of discrete dies, slices, and / or chiplets may also be part of a system on a package ("SoP").

[0269] Example core architectures - in-order and out-of-order core block diagrams.

[0270] Fig.15A is a block diagram illustrating both an example in-order pipeline and an example register renaming out-of-order issue / execution pipeline according to an example. Fig. 15B is a block diagram illustrating both an example in-order architecture core and an example register renaming out-of-order issue / execution architecture core to be included in a processor according to an example. Figures 15A-15B The solid line boxes in illustrate the in-order pipeline and in-order core, while the optional addition of dashed line boxes illustrates the register renaming out-of-order issue / execution pipeline and core. Given that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0271] exist Fig.15A, the processor pipeline 1500 includes a fetch stage 1502, an optional length decode stage 1504, a decode stage 1506, an optional allocation (Alloc) stage 1508, an optional rename stage 1510, a schedule (also called dispatch or issue) stage 1512, an optional register read / memory read stage 1514, an execute stage 1516, a write back / memory write stage 1518, an optional exception handling stage 1522, and an optional commit stage 1524. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 1502, one or more instructions are fetched from the instruction memory, and during the decode stage 1506, one or more of the fetched instructions may be decoded, an address using a forwarded register port (e.g., a load storage unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or link register (LR)) may be performed. In some examples, the decode stage 1506 and the register read / memory read stage 1514 may be combined into one pipeline stage. In some examples, during the execute stage 1516, decoded instructions may be executed, LSU address / data pipelining to an advanced microcontroller bus (AMB) interface may be performed, multiplication and addition operations may be performed, arithmetic operations with branch results may be performed, and the like.

[0272] For example, Fig. 15B An example register renaming out-of-order issue / execution architecture core may implement pipeline 1500 as follows: 1) instruction fetch circuitry 1538 performs fetch and length decode stages 1502 and 1504; 2) decode circuitry 1540 performs decode stage 1506; 3) rename / allocator unit circuitry 1552 performs allocate stage 1508 and rename stage 1510; 4) (one or more) scheduler circuitry 1556 performs schedule stage 1512; 5) (one or more) physical register file circuitry 1558 and The memory unit circuit system 1570 performs a register read / memory read phase 1514; (one or more) execution clusters 1560 perform an execute phase 1516; 6) the memory unit circuit system 1570 and (one or more) physical register file circuit systems 1558 perform a write back / memory write phase 1518; 7) various circuit systems may be involved in the exception handling phase 1522; and 8) the retirement unit circuit system 1554 and (one or more) physical register file circuit systems 1558 perform a commit phase 1524.

[0273] Fig. 15BA processor core 1590 is illustrated, which includes a front end unit circuit system 1530 coupled to an execution engine unit circuit system 1550, and both the front end unit circuit system 1530 and the execution engine unit circuit system 1550 are coupled to a memory unit circuit system 1570. The core 1590 can be a reduced instruction set architecture computing (RISC) core, a complex instruction set architecture computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the core 1590 can be a special-purpose core, such as, for example, a network or communication core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, a graphics core, etc.

[0274] The front end unit circuit system 1530 may include a branch prediction circuit system 1532 coupled to an instruction cache circuit system 1534, which is coupled to an instruction translation lookaside buffer (TLB) 1536, which is coupled to an instruction fetch circuit system 1538, which is coupled to a decoding circuit system 1540. In some examples, the instruction cache circuit system 1534 is included in the memory unit circuit system 1570 instead of the front end circuit system 1530. The decoding circuit system 1540 (or decoder) can decode the instruction and generate one or more micro-operations, micro-code entry points, micro-instructions, other instructions or other control signals as output, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decoding circuit system 1540 may further include an address generation unit (AGU, not shown) circuit system. In some examples, the AGU uses the forwarded register port to generate an LSU address and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decoding circuit system 1540 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read-only memories (ROMs), and the like. In some examples, the core 1590 includes a microcode ROM (not shown) or other medium storing microcode for certain macroinstructions (e.g., in the decoding circuit system 1540 or otherwise in the front-end circuit system 1530). In some examples, the decoding circuit system 1540 includes a micro-op or operation cache (not shown) to save / cache decoded operations, micro-tags, or micro-operations generated during decoding or other stages of the processor pipeline 1500. The decoding circuit system 1540 may be coupled to the rename / allocator unit circuit system 1552 in the execution engine circuit system 1550.

[0275] Execution engine circuitry 1550 includes rename / allocator unit circuitry 1552 coupled to retirement unit circuitry 1554 and a set of one or more scheduler circuitry 1556. Scheduler circuitry(s) 1556 represent any number of different schedulers, including reservation stations, central instruction windows, and the like. In some examples, scheduler circuitry(s) 1556 may include arithmetic logic unit (ALU) scheduler / scheduling circuitry, ALU queues, address generation unit (AGU) scheduler / scheduling circuitry, AGU queues, and the like. Scheduler circuitry(s) 1556 are coupled to physical register file(s) circuitry 1558. Each of the physical register file(s) circuitry 1558 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, status (e.g., an instruction pointer that is the address of the next instruction to be executed), and the like. In some examples, the physical register file(s) circuitry 1558 includes vector register unit circuitry, write mask register unit circuitry, and scalar register unit circuitry. These register units may provide architectural vector registers, vector mask registers, general purpose registers, and the like. The physical register file(s) circuitry 1558 is coupled to a retirement unit circuitry 1554 (also referred to as a retirement queue) to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using reorder buffer(s) (ROBs) and retirement register file(s); using future files(s), history buffer(s) and retirement register file(s); using register maps and register pools, and the like). The retirement unit circuitry 1554 and the physical register file(s) circuitry 1558 are coupled to execution cluster(s) 1560. The execution cluster(s) 1560 includes a set of one or more execution unit circuitry 1562 and a set of one or more memory access circuitry 1564. Execution unit circuitry 1562 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some examples may include multiple execution units or execution unit circuitry dedicated to a particular function or set of functions, other examples may include only one execution unit circuitry, or multiple execution units / execution unit circuitry that all perform all functions.Scheduler circuitry(s) 1556, physical register file circuitry(s) 1558, and execution cluster(s) 1560 are shown as possibly multiple because some examples create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipelines, and / or memory access pipelines, each of which has its own scheduler circuitry, physical register file circuitry(s), and / or execution clusters, and in the case of separate memory access pipelines, some examples are implemented where only the execution cluster of that pipeline has memory access unit circuitry(s) 1564). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, and the rest of the pipelines may be in-order.

[0276] In some examples, execution engine unit circuitry 1550 may perform load store unit (LSU) address / data pipelining, as well as address stage and writeback, data stage loads, stores, and branches to an advanced microcontroller bus (AMB) interface (not shown).

[0277] The set of memory access circuitry 1564 is coupled to memory cell circuitry 1570, which includes data TLB circuitry 1572 coupled to data cache circuitry 1574, which is coupled to level 2 (L2) cache circuitry 1576. In some examples, memory access circuitry 1564 may include load unit circuitry, store address unit circuitry, and store data unit circuitry, each of which is coupled to data TLB circuitry 1572 in memory cell circuitry 1570. Instruction cache circuitry 1534 is further coupled to level 2 (L2) cache circuitry 1576 in memory cell circuitry 1570. In some examples, instruction cache 1534 and data cache 1574 are combined into L2 cache circuitry 1576, level 3 (L3) cache circuitry (not shown), and / or a single instruction and data cache (not shown) in main memory. L2 cache circuitry 1576 is coupled to one or more other levels of cache and ultimately to main memory.

[0278] Core 1590 can support one or more instruction sets (e.g., x86 instruction set architecture (optionally, with some extensions that have been added under newer versions); MIPS instruction set architecture; ARM instruction set architecture (optionally, with optional additional extensions, such as NEON)), including the instruction(s) described herein. In some examples, core 1590 includes logic to support packed data instruction set architecture extensions (e.g., AVX1, AVX2), allowing operations used by many multimedia applications to be performed using packed data.

[0279] Example execution unit(s) circuitry.

[0280] Fig.16 An example of execution unit circuitry, such as Fig. 15B (One or more) execution unit circuit systems 1562. As illustrated, (one or more) execution unit circuit systems 1562 may include one or more ALU circuits 1601, optional vector / single instruction multiple data (SIMD) circuits 1603, load / store circuits 1605, branch / jump circuits 1607, and / or floating point unit (FPU) circuits 1609. ALU circuits 1601 perform integer arithmetic and / or Boolean operations. Vector / SIMD circuits 1603 perform vector / SIMD operations on packed data (such as SIMD / vector registers). Load / store circuits 1605 execute load and store instructions to load data from memory to registers or store data from registers to memory. Load / store circuits 1605 may also generate addresses. Branch / jump circuits 1607 cause branches or jumps to memory addresses depending on the instructions. FPU circuits 1609 perform floating point arithmetic. The width of execution unit circuitry 1562 varies depending on the example, and may range, for example, from 16 bits to 1024 bits. In some examples, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit).

[0281] Example register architecture.

[0282] Fig.171 is a block diagram of a register architecture 1700 according to some examples. As illustrated, the register architecture 1700 includes vector / SIMD registers 1710, the width of which varies from 128 bits to 1024 bits. In some examples, the vector / SIMD registers 1710 are physically 512 bits, and depending on the mapping, only some of the lower bits are used. For example, in some examples, the vector / SIMD registers 1710 are 512-bit ZMM registers: the lower 256 bits are used for the YMM registers, and the lower 128 bits are used for the XMM registers. Thus, there is an overlap of registers. In some examples, the vector length field selects between the maximum length and one or more other shorter lengths, wherein each such shorter length is half of the previous length. Scalar operations are operations performed on the lowest-order data element positions in the ZMM / YMM / XMM registers; higher-order data element positions either remain the same as they were before the instruction, or are zeroed, depending on the example.

[0283] In some examples, the register architecture 1700 includes write mask / predicate registers 1715. For example, in some examples, there are 8 write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16 bits, 32 bits, 64 bits, or 128 bits in size. The write mask / predicate registers 1715 can allow merging (e.g., allowing any set of elements in the destination to be protected from being updated during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some examples, each data element position in a given write mask / predicate register 1715 corresponds to a data element position in the destination. In other examples, the write mask / predicate registers 1715 are scalable and consist of a set number of enable bits for a given vector element (e.g., 8 enable bits per 64-bit vector element).

[0284] The register architecture 1700 includes a plurality of general registers 1725. These registers may be 16-bit, 32-bit, 64-bit, etc., and may be used for scalar operations. In some examples, these registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0285] In some examples, the register architecture 1700 includes a scalar floating point (FP) register file 1745, which is used to perform scalar floating point operations on 32 / 64 / 80-bit floating point data using x87 instruction set architecture extensions, or as an MMX register to perform operations on 64-bit packed integer data, and to store operands for some operations performed between MMX and XMM registers.

[0286] One or more flag registers 1740 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operations. For example, one or more flag registers 1740 can store condition code information such as carry, parity, auxiliary carry, zero, sign, and overflow. In some examples, one or more flag registers 1740 are referred to as program status and control registers.

[0287] Segment registers 1720 contain segment pointers for accessing memory. In some examples, these registers are referenced by the names CS, DS, SS, ES, FS, and GS.

[0288] Model specific registers or machine specific registers (MSRs) 1735 control processor performance and report on processor performance. Most MSRs 1735 handle system related functions and are inaccessible to applications. For example, MSRs can provide control of one or more of the following: performance monitoring counters, debug extensions, memory type range registers, thermal and power management, instruction specific support, and / or processor feature / mode support. Machine check registers 1760 consist of control, status, and error reporting MSRs for detecting hardware errors and reporting on hardware errors. (One or more) control registers 1755 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processor 870, 880, 838, 815, and / or 900) and the characteristics of the currently executing task. In some examples, MSRs 1735 are a subset of control registers 1755.

[0289] One or more instruction pointer registers 1730 store instruction pointer values. Debug registers 1750 control and enable monitoring of debug operations of the processor or core.

[0290] Memory (mem) management registers 1765 specify the location of data structures used in protected mode memory management. These registers may include the Global Descriptor Table Register (GDTR), Interrupt Descriptor Table Register (IDTR), Task Register, and Local Descriptor Table Register (LDTR) registers.

[0291] Alternative examples may use wider or narrower registers. In addition, alternative examples may use more, fewer, or different register files and registers. Register architecture 1700 may be used, for example, in register file / memory 1158 or (one or more) physical register file circuitry 1558.

[0292] Instruction set architecture.

[0293] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of the bits) to specify, among other things, the operation to be performed (e.g., opcode) and the (one or more) operands and / or (one or more) other data fields (e.g., mask) on which the operation is to be performed. Some instruction formats are further decomposed (broken down) by the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets of instruction format fields (the included fields are usually in the same order, but at least some have different bit positions because fewer fields are included) and / or defined as having given fields that are interpreted differently. Therefore, each instruction of an ISA is expressed using a given instruction format (and, if defined, in a given instruction template in the instruction template of the instruction format), and includes fields for specifying the operation and operands. For example, the example ADD instruction has a specific opcode and an instruction format that includes an opcode field for specifying the opcode and an operand field (source 1 / destination and source 2) for selecting operands; and the appearance of the ADD instruction in an instruction stream will have specific content in the operand field for selecting a specific operand. In addition, although the following description is made in the context of the x86 ISA, it is within the knowledge of those skilled in the art to apply the teachings of the present disclosure in another ISA.

[0294] Example instruction format.

[0295] The examples of (one or more) instructions described herein may be embodied in different formats. In addition, example systems, architectures, and pipelines are described in detail below. The examples of (one or more) instructions may be executed on such systems, architectures, and pipelines, but are not limited to these details.

[0296] Fig.18 An example of an instruction format is illustrated. As illustrated, an instruction may include multiple components, including, but not limited to, one or more fields for: one or more prefixes 1801, an opcode 1803, addressing information 1805 (e.g., a register identifier, memory addressing information, etc.), a displacement value 1807, and / or an immediate value 1809. Note that some instructions utilize some or all of the fields of the format, while other instructions may only use the opcode 1803 field. In some examples, the order shown is the order in which these fields will be encoded, however, it should be appreciated that in other examples, these fields may be encoded, combined, etc. in a different order.

[0297] (One or more) prefix (one or more) field 1801 modifies the instruction when used. In some examples, one or more prefixes are used to: repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), provide partial overwrites (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), perform bus lock operations, and / or change operands (e.g., 0x66) and address sizes (e.g., 0x67). Certain instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered "legacy" prefixes. Other prefixes (one or more examples of which are described in detail herein) indicate and / or provide further capabilities, such as specifying specific registers, etc. Other prefixes are usually followed by a "legacy" prefix.

[0298] The opcode field 1803 is used to at least partially define the operation to be performed when decoding the instruction. In some examples, the length of the primary opcode encoded in the opcode field 1803 is one, two or three bytes. In other examples, the primary opcode can be a different length. The additional 3-bit opcode field is sometimes encoded in another field.

[0299] The addressing information field 1805 is used to address one or more operands of the instruction, such as one or more registers or locations in memory. Fig.19 An example of an addressing information field 1805 is illustrated. In this illustration, an optional MOD R / M byte 1902 and an optional scale, index, base (SIB) byte 1904 are shown. The MOD R / M byte 1902 and SIB byte 1904 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. Note that both of these fields are optional, as not all instructions include one or more of these fields. The MOD R / M byte 1902 includes a MOD field 1942, a register (reg) field 1944, and an R / M field 1946.

[0300] The content of MOD field 1942 distinguishes between memory access and non-memory access modes. In some examples, when MOD field 1942 has a binary value of 11 (11b), register direct addressing mode is utilized, otherwise, register indirect addressing mode is used.

[0301] Register field 1944 may encode a destination register operand or a source register operand, or may encode an opcode extension without being used to encode any instruction operand. The contents of register field 1944 specify the location (in a register or memory) of the source or destination operand, either directly or through address generation. In some examples, register field 1944 is supplemented with additional bits from a prefix (e.g., prefix 1801) to allow for greater addressing.

[0302] R / M field 1946 may be used to encode an instruction operand that references a memory address, or may be used to encode a destination register operand or a source register operand. Note that in some examples, R / M field 1946 may be combined with MOD field 1942 to indicate an addressing mode.

[0303] SIB byte 1904 includes a scale field 1952, an index field 1954, and a base address field 1956 for generating addresses. Scale field 1952 indicates a scale factor. Index field 1954 specifies the index register to be used. In some examples, index field 1954 is supplemented with additional bits from a prefix (e.g., prefix 1801) to allow for greater addressing. Base address field 1956 specifies the base address register to be used. In some examples, base address field 1956 is supplemented with additional bits from a prefix (e.g., prefix 1801) to allow for greater addressing. In practice, the content of scale field 1952 allows the content of index field 1954 to be scaled for memory address generation (e.g., for address generation using 2 scale * index + base address). Some addressing forms utilize displacement values ​​to generate memory addresses. For example, a memory address can be generated according to 2 scale * index + base address + displacement, index * scale + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. The displacement may be a value of 1 byte, 2 bytes, 4 bytes, etc. In some examples, the displacement field 1807 provides this value. Additionally, in some examples, the displacement factor is encoded in the MOD field of the addressing information field 1805, which indicates a compressed displacement scheme for which the displacement value is calculated and stored in the displacement field 1807.

[0304] In some examples, the immediate value field 1809 specifies an immediate value for the instruction. The immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, etc.

[0305] Fig. 20An example of a first prefix 1801(A) is illustrated. In some examples, the first prefix 1801(A) is an example of a REX prefix. Instructions using this prefix can specify general registers, 64-bit packed data registers (e.g., single instruction multiple data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0306] Instructions using the first prefix 1801(A) can use a 3-bit field to specify up to three registers, depending on the format: 1) using the reg field 1944 and the R / M field 1946 of the MOD R / M byte 1902; 2) using the MOD R / M byte 1902 with the SIB byte 1904, including using the reg field 1944 as well as the base field 1956 and the index field 1954; or 3) using the register field of the opcode.

[0307] In the first prefix 1801 (A), the bit positions of payload bytes 7:4 are set to 0100. Bit position 3 (W) can be used to determine the operand size, but cannot determine the operand width alone. Thus, when W=0, the operand size is determined by the code segment descriptor (CS.D), and when W=1, the operand size is 64 bits.

[0308] Note that adding another bit allows 16 (24) registers to be addressed, whereas the MOD R / M reg field 1944 and the MODR / MR / M field 1946 alone are only capable of addressing 8 registers each.

[0309] In the first prefix 1801(A), bit position 2 (R) may be an extension of the MOD R / M reg field 1944 and may be used to modify the MOD R / M reg field 1944 when the MOD R / M reg field 1944 encodes a general register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. When the MOD R / M byte 1902 specifies other registers or defines an extended opcode, R is ignored.

[0310] Bit position 1 (X) may modify the SIB byte index field 1954 .

[0311] Bit position 0 (B) may modify the base address in MOD R / MR / M field 1946 or SIB byte base address field 1956; or it may modify the opcode register field used to access a general register (eg, general register 1725). Figures 21A-21D An example of how the R, X, and B fields of the first prefix 1801 (A) are used is illustrated. Fig.21AIt is illustrated that when the SIB byte 1904 is not used for memory addressing, the R and B from the first prefix 1801 (A) are used to extend the reg field 1944 and the R / M field 1946 of the MOD R / M byte 1902. Fig.21B It is illustrated that when the SIB byte 1904 is not used (register-register addressing), the R and B from the first prefix 1801 (A) are used to extend the reg field 1944 and the R / M field 1946 of the MOD R / M byte 1902. Fig. 21C It is illustrated that when the SIB byte 1904 is used for memory addressing, the R, X, and B from the first prefix 1801 (A) are used to extend the reg field 1944 of the MOD R / M byte 1902 as well as the index field 1954 and the base address field 1956. Fig.21D It is illustrated that when a register is encoded in the opcode 1803 , the B from the first prefix 1801 (A) is used to extend the reg field 1944 of the MOD R / M byte 1902 .

[0312] Figures 22A-22B An example of a second prefix 1801(B) is illustrated. In some examples, the second prefix 1801(B) is an example of a VEX prefix. The second prefix 1801(B) encoding allows instructions to have more than two operands and allows SIMD vector registers (e.g., vector / SIMD registers 1710) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 1801(B) provides a three-operand (or more) syntax. For example, previous two-operand instructions performed operations such as A=A+B, which would overwrite the source operand. The use of the second prefix 1801(B) enables operands to perform non-destructive operations, such as A=B+C

[0313] In some examples, the second prefix 1801(B) has two forms: a two-byte form and a three-byte form. The two-byte second prefix 1801(B) is mainly used for 128-bit, scalar, and some 256-bit instructions; while the three-byte second prefix 1801(B) provides a compact replacement for 3-byte opcode instructions and the first prefix 1801(A).

[0314] Fig.22AAn example of a two-byte form of a second prefix 1801 (B) is illustrated. In some examples, the format field 2201 (byte 0 2203) contains a value of C5H. In some examples, byte 1 2205 includes an "R" value in position [7]. This value is the complement of the "R" value of the first prefix 1801 (A). Position [2] is used to specify the length (L) of the vector (wherein value 0 is a scalar or 128-bit vector, and value 1 is a 256-bit vector). Position [1:0] provides opcode scalability equivalent to some legacy prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, 11=F2H). Bits [6:3], shown as vvvv, may be used to: 1) encode a first source register operand, which is specified in inverted (1s complement) form and is valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in 1s complement form for certain vector shifts; or 3) encode no operand, in which case the field is reserved and should contain some value, such as 1111b.

[0315] Instructions using this prefix may use MOD R / MR / M field 1946 to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0316] Instructions using this prefix may use the MOD R / M reg field 1944 to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0317] For instruction syntax supporting four operands vvvv, MOD R / MR / M field 1946 and MOD R / M reg field 1944 encode three of the four operands. Bits [7:4] of immediate value field 1809 are then used to encode the third source register operand.

[0318] Fig. 22B An example of a three-byte form of the second prefix 1801 (B) is illustrated. In some examples, the format field 2211 (byte 0 2213) contains the value C4H. Byte 1 2215 includes "R", "X", and "B" in positions [7:5], which are the complements of the same values ​​of the first prefix 1801 (A). Bits [4:0] (shown as mmmmm) of byte 1 2215 include content for encoding one or more implicit leading opcode bytes as needed. For example, 00001 implies a leading opcode of 0FH, 00010 implies a leading opcode of 0F38H, 00011 implies a leading opcode of 0F3AH, and so on.

[0319] Similar to the W of the first prefix 1801 (A), bit [7] of byte 2 2217 is used, including to help determine the size of the promotable operand. Bit [2] is used to specify the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector, and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensibility equivalent to some legacy prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, 11=F2H). Bits [6:3], shown as vvvv, may be used to: 1) encode the first source register operand, which is specified in inverted (1s complement) form and is valid for instructions with 2 or more source operands; 2) encode the destination register operand, which is specified in 1s complement form for certain vector shifts; or 3) do not encode any operand, this field is reserved and should contain a value such as 1111b.

[0320] Instructions using this prefix may use MOD R / MR / M field 1946 to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0321] Instructions using this prefix may use the MOD R / M reg field 1944 to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0322] For instruction syntax supporting four operands vvvv, MOD R / MR / M field 1946 and MOD R / M reg field 1944 encode three of the four operands. Bits [7:4] of immediate value field 1809 are then used to encode a third source register operand.

[0323] Fig.23 An example of a third prefix 1801(C) is illustrated. In some examples, the third prefix 1801(C) is an example of an EVEX prefix. The third prefix 1801(C) is a four-byte prefix.

[0324] The third prefix 1801(C) may encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some examples, write masking / operation masking (opmask) (see previous figures (such as Fig.17 ) or predicted instructions utilize this prefix. The operation mask register allows conditional processing or selection control. The second prefix 1801 (B) is used to encode the operation mask instruction, the source / destination operand of the operation mask instruction is the operation mask register, and the contents of the operation mask register are treated as a single value.

[0325] The third prefix 1801(C) may encode functionality specific to the instruction class (e.g., a packed instruction with "load+op" semantics may support an embedded broadcast functionality, a floating-point instruction with rounding semantics may support a static rounding functionality, a floating-point instruction with non-rounding arithmetic semantics may support a "suppress all exceptions" functionality, and so on).

[0326] The first byte of the third prefix 1801 (C) is the format field 2311, which in some examples has a value of 62 H. Subsequent bytes are referred to as payload bytes 2315-2319, and together form a 24-bit value of P[23:0], thereby providing specific capabilities (described in detail herein) in the form of one or more fields.

[0327] In some examples, P[1:0] of payload byte 2319 is the same as the lower two bits mm. P[3:2] is reserved in some examples. When combined with P[7] and MOD R / M reg field 1944, bit P[4] (R') allows access to the upper 16-bit vector register set. When SIB type addressing is not required, P[6] can also provide access to the upper 16-bit vector registers. P[7:5] consists of R, X, and B, which are operand specifier modifier bits for vector register, general register, memory addressing, and when combined with MOD R / M reg field 1944 and MOD R / MR / M field 1946, allow access to the next set of 8 registers outside the lower 8 registers. P[9:8] provides opcode extensibility equivalent to some legacy prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, 11=F2H). In some examples, P

[10] is a fixed value of 1. P[14:11] is shown as vvvv and can be used to: 1) encode the first source register operand, which is specified in inverted (1s complement) form and is valid for instructions with 2 or more source operands; 2) encode the destination register operand, which is specified in 1s complement form for certain vector shifts; or 3) do not encode any operand, the field is reserved and should contain some value, such as 1111b.

[0328] P

[15] is similar to W of the first prefix 1801(A) and the second prefix 1801(B), and can be used as an opcode extension bit or operand size promotion.

[0329] P[18:16] specifies the index of a register in an operation mask (write mask) register (e.g., write mask / assert register 1715). In some examples, a particular value aaa=000 has a special behavior that implies that no operation mask is used for a particular instruction (this can be implemented in a variety of ways, including using an operation mask hardwired to all 1s, or hardware that bypasses the mask hardware). When merged, the vector mask allows any set of elements in the destination to be protected from being updated during the execution of any operation (specified by the basic operation and the expansion operation); in some other examples, the old value of each element of the destination is retained, where the corresponding mask bit has a 0. Conversely, when the zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the basic operation and the expansion operation); in some examples, when the corresponding mask bit has a 0 value, the elements of the destination are set to 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span from the first to the last element modified); however, the elements modified are not necessarily contiguous. Thus, the operation mask field enables partial vector operations, including loads, stores, arithmetic, logical, etc. Although examples are described in which the contents of the operation mask field select one of a plurality of operation mask registers containing an operation mask to be used (and thus the contents of the operation mask field indirectly identify the masking to be performed), alternative or additional examples allow the contents of the mask write field to directly specify the masking to be performed.

[0330] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that can use P

[19] to access the upper 16 vector registers. P

[20] encodes multiple features that vary in different classes of instructions and can affect the meaning of the vector length / rounding control specifier field (P[22:21]). P

[23] indicates support for merging writemasks (e.g., when set to 0) or support for zeroing and merging writemasks (e.g., when set to 1).

[0331] An example of using the third prefix 1801 (C) to encode a register in an instruction is described in detail in the following table.

[0332]

[0333] Table 2: 32-register support in 64-bit mode

[0334] [2:0] Register Type Common Uses REG MOD R / M reg GPR, vector Source or destination VVVV vvvv GPR, vector Second source or destination RM MOD R / MR / M GPR, vector First source or destination BASE MOD R / MR / M GPR Memory addressing INDEX SIB.Index GPR Memory addressing VIDX SIB.Index vector VSIB Memory Addressing

[0335] Table 3: Encoded register specifiers in 32-bit mode

[0336]

[0337]

[0338] Table 4: Operation Mask Register Specifier Encoding

[0339] Graphics Execution Unit

[0340] Figures 24A-24B Thread execution logic 2400 is illustrated including an array of processing elements employed in a graphics processor core according to examples described herein. Figures 24A-24B Elements in the drawings having the same reference numerals (or names) as elements of any other figure herein may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto. Fig.24A represents an execution unit within a general-purpose graphics processor, and Fig. 24B Represents an execution unit that can be used within a compute accelerator.

[0341] like Fig.24A As shown, in some examples, the thread execution logic 2400 includes a shader processor 2402, a thread dispatcher 2404, an instruction cache 2406, a scalable execution unit array including a plurality of execution units 2408A-2408N, a sampler 2410, a shared local memory 2411, a data cache 2412, and a data port 2414. In some examples, the scalable execution unit array can be dynamically scaled by enabling or disabling one or more execution units (e.g., any one of execution units 2408A, 2408B, 2408C, 2408D to 2408N-1 and 2408N) based on the computational requirements of the workload. In some examples, the included components are interconnected via an interconnect structure linked to each component. In some examples, the thread execution logic 2400 includes one or more connections to a memory (such as a system memory or a cache memory) through the instruction cache 2406, the data port 2414, the sampler 2410, and one or more of the execution units 2408A-2408N. In some examples, each execution unit (e.g., 2408A) is an independent programmable general-purpose computing unit that is capable of executing multiple simultaneous hardware threads while processing multiple data elements in parallel for each thread. In various examples, the array of execution units 2408A-2408N is scalable to include any number of separate execution units.

[0342] In some examples, execution units 2408A-2408N are primarily used to execute shader programs. Shader processor 2402 can process various shader programs and dispatch execution threads associated with shader programs via thread dispatcher 2404. In some examples, thread dispatcher includes logic for arbitrating thread initiation requests from graphics and media pipelines and instantiating the requested threads on one or more execution units in execution units 2408A-2408N. For example, a geometry pipeline can dispatch vertex shaders, tessellation shaders, or geometry shaders to thread execution logic for processing. In some examples, thread dispatcher 2404 can also process runtime thread generation requests from the shader program being executed.

[0343] In some examples, execution units 2408A-2408N support an instruction set including native support for many standard 3D graphics shader instructions, so that shader programs from graphics libraries (e.g., Direct 3D and OpenGL) are executed with minimal translation. The execution units support vertex and geometry processing (e.g., vertex programs, geometry programs, vertex shaders), pixel processing (e.g., pixel shaders, segment shaders), and general processing (e.g., compute and media shaders). Each of the execution units 2408A-2408N is capable of multi-issue single instruction multiple data (SIMD) execution, and multi-threaded operations enable efficient execution environments in the face of higher latency memory accesses. Each hardware thread in each execution unit has a dedicated high-bandwidth register file and an associated independent thread state. Execution is multi-issue per clock to the pipeline, which is capable of integer, single-precision and double-precision floating-point operations, SIMD branching capabilities, logical operations, transcendental operations, and other miscellaneous operations. When waiting for data from one of the memory or shared functions, the dependency logic within the execution unit 2408A-2408N causes the waiting thread to sleep until the requested data is returned. While the waiting thread is sleeping, hardware resources can be dedicated to processing other threads. For example, during the delay period associated with the vertex shader operation, the execution unit can perform operations for a pixel shader, a segment shader, or another type of shader program (including different vertex shaders). Various examples can be applied to use execution using single instruction multiple threads (SIMT) as an alternative to the use of SIMD, or as an addition to the use of SIMD. References to SIMD cores or operations can also apply to SIMT, or to a combination of SIMD and SIMT.

[0344] Each execution unit in the execution units 2408A-2408N operates on an array of data elements. The number of data elements is the "execution size," or the number of lanes used for the instruction. An execution lane is a logical execution unit used for data element access, masking, and flow control within an instruction. The number of lanes can be independent of the number of physical arithmetic logic units (ALUs) or floating point units (FPUs) of a particular graphics processor. In some examples, the execution units 2408A-2408N support integer and floating point data types. The execution unit instruction set includes SIMD instructions. Various data elements can be stored in registers as packed data types, and the execution units will process the various elements based on the data size of the elements. For example, when operating on a 256-bit wide vector, the 256 bits of the vector are stored in registers and the execution unit operates on the vector as four individual 64-bit packed data elements (quadword (QW) sized data elements), eight individual 32-bit packed data elements (doubleword (DW) sized data elements), sixteen individual 16-bit packed data elements (word (W) sized data elements), or thirty-two individual 8-bit data elements (byte (B) sized data elements). However, different vector widths and register sizes are possible.

[0345] In some examples, one or more execution units may be combined into a fused execution unit 2409A-2409N, which has a thread control logic (2407A-2407N) common to the fused EU. Multiple EUs may be fused into an EU group. Each EU in the fused EU group may be configured to execute a separate SIMD hardware thread. The number of EUs in the fused EU group may vary according to the example. In addition, various SIMD widths may be executed EU by EU, including but not limited to SIMD8, SIMD16, and SIMD32. Each fused graphics execution unit 2409A-2409N includes at least two execution units. For example, the fused execution unit 2409A includes a first EU 2408A, a second EU 2408B, and a thread control logic 2407A common to the first EU 2408A and the second EU 2408B. Thread control logic 2407A controls threads executing on fused graphics execution unit 2409A, allowing each EU in fused execution units 2409A-2409N to execute using a common instruction pointer register.

[0346] One or more internal instruction caches (e.g., 2406) are included in the thread execution logic 2400 to cache thread instructions for the execution unit. In some examples, one or more data caches (e.g., 2412) are included to cache thread data during thread execution. Threads executing on the execution logic 2400 may also store explicitly managed data in the shared local memory 2411. In some examples, a sampler 2410 is included to provide texture sampling for 3D operations and media sampling for media operations. In some examples, the sampler 2410 includes a specialized texture or media sampling function to process texture or media data during the sampling process before providing the sampled data to the execution unit.

[0347] During execution, the graphics pipeline and the media pipeline send thread initiation requests to the thread execution logic 2400 via the thread generation and dispatch logic. Once the group of geometric objects has been processed and rasterized into pixel data, pixel processor logic (e.g., pixel shader logic, segment shader logic, etc.) within the shader processor 2402 is called to further calculate output information and cause the results to be written to an output surface (e.g., a color buffer, a depth buffer, a stencil buffer, etc.). In some examples, the pixel shader or segment shader calculates values ​​for various vertex attributes to be interpolated across the rasterized objects. In some examples, the pixel processor logic within the shader processor 2402 then executes a pixel or segment shader program provided by an application programming interface (API). To execute the shader program, the shader processor 2402 dispatches threads to execution units (e.g., 2408A) via a thread dispatcher 2404. In some examples, the shader processor 2402 uses texture sampling logic in a sampler 2410 to access texture data stored in a texture map in memory. Arithmetic operations on the texture data and the input geometric data calculate pixel color data for each geometric segment, or discard one or more pixels from further processing.

[0348] In some examples, data port 2414 provides a memory access mechanism for thread execution logic 2400 to output processed data to memory for further processing on a graphics processor output pipeline. In some examples, data port 2414 includes or is coupled to one or more cache memories (e.g., data cache 2412) to cache data for memory access via the data port.

[0349] In some examples, execution logic 2400 may also include a ray tracer 2405, which may provide ray tracing acceleration functionality. Ray tracer 2405 may support a ray tracing instruction set that includes instructions / functions for ray generation.

[0350] Fig. 24B 2426, and a set of dedicated integer SIMD ALUs 2435. The GRF 2424 and ARF 2426 include a set of general register files and architectural register files associated with each simultaneous hardware thread that may be active in the graphics execution unit 2408. In some examples, the per-thread architectural state is maintained in the ARF 2426, while data used during thread execution is stored in the GRF 2424. The execution state of each thread, including the instruction pointer of each thread, can be saved in thread-specific registers in the ARF 2426.

[0351] In some examples, graphics execution unit 2408 has an architecture that is a combination of simultaneous multithreading (SMT) and fine-grained interleaved multithreading (IMT). The architecture has a modular configuration that can be fine-tuned at design time based on the target number of simultaneous threads and the number of registers per execution unit, where execution unit resources are divided across logic for executing multiple simultaneous threads. The number of logical threads that can be executed by graphics execution unit 2408 is not limited to the number of hardware threads, and multiple logical threads can be assigned to each hardware thread.

[0352] In some examples, the graphics execution unit 2408 may issue multiple instructions together, each of which may be a different instruction. The thread arbiter 2422 of the graphics execution unit thread 2408 may dispatch the instruction to one of the following for execution: a send unit 2430, a branch unit 2432, or (one or more) SIMD FPUs 2434. Each execution thread may access 128 general registers within the GRF 2424, each of which may store 32 bytes, which may be accessed as a SIMD 8 element vector of 32-bit data elements. In some examples, each execution unit thread may access 4 kilobytes within the GRF 2424, although the examples are not limited thereto, and more or less register resources may be provided in other examples. In some examples, the graphics execution unit 2408 is partitioned into seven hardware threads, which may independently perform computational operations, although the number of threads per execution unit may also vary depending on the example. For example, in some examples, up to 16 hardware threads are supported. In an example where seven threads can access 4 kilobytes, GRF 2424 can store a total of 28 kilobytes. In a case where 16 threads can access 4 kilobytes, GRF 2424 can store a total of 64 kilobytes. Flexible addressing modes can allow registers to be addressed together to efficiently build wider registers or represent strided rectangular block data structures.

[0353] In some examples, memory operations, sampler operations, and other higher latency system communications are dispatched via "send" instructions executed by message passing send unit 2430. In some examples, branch instructions are dispatched to a dedicated branch unit 2432 to facilitate SIMD divergence and eventual convergence.

[0354] In some examples, the graphics execution unit 2408 includes one or more SIMD floating point units (FPUs) 2434 to perform floating point operations. In some examples, (one or more) FPUs 2434 also support integer calculations. In some examples, (one or more) FPUs 2434 can SIMD perform up to M 32-bit floating point (or integer) operations, or SIMD perform up to 2M 16-bit integers or 16-bit floating point operations. In some examples, at least one FPU in (one or more) FPUs provides extended mathematical capabilities to support high throughput transcendental math functions and double-precision 64-bit floating points. In some examples, a set of 8-bit integer SIMD ALUs 2435 also exists and can be specifically optimized to perform operations associated with machine learning calculations.

[0355] In some examples, an array of multiple instances of graphics execution unit 2408 can be instantiated in graphics sub-core groupings (e.g., sub-slices). For scalability, product architects can choose the exact number of execution units per sub-core grouping. In some examples, execution unit 2408 can execute instructions across multiple execution lanes. In another example, each thread executed on graphics execution unit 2408 executes on a different lane.

[0356] Fig.25 An additional execution unit 2500 according to an example is illustrated. In some examples, the execution unit 2500 includes a thread control unit 2501, a thread state unit 2502, an instruction fetch / prefetch unit 2503, and an instruction decode unit 2504. The execution unit 2500 additionally includes a register file 2506, which stores registers that can be assigned to hardware threads within the execution unit. The execution unit 2500 additionally includes a dispatch unit 2507 and a branch unit 2508. In some examples, the dispatch unit 2507 and the branch unit 2508 can be connected to Fig. 24B Send unit 2430 and branch unit 2432 of graphics execution unit 2408 operate similarly.

[0357] The execution unit 2500 also includes a computing unit 2510, which includes a plurality of different types of functional units. In some examples, the computing unit 2510 includes an ALU unit 2511, which includes an arithmetic logic unit array. The ALU unit 2511 can be configured to perform 64-bit, 32-bit and 16-bit integer and floating-point operations. Integer and floating-point operations can be performed simultaneously. The computing unit 2510 can also include a systolic array 2512 and a mathematical unit 2513. The systolic array 2512 includes a data processing unit network with a width W and a depth D, which can be used to perform vector or other data parallel operations in a systolic manner. In some examples, the systolic array 2512 can be configured to perform matrix operations, such as matrix dot product operations. In some examples, the systolic array 2512 supports 16-bit floating-point operations, as well as 8-bit and 4-bit integer operations. In some examples, the systolic array 2512 can be configured to accelerate machine learning operations. In such an example, systolic array 2512 may be configured with support for the bfloat 16-bit floating point format. In some examples, a math unit 2513 may be included to perform a specific subset of math operations in a more efficient and lower power manner than ALU unit 2511. Math unit 2513 may include a variation of math logic that may be found in the shared functional logic of the graphics processing engine provided by other examples. In some examples, math unit 2513 may be configured to perform 32-bit and 64-bit floating point operations.

[0358] Thread control unit 2501 includes logic for controlling the execution of threads within an execution unit. Thread control unit 2501 may include thread arbitration logic to start, stop, and preempt the execution of threads within execution unit 2500. Thread state unit 2502 may be used to store thread states assigned to threads executing on execution unit 2500. Storing thread states within execution unit 2500 enables quick preemption of threads when they become blocked or idle. Instruction fetch / prefetch unit 2503 may fetch instructions from instruction caches of higher level execution logic (e.g., Fig.24A The instruction fetch / prefetch unit 2503 may also issue a prefetch request for instructions to be loaded into the instruction cache based on an analysis of the current execution thread. The instruction decode unit 2504 may be used to decode instructions to be executed by the computing unit. In some examples, the instruction decode unit 2504 may be used as a secondary decoder to decode complex instructions into constituent micro-operations.

[0359] Execution unit 2500 additionally includes a register file 2506 that can be used by hardware threads executing on execution unit 2500. Registers in register file 2506 can be divided across logic used to execute multiple simultaneous threads within compute unit 2510 of execution unit 2500. The number of logical threads that can be executed by graphics execution unit 2500 is not limited to the number of hardware threads, and multiple logical threads can be assigned to each hardware thread. The size of register file 2506 can vary across examples based on the number of hardware threads supported. In some examples, register renaming can be used to dynamically allocate registers to hardware threads.

[0360] Fig.26 2600 is a block diagram illustrating a graphics processor instruction format 2600 according to some examples. In one or more examples, a graphics processor execution unit supports an instruction set having instructions in a variety of formats. Solid line boxes illustrate components that are typically included in execution unit instructions, while dashed lines include components that are optional or included only in a subset of instructions. In some examples, the described and illustrated instruction format 2600 are macroinstructions in that they are instructions provided to the execution unit, as opposed to micro-operations that result from instruction decoding that occurs once the instruction is processed.

[0361] In some examples, the graphics processor execution unit natively supports instructions in 128-bit instruction format 2610. Based on the selected instructions, instruction options, and the number of operands, 64-bit compressed instruction format 2630 can be used for some instructions. Native 128-bit instruction format 2610 provides access to all instruction options, while some options and operations are restricted in 64-bit format 2630. Native instructions available in 64-bit format 2630 vary from example to example. In some examples, the index value set in index field 2613 is used to partially compress instructions. The execution unit hardware references a compression table set based on the index value, and uses the compression table output to reconstruct native instructions in 128-bit instruction format 2610. Instructions of other sizes and formats can be used. For each format, the instruction opcode 2612 defines the operation to be performed by the execution unit. The execution unit executes each instruction in parallel across multiple data elements of each operand. For example, in response to an addition instruction, the execution unit performs simultaneous addition operations across each color channel representing a texture element or a picture element. By default, the execution unit executes each instruction across all data lanes of the operands. In some examples, instruction control field 2614 enables control of certain execution options, such as lane selection (e.g., prediction) and data lane order (e.g., swizzle). For instructions in 128-bit instruction format 2610, execution size field 2616 limits the number of data lanes that will be executed in parallel. In some examples, execution size field 2616 is not available for 64-bit compact instruction format 2630.

[0362] Some execution unit instructions have up to three operands, including two source operands src0 2620, src1 2622, and one destination 2618. In some examples, the execution unit supports dual destination instructions, where one of the destinations is implicit. Data manipulation instructions may have a third source operand (e.g., SRC2 2624), where the instruction opcode 2612 determines the number of source operands. The last source operand of an instruction may be an immediate (e.g., hard-coded) value passed with the instruction.

[0363] In some examples, the 128-bit instruction format 2610 includes an access / addressing mode field 2626 that specifies, for example, whether direct register addressing mode or indirect register addressing mode is used. When direct register addressing mode is used, the register address of one or more operands is provided directly by bits in the instruction.

[0364] In some examples, the 128-bit instruction format 2610 includes an access / addressing mode field 2626 that specifies an addressing mode and / or access mode for the instruction. In some examples, the access mode is used to define data access alignment for the instruction. Some examples support access modes including a 16-byte aligned access mode and a 1-byte aligned access mode, wherein the byte alignment of the access mode determines the access alignment of the instruction operand. For example, when in a first mode, the instruction may use byte-aligned addressing for source and destination operands, and when in a second mode, the instruction may use 16-byte aligned addressing for all source and destination operands.

[0365] In some examples, the addressing mode portion of the access / addressing mode field 2626 determines whether the instruction uses direct addressing or indirect addressing. When direct register addressing mode is used, the bits in the instruction directly provide the register address of one or more operands. When indirect register addressing mode is used, the register address of one or more operands can be calculated based on the address register value and the address immediate field in the instruction.

[0366] In some examples, instructions are grouped based on the opcode 2612 bit field to simplify opcode decoding 2640. For 8-bit opcodes, the 4th, 5th and 6th bits allow the execution unit to determine the type of opcode. The precise opcode grouping shown is only an example. In some examples, the move and logic opcode group 2642 includes data movement and logic instructions (e.g., move (mov), compare (cmp)). In some examples, the move and logic group 2642 shares five most significant bits (MSB), where the move (mov) instruction is in the form of 0000xxxxb, and the logic instruction is in the form of 0001xxxxb. The flow control instruction group 2644 (e.g., call, jump (jmp)) includes instructions in the form of 0010xxxxb (e.g., 0x20). Miscellaneous instruction group 2646 includes a mixture of instructions, including synchronization instructions (e.g., wait, send) in the form of 0011xxxxb (e.g., 0x30). The parallel math instruction group 2648 includes component-by-component arithmetic instructions (e.g., addition, multiplication (mul)) in the form of 0100xxxxb (e.g., 0x40). The parallel math group 2648 performs arithmetic operations in parallel across data channels. The vector math group 2650 includes arithmetic instructions (e.g., dp4) in the form of 0101xxxxb (e.g., 0x50). The vector math group performs arithmetic on vector operands, such as dot product calculations. In some examples, the illustrated opcode decode 2640 can be used to determine which portion of the execution unit will be used to execute the decoded instruction. For example, some instructions can be designated as systolic instructions to be executed by a systolic array. Other instructions such as ray tracing instructions (not shown) can be routed to a ray tracing core or ray tracing logic within a slice or partition of the execution logic.

[0367] Graphics Pipeline

[0368] Fig. 27 is a block diagram of another example of a graphics processor 2700 . Fig. 27 Elements having the same reference number (or name) as elements of any other figure herein may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto.

[0369] In some examples, graphics processor 2700 includes geometry pipeline 2720, media pipeline 2730, display engine 2740, thread execution logic 2750, and rendering output pipeline 2770. In some examples, graphics processor 2700 is a graphics processor within a multi-core processing system that includes one or more general-purpose processing cores. The graphics processor is controlled by register writes to one or more control registers (not shown), or by commands issued to graphics processor 2700 via ring interconnect 2702. In some examples, ring interconnect 2702 couples graphics processor 2700 to other processing components, such as other graphics processors or general-purpose processors. Commands from ring interconnect 2702 are interpreted by command streamer 2703, which provides instructions to individual components of geometry pipeline 2720 or media pipeline 2730.

[0370] In some examples, command streamer 2703 directs the operation of vertex fetcher 2705, which reads vertex data from memory and executes vertex processing commands provided by command streamer 2703. In some examples, vertex fetcher 2705 provides vertex data to vertex shader 2707, which performs coordinate space transformation and lighting operations on each vertex. In some examples, vertex fetcher 2705 and vertex shader 2707 execute vertex processing instructions by dispatching execution threads to execution units 2752A-2752B via thread dispatcher 2731.

[0371] In some examples, execution units 2752A-2752B are vector processor arrays with instruction sets for performing graphics and media operations. In some examples, execution units 2752A-2752B have an attached L1 cache 2751 that is dedicated to each array or shared between arrays. The cache can be configured as a data cache, an instruction cache, or a single cache that is partitioned to contain data and instructions in different partitions.

[0372] In some examples, the geometry pipeline 2720 includes a tessellation component to perform hardware accelerated tessellation of 3D objects. In some examples, the programmable hull shader 2711 configures the tessellation operation. The programmable domain shader 2717 provides back-end evaluation of the tessellation output. The tessellation 2713 operates under the direction of the hull shader 2711 and contains dedicated logic to generate a collection of detailed geometric objects based on a coarse geometric model provided as input to the geometry pipeline 2720. In some examples, if tessellation is not used, the tessellation components (e.g., the hull shader 2711, the tessellation 2713, and the domain shader 2717) can be bypassed.

[0373] In some examples, the complete geometric object may be processed by the geometry shader 2719 via one or more threads dispatched to execution units 2752A-2752B, or may proceed directly to the clipper 2729. In some examples, the geometry shader operates on the entire geometric object, rather than on vertices or vertex patches as in previous stages of the graphics pipeline. If tessellation is disabled, the geometry shader 2719 receives input from the vertex shader 2707. In some examples, if the tessellation unit is disabled, the geometry shader 2719 may be programmed by a geometry shader program to perform geometry tessellation.

[0374] Before rasterization, the clipper 2729 processes the vertex data. The clipper 2729 can be a fixed function clipper or a programmable clipper with clipping and geometry shader functions. In some examples, the rasterizer and depth test component 2773 in the render output pipeline 2770 dispatches a pixel shader to convert the geometric object into a per-pixel representation. In some examples, the pixel shader logic is included in the thread execution logic 2750. In some examples, the application can bypass the rasterizer and depth test component 2773 and access the unrasterized vertex data via the outflow unit 2723.

[0375] The graphics processor 2700 has an interconnect bus, an interconnect structure, or some other interconnect mechanism that allows data and messages to be passed between the main components of the processor. In some examples, execution units 2752A-2752B and associated logic units (e.g., L1 cache 2751, sampler 2754, texture cache 2758, etc.) are interconnected via data ports 2756 to perform memory accesses and communicate with the rendering output pipeline components of the processor. In some examples, samplers 2754, caches 2751, 2758, and execution units 2752A-2752B each have a separate memory access path. In some examples, texture cache 2758 can also be configured as a sampler cache.

[0376] In some examples, the render output pipeline 2770 includes a rasterizer and depth test component 2773 that converts vertex-based objects into associated pixel-based representations. In some examples, the rasterizer logic includes a windower / masker unit to perform fixed-function triangle and line rasterization. In some examples, an associated render buffer 2778 and depth buffer 2779 are also available. The pixel operation component 2777 performs pixel-based operations on data, although in some instances, pixel operations associated with 2D operations (e.g., bit-block image transfers with blending) are performed by the 2D engine 2741, or replaced by the display controller 2743 using an overlay display plane when displaying. In some examples, a shared L3 cache 2775 is available to all graphics components, allowing data to be shared without using main system memory.

[0377] In some examples, the graphics processor media pipeline 2730 includes a media engine 2737 and a video front end 2734. In some examples, the video front end 2734 receives pipeline commands from the command streamer 2703. In some examples, the media pipeline 2730 includes a separate command streamer. In some examples, the video front end 2734 processes media commands before sending them to the media engine 2737. In some examples, the media engine 2737 includes a thread generation function to generate threads for dispatching to the thread execution logic 2750 via the thread dispatcher 2731.

[0378] In some examples, graphics processor 2700 includes display engine 2740. In some examples, display engine 2740 is external to processor 2700 and is coupled to the graphics processor via ring interconnect 2702 or some other interconnect bus or structure. In some examples, display engine 2740 includes 2D engine 2741 and display controller 2743. In some examples, display engine 2740 contains dedicated logic that can operate independently of the 3D pipeline. In some examples, display controller 2743 is coupled to a display device (not shown), which can be a system integrated display device, such as in a laptop computer, or an external display device attached via a display device connector.

[0379] In some examples, the geometry pipeline 2720 and the media pipeline 2730 may be configured to perform operations based on multiple graphics and media programming interfaces and are not dedicated to any one application programming interface (API). In some examples, the driver software for the graphics processor translates API calls dedicated to a specific graphics or media library into commands that can be processed by the graphics processor. In some examples, support is provided for all of the Open Graphics Library (OpenGL), Open Computing Language (OpenCL) and / or Vulkan graphics and computing APIs from the Khronos Group. In some examples, support may also be provided for the Direct3D library from Microsoft. In some examples, a combination of these libraries may be supported. Support may also be provided for the open source computer vision library (OpenCV). If it is possible to map from the pipeline of a future API to the pipeline of a graphics processor, future APIs with compatible 3D pipelines will also be supported.

[0380] Graphics pipeline programming

[0381] Fig.28A is a block diagram illustrating a graphics processor command format 2800 according to some examples. Fig.28B is a block diagram illustrating a graphics processor command sequence 2810 according to an example. Fig.28A The solid-line boxes in illustrate components that are typically included in a graphics command, while the dashed lines include components that are optional or included only in a subset of the graphics commands. Fig.28A The exemplary graphics processor command format 2800 includes a data field to identify the client 2802, a command operation code (opcode) 2804, and data for the command 2806. Some commands also include a sub-opcode 2805 and a command size 2808.

[0382] In some examples, client 2802 specifies a client unit of a graphics device that processes command data. In some examples, a graphics processor command parser checks the client field of each command to adjust further processing of the command and routes the command data to the appropriate client unit. In some examples, a graphics processor client unit includes a memory interface unit, a rendering unit, a 2D unit, a 3D unit, and a media unit. Each client unit has a corresponding processing pipeline for processing commands. Once a client unit receives a command, the client unit reads an opcode 2804 and a sub-opcode 2805 (if present) to determine the operation to be performed. The client unit uses the information in data field 2806 to execute the command. For some commands, an explicit command size 2808 is expected to specify the size of the command. In some examples, the command parser automatically determines the size of at least some commands based on the command opcode. In some examples, commands are aligned via multiples of double words. Other command formats can be used.

[0383] Fig.28B The flowchart in 28 illustrates an exemplary graphics processor command sequence 2810. In some examples, software or firmware of a data processing system featuring an example of a graphics processor uses a version of the command sequence shown to set up, execute, and terminate a set of graphics operations. The sample command sequence is shown and described for purposes of example only, as the examples are not limited to these particular commands or the command sequence. In addition, commands can be issued as batches of commands in a command sequence so that the graphics processor will process the command sequence at least partially concurrently.

[0384] In some examples, the graphics processor command sequence 2810 may begin with a pipeline dump clear command 2812 to cause any active graphics pipeline to complete the currently pending commands for that pipeline. In some examples, the 3D pipeline 2822 and the media pipeline 2824 do not operate concurrently. The pipeline dump clear is performed to cause the active graphics pipeline to complete any pending commands. In response to the pipeline dump clear, the command parser for the graphics processor will suspend command processing until the active drawing engine completes the pending operation and the associated read cache is invalidated. Optionally, any data marked as "dirty" in the rendering cache can be dumped into memory. In some examples, the pipeline dump clear command 2812 can be used for pipeline synchronization, or used before placing the graphics processor in a low power state.

[0385] In some examples, pipeline select command 2813 is used when a command sequence requires the graphics processor to explicitly switch between pipelines. In some examples, pipeline select command 2813 is only required once within an execution context before issuing pipeline commands unless the context is to issue commands for both pipelines. In some examples, pipeline flush command 2812 is required before a pipeline switch is made via pipeline select command 2813.

[0386] In some examples, pipeline control commands 2814 configure the graphics pipeline for operation and are used to program 3D pipeline 2822 and media pipeline 2824. In some examples, pipeline control commands 2814 configure the pipeline state of the active pipeline. In some examples, pipeline control commands 2814 are used for pipeline synchronization and clearing data from one or more cache memories within the active pipeline before processing a batch of commands.

[0387] In some examples, return buffer state commands 2816 are used to configure a set of return buffers for a corresponding pipeline to write data. Some pipeline operations require allocating, selecting, or configuring one or more return buffers into which the operation writes intermediate data during processing. In some examples, the graphics processor also uses one or more return buffers to store output data and perform cross-thread communication. In some examples, return buffer state 2816 includes selecting the size and number of return buffers to use for a set of pipeline operations.

[0388] The remaining commands in the command sequence differ based on the active pipeline for the operation. Based on pipeline determination 2820 , the command sequence is tailored to either the 3D pipeline 2822 starting with a 3D pipeline state 2830 , or the media pipeline 2824 starting with a media pipeline state 2840 .

[0389] The commands for configuring the 3D pipeline state 2830 include 3D state setting commands for vertex buffer state, vertex element state, constant color state, depth buffer state, and other state variables to be configured before processing the 3D primitive command. The values ​​of these commands are determined at least in part based on the specific 3D API in use. In some examples, the 3D pipeline state 2830 command can also selectively disable or bypass certain pipeline elements if those elements will not be used. In some examples, the 3D primitive 2832 command is used to submit the 3D primitive to be processed by the 3D pipeline. The command and associated parameters passed to the graphics processor via the 3D primitive 2832 command are forwarded to the vertex acquisition function in the graphics pipeline. The vertex acquisition function uses the 3D primitive 2832 command data to generate a vertex data structure. The vertex data structure is stored in one or more return buffers. In some examples, the 3D primitive 2832 command is used to perform vertex operations on the 3D primitive via the vertex shader. To process vertex shaders, 3D pipeline 2822 dispatches shader execution threads to graphics processor execution units.

[0390] In some examples, the 3D pipeline 2822 is triggered via an execute 2834 command or event. In some examples, a register write triggers the command execution. In some examples, the execution is triggered via a "go" or "kick" command in the command sequence. In some examples, the command execution is triggered using a pipeline synchronization command to flush the command sequence through the graphics pipeline. The 3D pipeline will perform geometry processing on the 3D primitives. Once the operation is completed, the resulting geometric object is rasterized and the pixel engine shades the resulting pixels. For those operations, additional commands for controlling pixel shading and pixel backend operations may also be included.

[0391] In some examples, when performing media operations, the graphics processor command sequence 2810 follows the media pipeline 2824 path. In general, the specific use and manner of programming for the media pipeline 2824 depends on the media or computing operations to be performed. During media decoding, specific media decoding operations can be offloaded to the media pipeline. In some examples, the media pipeline can also be bypassed, and the media decoding can be performed in whole or in part using resources provided by one or more general processing cores. In some examples, the media pipeline also includes elements for general purpose graphics processor unit (GPGPU) operations, where the graphics processor is used to perform SIMD vector operations using compute shader programs that are not explicitly related to the rendering of graphics primitives.

[0392] In some examples, the media pipeline 2824 is configured in a similar manner to the 3D pipeline 2822. A set of commands for configuring the media pipeline state 2840 is dispatched or placed into a command queue before the media object commands 2842. In some examples, the commands for the media pipeline state 2840 include data for configuring the media pipeline elements that will be used to process the media objects. This includes data for configuring the video decoding and video encoding logic within the media pipeline, such as encoding or decoding formats. In some examples, the commands for the media pipeline state 2840 also support the use of one or more pointers to an "indirect" state element that contains bulk state settings.

[0393] In some examples, media object command 2842 provides a pointer to a media object for processing by the media pipeline. The media object includes a memory buffer containing video data to be processed. In some examples, all media pipeline states must be valid before issuing media object command 2842. Once the pipeline state is configured and media object command 2842 is queued, media pipeline 2824 is triggered via execution command 2844 or an equivalent execution event (e.g., register write). The output from media pipeline 2824 can then be post-processed by the operations provided by 3D pipeline 2822 or media pipeline 2824. In some examples, GPGPU operations are configured and executed in a manner similar to media operations.

[0394] Program code can be applied to input information to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system with a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microprocessor or any combination thereof.

[0395] The program code can be implemented in a high-level procedural or object-oriented programming language to communicate with the processing system. If necessary, the program code can also be implemented in assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled or interpreted language.

[0396] Examples of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementation methods. Examples may be implemented as a computer program or program code executed on a programmable system comprising at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0397] Such machine-readable storage media may include, but are not limited to, a non-transitory tangible arrangement of an article manufactured or formed by a machine or apparatus, including storage media such as a hard disk; any other type of disk, including a floppy disk, an optical disk, a compact disk-read only memory (CD-ROM), a compact disk-rewritable (CD-RW), and a magneto-optical disk; a semiconductor device, such as a read-only memory (ROM), a random access memory (RAM) such as a dynamic random access memory (DRAM) and a static random access memory (SRAM), an erasable programmable read-only memory (EPROM), a flash memory, an electrically erasable programmable read-only memory (EEPROM); a phase change memory (PCM); a magnetic card or an optical card; or any other type of medium suitable for storing electronic instructions.

[0398] Therefore, examples also include non-transitory tangible machine-readable media containing instructions or containing design data, such as hardware description language (HDL), which defines the structures, circuits, devices, processors and / or system features described herein. Such examples are also referred to as program products.

[0399] Simulation (including binary translation, code deformation, etc. (morphing)).

[0400] In some cases, the instruction converter can be used to convert instructions from a source instruction set architecture to a target instruction set architecture. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions into one or more other instructions to be processed by the core. The instruction converter can be implemented in software, hardware, firmware, or a combination thereof. The instruction converter can be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0401] Fig.291 is a block diagram illustrating the use of a software instruction converter to convert binary instructions in a source ISA into binary instructions in a target ISA according to an example. In the illustrated example, the instruction converter is a software instruction converter, although alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig.29 2904 can be used to compile a program in a high-level language 2902 to generate a first ISA binary code 2906 that can be natively executed by a processor 2916 having at least one first ISA core. The processor 2916 having at least one first ISA core represents a processor capable of executing programs with at least one first ISA core. Any processor that has substantially the same functionality as a processor having at least one first ISA core in order to achieve substantially the same results as a processor having at least one first ISA core by compatibly executing or otherwise processing: (1) a substantial portion of the first ISA, or (2) an object code version of an application or other software targeted to run on an Intel processor having at least one first ISA core. First ISA compiler 2904 represents a compiler operable to generate first ISA binary code 2906 (e.g., object code) that can be executed on a processor having at least one first ISA core 2916 with or without additional linkage processing. Similarly, Fig.29 It is shown that an alternative ISA compiler 2908 can be used to compile a program in a high-level language 2902 to generate an alternative ISA binary code 2910, which can be natively executed by a processor 2914 that does not have a first ISA core. The instruction converter 2912 is used to convert the first ISA binary code 2906 into code that can be natively executed by a processor 2914 that does not have a first ISA core. The converted code is not necessarily the same as the alternative ISA binary code 2910; however, the converted code will complete the general operation and consist of instructions from the alternative ISA. Therefore, the instruction converter 2912 represents software, firmware, hardware, or a combination thereof, which allows a processor or other electronic device that does not have a first ISA processor or core to execute the first ISA binary code 2906 through simulation, emulation, or any other process.

[0402] IP core implementation

[0403] One or more aspects of at least some examples may be implemented by representative code stored on a machine-readable medium that represents and / or defines logic within an integrated circuit (such as a processor). For example, a machine-readable medium may include instructions representing various logics within a processor. When read by a machine, the instructions may cause the machine to manufacture logic for performing the techniques described herein. This representation (referred to as an "IP core") is a reusable unit of logic for an integrated circuit that can be stored on a tangible machine-readable medium as a hardware model describing the structure of the integrated circuit. The hardware model may be supplied to various customers or manufacturing facilities that load the hardware model on a manufacturing machine that manufactures the integrated circuit. An integrated circuit may be manufactured so that the circuit performs the operations described in association with any of the examples described herein.

[0404] Fig.30 3000 is a block diagram illustrating an IP core development system 3000 that can be used to manufacture an integrated circuit to perform operations according to some examples. The IP core development system 3000 can be used to generate a modular, reusable design that can be incorporated into a larger design or used to construct an entire integrated circuit (e.g., a SOC integrated circuit). The design facility 3030 can generate a software simulation 3010 of the IP core design in a high-level programming language (e.g., C / C++). The software simulation 3010 can be used to design, test and verify the behavior of the IP core using a simulation model 3012. The simulation model 3012 can include functional simulation, behavioral simulation and / or timing simulation. A register transfer level (RTL) design 3015 can then be created or synthesized from the simulation model 3012. The RTL design 3015 is an abstraction of the behavior of an integrated circuit (including associated logic executed using the modeled digital signals) that models the flow of digital signals between hardware registers. In addition to the RTL design 3015, a lower level design at the logic level or transistor level can also be created, designed or synthesized. Thus, the specific details of the initial design and simulation can vary.

[0405] The RTL design 3015 or equivalent may be further synthesized by the design facility into a hardware model 3020, which may be in a hardware description language (HDL) or some other representation of physical design data. The HDL may be further simulated or tested to verify the IP core design. The IP core design may be stored using a non-volatile memory 3040 (e.g., a hard disk, flash memory, or any non-volatile storage medium) for delivery to a third-party manufacturing facility 3065. Alternatively, the IP core design may be transmitted via a wired connection 3050 or a wireless connection 3060 (e.g., via the Internet). The manufacturing facility 3065 may then manufacture an integrated circuit based at least in part on the IP core design. The manufactured integrated circuit may be configured to perform operations according to at least one example described herein.

[0406] References to "some examples," "examples," etc. indicate that the examples described may include a particular feature, structure, or characteristic, but each example may not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same example. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an example, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other examples, whether or not explicitly described.

[0407] Furthermore, in the various examples above, disjunctive language, such as phrases "at least one of A, B, or C" or "A, B and / or C," is intended to be understood to mean A, B, or C, or any combination thereof (i.e., A and B, A and C, B and C, and A, B, and C), unless specifically noted otherwise.

[0408] Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the claims.

Claims

1. A device comprising: An execution circuit for executing one or more instructions; Performance monitoring counters; control registers, including threshold fields; as well as A performance monitor control circuit is configured to increment a performance monitoring counter in response to a performance monitoring event of the one or more instructions being equal to but not greater than the threshold field. 2 . The apparatus of claim 1 , wherein the threshold field is a counter mask field of a control register.

3. An apparatus according to claim 1, wherein the control register includes a mode field, and the performance monitor control circuit is used to increment the performance monitoring counter in response to the mode field being set to the first mode and in response to a performance monitoring event being equal to but not greater than the threshold field. 4 . The apparatus of claim 3 , wherein the mode field set to the first mode comprises an equal field of the control register set to 1 and an invert field of the control register set to 0. 5 .

5. The apparatus of claim 3, wherein in response to a mode field of the control register being set to a second mode, the performance monitor control circuit is configured to increment a performance monitoring counter in response to a performance monitoring event being greater than zero and less than the threshold field. 6 . The apparatus of claim 5 , wherein the mode field set to the second mode includes an equal field of the control register set to 1 and an inversion field of the control register set to 1. 7 .

7. The apparatus of any one of claims 1 to 6, wherein the control register comprises a first unit mask field in a first half of the control register and a second unit mask field in a second half of the control register.

8. A method comprising: executing one or more instructions by execution circuitry of the processor; Set the threshold field of the processor's control register; as well as A performance monitoring counter is incremented by performance monitor control circuitry of the processor in response to a performance monitoring event of the one or more instructions being equal to but not greater than the threshold field.

9. The method of claim 8, wherein the threshold field is a counter mask field of a control register.

10. The method of claim 8, further comprising setting a mode field of a control register to a first mode, wherein the incrementing by the performance monitor control circuit in response to a performance monitoring event being equal to but not greater than the threshold field is in response to the mode field being set to the first mode. 11 . The method of claim 10 , wherein setting the mode field to the first mode comprises setting an equal field of a control register to 1 and setting an invert field of the control register to 0.

12. The method according to claim 10, further comprising: Setting the mode field of the control register to the second mode; as well as In response to the mode field being set to the second mode, the performance monitoring counter is incremented by the performance monitor control circuit in response to the performance monitoring event being greater than zero and less than the threshold field.

13. The method of claim 12, setting the mode field to the second mode comprises setting an equal field of a control register to 1 and setting an invert field of the control register to 1.

14. The method of any one of claims 8 to 13, wherein the control register comprises a first unit mask field in a first half of the control register and a second unit mask field in a second half of the control register.

15. An apparatus comprising: Memory; execution circuitry for executing one or more instructions on data accessed in the memory; Performance monitoring counters; control registers, including threshold fields; as well as A performance monitor control circuit is configured to increment a performance monitoring counter in response to a performance monitoring event of the one or more instructions being equal to but not greater than the threshold field.

16. The apparatus of claim 15, wherein the threshold field is a counter mask field of a control register.

17. The apparatus of claim 15, wherein the control register includes a mode field, and the performance monitor control circuit is operative to increment the performance monitoring counter in response to the mode field being set to the first mode and in response to a performance monitoring event being equal to but not greater than the threshold field. 18 . The apparatus of claim 17 , wherein the mode field set to the first mode comprises an equal field of the control register set to 1 and an invert field of the control register set to 0.

19. The apparatus of claim 17, wherein in response to a mode field of the control register being set to a second mode, the performance monitor control circuit is operative to increment a performance monitoring counter in response to a performance monitoring event being greater than zero and less than the threshold field. 20 . The apparatus of claim 19 , wherein the mode field set to the second mode includes an equal field of the control register set to 1 and an invert field of the control register set to 1.

Images