Adjusting display refresh rate based on user activity

CN113272889BActive Publication Date: 2026-10-23INTEL CORP
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202080008173.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-02-07
Filing Date
2020-02-05
Publication Date
2026-10-23
Estimated Expiration
2040-02-05

Smart Images

  • Figure CN113272889B_ABST
    Figure CN113272889B_ABST
Patent Text Reader

Abstract

In one embodiment, a computing device includes a processor and a machine-readable storage medium storing instructions. The instructions are executable by the hardware processor to: monitor a user input device during presentation of a video frame on a display device at a refresh rate at a first level; determine whether a time period since a last user interaction with the user input device exceeds a time threshold; and in response to determining that the time period since the last user interaction exceeds the time threshold, reduce the refresh rate of the display device to a second level. Other embodiments are described and claimed.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments relate to display devices, and more specifically to controlling the refresh rate in a display device. Background Technology

[0002] Advances in digital technology have made it possible to display video images on screens associated with electronic devices. For example, a smartphone can display video images on its included screen. In another example, a desktop computer can display video images on an attached display device (e.g., a monitor). In some examples, the computing device may include a display engine to process the video images displayed by the computing device. Attached Figure Description

[0003] Figure 1 This is a block diagram of a system according to an embodiment of the present invention.

[0004] Figure 2 This is a block diagram of a processor according to an embodiment of the present invention.

[0005] Figure 3 This is a block diagram of a multi-domain processor according to another embodiment of the present invention.

[0006] Figure 4 It is an embodiment that includes a processor with multiple cores.

[0007] Figure 5 This is a block diagram of the microarchitecture of a processor core according to an embodiment of the present invention.

[0008] Figure 6 This is a block diagram of the microarchitecture of a processor core according to another embodiment.

[0009] Figure 7 This is a block diagram of the microarchitecture of a processor core according to yet another embodiment.

[0010] Figure 8 This is a block diagram of the microarchitecture of a processor core according to another embodiment.

[0011] Figure 9 This is a block diagram of a processor according to another embodiment of the present invention.

[0012] Figure 10 This is a block diagram of a representative SoC according to an embodiment of the present invention.

[0013] Figure 11 This is a block diagram of another example SoC according to an embodiment of the present invention.

[0014] Figure 12 This is a block diagram of an example system that can be used with the embodiments.

[0015] Figure 13 This is a block diagram of another example system that can be used with the embodiments.

[0016] Figure 14 It is a block diagram of a representative computer system.

[0017] Figures 15A-15B This is a block diagram of a system according to an embodiment of the present invention.

[0018] Figure 16 This is a block diagram illustrating an IP core development system according to an embodiment, which is used to manufacture integrated circuits to perform operations.

[0019] Figures 17A-17B This is a block diagram illustrating a general vector-friendly instruction format and its instruction template according to an embodiment of the present invention.

[0020] Figures 18A-18D This is a block diagram illustrating an exemplary vector-friendly instruction format according to an embodiment of the present invention.

[0021] Figure 19 This is a block diagram of a register architecture according to an embodiment of the present invention.

[0022] Figure 20A This is a block diagram illustrating both an exemplary ordered pipeline and an exemplary register renaming, unordered issue / execution pipeline according to an embodiment of the present invention.

[0023] Figure 20B The diagram illustrates an exemplary embodiment of an ordered architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core, according to embodiments of the present invention.

[0024] Figures 21A-21B The diagram illustrates a more specific exemplary ordered core architecture, which will be one of several logical blocks in the chip (including other cores of the same type and / or different types).

[0025] Figure 22 This is a block diagram of a processor according to an embodiment of the present invention, which may have more than one core, may have an integrated memory controller, and may have integrated graphics.

[0026] Figures 23-24 It is a block diagram of an exemplary computer architecture.

[0027] Figure 25 This is a block diagram comparing an embodiment of the present invention with the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set.

[0028] Figure 26 This is a diagram of an example system according to one or more embodiments.

[0029] Figure 27 This is a flowchart of an example method according to one or more embodiments.

[0030] Figure 28 This is a diagram of example events based on one or more embodiments.

[0031] Figure 29 This is a flowchart of an example method according to one or more embodiments.

[0032] Figure 30 This is a flowchart of an example method according to one or more embodiments.

[0033] Figure 31 This is a flowchart of an example method according to one or more embodiments.

[0034] Figure 32 This is a diagram of an example computing device according to one or more embodiments.

[0035] Figure 33 This is a diagram of an example machine-readable storage medium according to storage instructions based on one or more embodiments. Detailed Implementation

[0036] Computers or other electronic devices may use display devices to present video images. A display device can be a monitor capable of displaying video content at multiple refresh rates. The refresh rate is the frequency at which individual image frames can be displayed. For example, a display device may use a 48Hz refresh rate, thus displaying 48 frames per second. A relatively higher refresh rate may provide a better viewing experience than a relatively lower refresh rate. Therefore, some display devices may default to using the maximum refresh rate supported in a given situation. However, using a higher refresh rate may result in higher overall power consumption compared to using a lower refresh rate. Therefore, using a higher refresh rate may be associated with reduced battery life, increased thermal load, and / or increased power costs.

[0037] According to one or more embodiments, the refresh rate of a display device can be dynamically adjusted when conditions are detected indicating that a lower refresh rate will have little or no impact on the viewing experience. In some examples, the refresh rate may be reduced if the time since the last user input exceeds a time threshold, if the updated frame portion is below a size threshold, if the frame update frequency is lower than the refresh rate, or if any combination of these occurs. Conversely, the refresh rate may be increased if such conditions(one or more) are no longer detected. In this way, the refresh rate can be dynamically adjusted while minimizing the impact on the viewing experience. Therefore, some embodiments can provide a reduction in the power consumption of the computing device. Various details of some embodiments are referenced below. Figures 26-33 Further description is provided. Additionally, exemplary systems and architectures are referenced below. Figures 1-25 To be described.

[0038] Exemplary systems and architectures

[0039] While the following embodiments have been described with reference to specific implementations, the embodiments are not limited in this respect. In particular, it is contemplated that similar techniques and teachings of the embodiments described herein can be applied to other types of circuits, semiconductor devices, processors, systems, etc. For example, the disclosed embodiments can be implemented in any type of computer system, including server computers (e.g., tower, rack, blade, microservers, etc.), communication systems, storage systems, desktop computers of any configuration, laptop computers, notebooks, and tablet computers (including 2:1 tablets, phablets, etc.).

[0040] Furthermore, the disclosed embodiments can also be used in other devices, such as handheld devices, systems-on-chip (SoCs), and embedded applications. Some examples of handheld devices include cellular phones such as smartphones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and handheld PCs. Embedded applications typically include microcontrollers, digital signal processors (DSPs), network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, wearable devices, or any other system capable of performing the functions and operations taught below. Additionally, embodiments can be implemented in mobile terminals with standard voice capabilities, such as mobile phones, smartphones, and phablets, and / or in non-mobile terminals without standard wireless voice communication capabilities, such as many wearable devices, tablets, laptops, desktop computers, microservers, servers, and so on.

[0041] Now for reference Figure 1 A block diagram of a portion of a system according to an embodiment of the present invention is shown. Figure 1 As shown, system 100 may include various components, including processor 110, which is a multi-core processor as illustrated. Processor 110 may be coupled to power supply 150 via external voltage regulator 160, which may perform a first voltage conversion to provide a main regulated voltage Vreg to processor 110.

[0042] As can be seen, the processor 110 can be a single-die processor comprising multiple cores 120a-120n. Furthermore, each core can be associated with an integrated voltage regulator (IVR) 125a-125n, which receives a master regulated voltage and generates an operating voltage to be supplied to one or more agents of the processor associated with that IVR. Therefore, an IVR implementation can be provided to allow fine-grained control of voltage, thereby allowing fine-grained control of the power and performance of each individual core. In this way, each core can operate at independent voltage and frequency, enabling great flexibility and providing a wide range of opportunities to balance power consumption and performance. In some embodiments, the use of multiple IVRs allows components to be grouped into separate power planes, such that power is regulated by the IVR and supplied only to those components in the group. During power management, a given power plane of one IVR can be powered down or de-energized when the processor is placed in a low-power state, while another power plane of another IVR remains active or fully powered. Similarly, core 120 may include independent clock generation circuitry (e.g., one or more phase lock loops (PLLs)) or be associated with independent clock generation circuitry to independently control the operating frequency of each core 120.

[0043] Still referencing Figure 1 Additional components may reside within the processor, including an input / output interface (IF) 132, another interface 134, and an integrated memory controller (IMC) 136. It can be seen that each of these components can be controlled by another integrated voltage regulator 125. x To provide power. In one embodiment, interface 132 can be for... The Quick Path Interconnect (QPI) interconnect is enabled, providing a point-to-point (PtP) link in a cache coherence protocol comprising multiple layers, including the physical layer, link layer, and protocol layer. Furthermore, interface 134 can be connected via Quick Peripheral Component Interconnect Express (PCIe). TM They communicate using protocols.

[0044] A power control unit (PCU) 138 is also shown, which may include circuitry comprising hardware, software, and / or firmware to perform power management operations with respect to processor 110. It can be seen that PCU 138 provides control information to an external voltage regulator 160 via digital interface 162 to cause the voltage regulator to generate an appropriate regulated voltage. PCU 138 also provides control information to an IVR 125 via another digital interface 163 to control the generated operating voltage (or to disable the corresponding IVR in a low-power mode). In various embodiments, PCU 138 may include multiple power management logic units to perform hardware-based power management. This power management may be entirely processor-controlled (e.g., controlled by various processor hardware and may be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (e.g., a platform or power management source or system software).

[0045] exist Figure 1 In this embodiment, PCU 138 is shown as a separate piece of processor logic. In other cases, PCU 138 may execute on one or more of the cores given in core 120. In some cases, PCU 138 may be implemented as a microcontroller (dedicated or general-purpose) or other control logic configured to execute its own dedicated power management code (sometimes called P-code). In yet another embodiment, the power management operations to be performed by PCU 138 may be implemented outside the processor, for example, by a separate power management integrated circuit (PMIC) or another component outside the processor. In yet another embodiment, the power management operations to be performed by PCU 138 may be implemented within the BIOS or other system software.

[0046] Implementations are particularly well-suited for multi-core processors, where each of the multiple cores can operate at independent voltage and frequency points. For the purposes of this document, the term "domain" is used to mean a collection of hardware and / or logic operating at the same voltage and frequency point. Furthermore, multi-core processors may also include other non-core processing engines, such as fixed-function units, graphics engines, and so on. Such processors may include independent domains in addition to the cores, for example, one or more domains associated with a graphics engine (referred to herein as graphics domains), and one or more domains associated with non-core circuitry (referred to herein as system agents). While many implementations of multi-domain processors can be formed on a single semiconductor die, other implementations can be implemented using a multi-chip package in which different domains can exist on different semiconductor dies within a single package.

[0047] Although not shown for ease of illustration, it is understood that additional components may exist within processor 110, such as non-core logic, and other components such as internal memory, such as one or more levels of the cache memory hierarchy, etc. Furthermore, although in Figure 1 The implementation is shown using an integrated voltage regulator, but the embodiment is not limited to this. For example, additional regulated voltages may be provided to the on-chip resources from an external voltage regulator 160 or one or more additional external sources for regulating the voltage.

[0048] Note that the power management techniques described in this article can be independent of and complementary to operating system-based power management (OSPM) mechanisms. According to an example OSPM technique, the processor can operate in various performance states or levels—so-called P states—ranging from P0 to PN. Generally, the P1 performance state corresponds to the highest guaranteed performance state that the OS can request. In addition to this P1 state, the OS can request higher performance states, namely the P0 state. This P0 state can therefore be an opportunistic mode, overclocking mode, or turbo mode state, in which the processor hardware can configure the processor or at least some of its components to operate at frequencies higher than the guaranteed frequency when power and / or thermal budgets are available. In many implementations, the processor may include multiple so-called bin frequencies exceeding the maximum guaranteed P1 frequency and extending to the maximum peak frequency of a particular processor; these bin frequencies are melted down or otherwise written into the processor during manufacturing. Furthermore, according to an OSPM mechanism, the processor can operate in various power states or levels. Regarding power states, the OSPM mechanism can specify different power consumption states, generally referred to as C states, C0, C1 to Cn. When a core is active, it operates in the C0 state, and when a core is idle, it can be placed in a core low-power state, also known as a core non-zero C state (e.g., C1-C6 states), where each C state is at a lower power consumption level (making C6 a deeper low-power state than C1, and so on).

[0049] It is important to understand that many different types of power management techniques can be used individually or in combination in different implementations. As a representative example, a power controller can manage the power of a processor using some form of dynamic voltage frequency scaling (DVFS), in which the operating voltage and / or operating frequency of one or more cores or other processor logic can be dynamically controlled to reduce power consumption in certain situations. In one example, DVFS can utilize an enhanced Intel SpeedStep processor available from Intel Corporation in Santa Clara, California. TM The technology is implemented to deliver optimal performance with the lowest possible power consumption. In another example, DVFS can leverage Intel Turbo Boost. TM The technology is implemented to enable one or more cores or other computing engines to operate at a frequency higher than the guaranteed operating frequency based on conditions (e.g., workload and availability).

[0050] Another power management technique that can be used in some examples is the dynamic switching of workloads between different computing engines. For example, the processor may include asymmetric cores or other processing engines operating at different power consumption levels, so that in power-constrained situations, one or more workloads can be dynamically switched to execute on lower-power cores or other computing engines. Another exemplary power management technique is hardware duty cycling (HDC), which allows cores and / or other computing engines to be periodically enabled and disabled according to duty cycles, so that one or more cores can be set to inactive during the inactive period of a duty cycle and set to active during the active period of a duty cycle.

[0051] Power management techniques can also be used when constraints exist in the operating environment. For example, when power constraints and / or thermal constraints are encountered, power can be reduced by decreasing the operating frequency and / or voltage. Other power management techniques include restricting the instruction execution rate or limiting instruction scheduling. Furthermore, the instructions of a given instruction set architecture may include explicit or implicit guidance regarding power management operations. While described using these specific examples, it is to be understood that many other power management techniques may be used in particular embodiments.

[0052] Implementation examples can be used in processors targeting various markets, including server processors, desktop processors, mobile processors, and so on. Reference now. Figure 2 A block diagram of a processor according to an embodiment of the present invention is shown. Figure 2 As shown, the processor 200 may include multiple cores 210 a -210 n A multi-core processor. In one embodiment, each such core may be an independent power domain and may be configured to enter and exit active and / or maximum performance states based on workload. One or more cores 210 may be heterogeneous with other cores, for example, having different microarchitectures, instruction set architectures, pipeline depths, power and performance capabilities. Various cores may be coupled to a system agent 220 comprising various components via interconnect 215. It can be seen that the system agent 220 may include a shared cache 230, which may be a last-level cache. In addition, the system agent may include an integrated memory controller 240 to communicate with the system memory, for example, via a memory bus. Figure 2 (Not shown in the text) Communication. System agent 220 also includes various interfaces 250 and a power control unit 255, which may include logic to perform the power management techniques described herein.

[0053] Furthermore, various external components can be connected via interfaces 250a-250n, such as peripheral devices and high-capacity storage devices. Although in Figure 2 The embodiments shown utilize this particular implementation, but the scope of the invention is not limited in this respect.

[0054] Now for reference Figure 3 A block diagram of a multi-domain processor according to another embodiment of the present invention is shown. Figure 3 As shown in the embodiments, the processor 300 includes multiple domains. Specifically, the core domain 310 may include multiple cores 3100-3100. n The graphics domain 320 may include one or more graphics engines, and the system agent domain 350 may further exist. In some embodiments, the system agent domain 350 may execute at a frequency independent of the core domains and may remain powered on at all times in response to power control events and power management, such that domains 310 and 320 may be controlled to dynamically enter and exit high-power and low-power states. Each of domains 310 and 320 may operate at different voltages and / or power levels. Note that although only three domains are shown, it is to be understood that the scope of the invention is not limited in this respect, and additional domains may exist in other embodiments. For example, multiple core domains may exist, each core domain including at least one core.

[0055] Generally, each of the cores 310a-310n may include a low-level cache in addition to various execution units and additional processing elements. Furthermore, the various cores may be coupled to each other and to a shared cache memory formed by multiple units of the last-level cache (LLC) 340a-340n. In various embodiments, LLC 340 may be shared between the cores and the graphics engine, as well as various media processing circuits. It can be seen that the ring interconnect 330 thus couples the cores together and provides interconnection between the core, the graphics domain 320, and the system proxy domain 350. In one embodiment, interconnect 330 may be part of the core domain. However, in other embodiments, the ring interconnect may be its own domain.

[0056] It can also be seen that the system agent domain 350 may include a display controller 352, which can provide control over an associated display and an interface to the associated display. It can also be seen that the system agent domain 350 may include a power control unit 355, which may include logic to perform the power management techniques described herein.

[0057] from Figure 3It can also be seen that the processor 300 may include an integrated memory controller (IMC) 370, which provides an interface to system memory such as dynamic random access memory (DRAM). Multiple interfaces 380a-380n may be present to enable interconnection between the processor and other circuitry. For example, in one embodiment, at least one direct media interface (DMI) interface and one or more PCIe interfaces may be provided. TM Interface. Additionally, one or more QPI interfaces may be provided to facilitate communication between other agents, such as additional processors or other circuitry. Although in Figure 3 The embodiments are shown at this high level, but it is to be understood that the scope of the invention is not limited in this respect.

[0058] refer to Figure 4 The illustration depicts an embodiment of a processor comprising multiple cores. Processor 400 includes any processor or processing device, such as a microprocessor, embedded processor, digital signal processor (DSP), network processor, handheld processor, application processor, coprocessor, system-on-a-chip (SoC), or other device for executing code. In one embodiment, processor 400 includes at least two cores—cores 401 and 402—which may include asymmetric or symmetric cores (as illustrated in the embodiment). However, processor 400 may include any number of processing elements, which may be symmetric or asymmetric.

[0059] In one embodiment, a processing element refers to hardware or logic used to support software threads. Examples of hardware processing elements include: thread units, thread slots, threads, processing units, contexts, context units, logic processors, hardware threads, cores, and / or any other element capable of maintaining state (e.g., execution state or architectural state) for the processor. In other words, in one embodiment, a processing element refers to any hardware capable of being independently associated with code such as software threads, operating systems, applications, or other code. A physical processor typically refers to an integrated circuit that may include any number of other processing elements (e.g., cores or hardware threads).

[0060] A kernel typically refers to logic located on an integrated circuit that maintains an independent architectural state, each of which is associated with at least some dedicated execution resources. In contrast, a hardware thread generally refers to any logic located on an integrated circuit that maintains an independent architectural state, where these independently maintained architectural states share access to execution resources. It can be seen that the boundary between the nomenclature of hardware threads and kernels overlaps when some resources are shared and others are dedicated to architectural states. However, often, kernels and hardware threads are treated as separate logical processors by the operating system, which can schedule operations on each logical processor independently.

[0061] like Figure 4 As shown, the physical processor 400 includes two cores, namely cores 401 and 402. Here, cores 401 and 402 are considered symmetric cores, i.e., cores with the same configuration, functional units, and / or logic. In another embodiment, core 401 includes an out-of-order processor core, while core 402 includes an ordered processor core. However, cores 401 and 402 can be selected individually from any type of core, such as a native core, a software-managed core, a core adapted to execute a native instruction set architecture (ISA), a core adapted to execute a transformed ISA, a co-designed core, or other known cores. Further discussion follows, with the functional units illustrated in core 401 described in more detail below, as the units in core 402 operate in a similar manner.

[0062] As depicted in the figure, core 401 includes two architecture status registers 401a and 401b, which can be associated with two hardware threads (also referred to as hardware thread slots). Therefore, in one embodiment, a software entity (e.g., an operating system) may view processor 400 as four separate processors, i.e., four logical processors or processing elements capable of executing four software threads simultaneously. As mentioned above, the first thread is associated with architecture status register 401a, the second thread with architecture status register 401b, the third thread with architecture status register 402a, and the fourth thread with architecture status register 402b. Here, the architecture status registers (401a, 401b, 402a, and 402b) can be associated with processing elements, thread slots, or thread units, as described above. As shown, architecture status register 401a is copied into architecture status register 401b, thus enabling the storage of individual architecture state / context for logical processors 401a and 401b. Within core 401, other smaller resources, such as the instruction pointer and renaming logic in allocator and renamer block 430, can also be copied for threads 401a and 401b. Some resources can be shared through partitioning, such as the reorder buffer, branch target buffer, and instruction translation back buffer (BTB and I-TLB) 420, load / store buffer, and queues in reordering / retreating unit 435. Other resources (e.g., general-purpose internal registers, one or more page table base registers, low-level data cache and data TLB 450, one or more execution units 440, and portions of reordering / retreating unit 435) may be fully shared.

[0063] Processor 400 often includes other resources that can be fully shared, shared through partitions, or dedicated to or specific to the processing element. Figure 4 The illustration depicts a purely exemplary embodiment of a processor with illustrative logic units / resources for the processor. Note that the processor may include or omit any of these functional units, as well as any other known functional units, logic, or firmware not depicted. As shown, core 401 includes a simplified, representative out-of-order (OOO) processor core. However, ordered processors may be utilized in different embodiments.

[0064] Core 401 also includes a decoding module 425 coupled to the fetch unit to decode the fetched elements. In one embodiment, the fetch logic includes individual sequencers associated with thread slots 401a and 401b, respectively. Typically, core 401 is associated with a first ISA that defines / specifies instructions executable on processor 400. Often, machine code instructions that are part of the first ISA include a portion of the instruction (called an opcode) that references / specifies the instruction or operation to be performed. Decoding module 425 includes circuitry that recognizes the instructions from their opcodes and passes the decoded instructions through a pipeline for processing as defined by the first ISA. For example, in one embodiment, decoder module 425 includes logic designed or adapted to recognize specific instructions, such as transactional instructions. As a result of the recognition performed by decoder module 425, the architecture or core 401 takes specific predefined actions to perform the task associated with the appropriate instruction. It is important to note that any task, block, operation, and method described herein may be executed in response to a single or multiple instructions; some of these instructions may be new or old.

[0065] In one example, allocator and renamer block 430 includes an allocator to reserve resources, such as reserving a register file to store instruction processing results. However, threads 401a and 401b may be able to perform out-of-order execution, where allocator and renamer block 430 also reserves other resources, such as reserving a reorder buffer to track instruction results. Renamer block 430 may also include a register renamer to rename program / instruction reference registers to other registers within processor 400. Reordering / retirement unit 435 includes components (e.g., the reorder buffer, load buffer, and store buffer mentioned above) to support out-of-order execution of instructions that are executed out of order and subsequent ordered retirement.

[0066] One or more scheduler and execution unit blocks 440 in one embodiment include a scheduler unit to schedule instructions / operations on an execution unit. For example, floating-point instructions are scheduled at a port of the execution unit, where the execution unit has available floating-point execution units. A register file associated with the execution unit is also included to store information about instruction processing results. Exemplary execution units include floating-point execution units, integer execution units, jump execution units, load execution units, store execution units, and other known execution units.

[0067] Lower-level data caches and data translation lookaside buffers (D-TLBs) 450 are coupled to one or more execution units 440. The data cache is also used to store recently used / operated elements (e.g., data manipulation objects) that may be kept in a memory-coherent state. The D-TLB is used to store recent virtual / linear-to-physical address translations. As a concrete example, the processor may include a page table structure to break down physical memory into multiple virtual pages.

[0068] Here, cores 401 and 402 share access to a higher-level or more distant cache 410, which is used to cache recently acquired elements. Note that "higher-level or more distant" refers to a cache level that increases or becomes more distant from execution unit(s). In one embodiment, the higher-level cache 410 is the last-level data cache—the last cache in the memory hierarchy on processor 400—such as a second or third-level data cache. However, the higher-level cache 410 is not limited to this, as it may be associated with or include an instruction cache. Instead, a trace cache (a type of instruction cache) may be coupled after decoder module 425 to store recently decoded traces.

[0069] In the depicted configuration, processor 400 also includes a bus interface 405 and a power control unit 460, which can perform power management according to embodiments of the invention. In this scenario, bus interface 405 is used to communicate with devices external to processor 400 (e.g., system memory and other components).

[0070] The memory controller 470 can interface with other devices such as one or more memories. In one example, the bus interface 405 includes a ring interconnect with a memory controller for interfacing with the memory and a graphics controller for interfacing with the graphics processor. In a SoC environment, even more devices (e.g., network interfaces, coprocessors, memory, graphics processors, and any other known computer devices / interfaces) can be integrated onto a single die or integrated circuit to provide small form factor with high functionality and low power consumption.

[0071] Now for reference Figure 5 A block diagram of the microarchitecture of a processor core according to an embodiment of the present invention is shown. Figure 5 As shown, processor core 500 can be a multi-stage pipelined out-of-order processor. Core 500 can operate at various voltages based on a received operating voltage, which can be received from an integrated voltage regulator or an external voltage regulator.

[0072] from Figure 5As can be seen, core 500 includes a front-end unit 510, which can be used to fetch instructions to be executed and prepare them for later use in the processor pipeline. For example, front-end unit 510 may include fetch unit 501, instruction cache 503, and instruction decoder 505. In some implementations, front-end unit 510 may also include trace cache, along with microcode storage and microoperation storage. Fetch unit 501 can fetch macro instructions (e.g., from memory or instruction cache 503) and feed them to instruction decoder 505 to decode them into primitives (i.e., microoperations for processor execution).

[0073] Coupled between the front-end unit 510 and the execution unit 520 is an out-of-order (OOO) engine 515, which can be used to receive microinstructions and prepare them for execution. More specifically, the OOO engine 515 may include various buffers for reordering the microinstruction stream and allocating various resources required for execution, and for providing renaming of logical registers to storage locations within various register files (such as register file 530 and extended register file 535). Register file 530 may include separate register files for integer and floating-point operations. For configuration, control, and additional operations, a set of machine-specific registers (MSRs) 538 may also exist and be logically accessible within (and outside) the core 500.

[0074] Various resources may reside in execution unit 520, including, for example, various integer, floating-point, and single instruction multiple data (SIMD) logic units, as well as other specialized hardware. For example, such execution unit may include one or more arithmetic logic units (ALUs) 522 and one or more vector execution units 524, as well as other such execution units.

[0075] The results from the execution unit can be provided to the decommissioning logic, namely, the reorder buffer (ROB) 540. More specifically, the ROB 540 may include various arrays and logic to receive information associated with the executed instruction. This information is then examined by the ROB 540 to determine whether the instruction can be effectively decommissioned and the resulting data can be submitted to the processor's architectural state, or to determine whether one or more exceptions have occurred that prevent the proper decommissioning of the instruction. Of course, the ROB 540 can handle other operations associated with decommissioning.

[0076] like Figure 5As shown, ROB 540 is coupled to cache 550, which in one embodiment may be a low-level cache (e.g., L1 cache), although the scope of the invention is not limited in this respect. Additionally, execution unit 520 may be directly coupled to cache 550. From cache 550, data communication can occur with higher-level caches, system memory, etc. Although in Figure 5 The embodiments are shown at this high level, but it is to be understood that the scope of the invention is not limited in this respect. For example, although Figure 5 The implementation method is about such as The invention is not limited in this respect to out-of-order machines such as the x86 instruction set architecture (ISA). That is, other embodiments can be implemented in ordered processors, reduced instruction set computing (RISC) processors such as ARM-based processors, or processors of another type of ISA that can emulate the instructions and operations of different ISAs via an emulation engine and associated logic circuitry.

[0077] Now for reference Figure 6 A block diagram of the microarchitecture of a processor core according to another embodiment is shown. Figure 6 In this embodiment, core 600 can be a low-power core of a different microarchitecture, for example, based on Atom TM The processor has a relatively limited pipeline depth designed to reduce power consumption. It can be seen that core 600 includes an instruction cache 610 coupled to provide instructions to instruction decoder 615. Branch predictor 605 can be coupled to instruction cache 610. Note that instruction cache 610 can also be coupled to another level of cache memory, such as L2 cache (in...). Figure 6 (Not shown for ease of illustration). Furthermore, the instruction decoder 615 provides the decoded instructions to the issue queue (IQ) 620 for storage and delivery to a given execution pipeline. The microcode ROM 618 is coupled to the instruction decoder 615.

[0078] The floating-point pipeline 630 includes a floating-point (FP) register file 632, which may include multiple architectural registers with a given bit width such as 128, 256, or 512 bits. The pipeline 630 includes a floating-point scheduler 634 to schedule instructions for execution on one of the pipeline's multiple execution units. In the illustrated embodiment, such an execution unit includes an arithmetic logic unit (ALU) 635, a scrambling unit 636, and a floating-point (FP) adder 638. Furthermore, the results generated in these execution units may be provided back to buffers and / or registers in the register file 632. It should be understood that while these are some of the example execution units shown, additional or different floating-point execution units may exist in another embodiment.

[0079] An integer pipeline 640 may also be provided. In the illustrated embodiment, pipeline 640 includes an integer (INT) register file 642, which may include multiple architectural registers with a given bit width, such as 128 or 256 bits. Pipeline 640 includes an integer execution (IE) scheduler 644 to schedule instructions for execution on one of the pipeline's multiple execution units. In the illustrated embodiment, such an execution unit includes an ALU 645, a shifter unit 646, and a jump execution unit (JEU) 648. Furthermore, the results generated in these execution units may be provided back to buffers and / or registers in register file 642. It should be understood that while these are some of the example execution units shown, additional or different integer execution units may exist in another embodiment.

[0080] The memory execution (ME) scheduler 650 schedules memory operations to be executed in the address generation unit (AGU) 652, which is also coupled to the TLB 654. These structures can be coupled to a data cache 660, which can be an L0 and / or L1 data cache, and which in turn is coupled to additional levels of the cache memory hierarchy, including the L2 cache.

[0081] To provide support for out-of-order execution, in addition to the reorder buffer 680, an allocator / renamer 670 is provided, which is configured to reorder out-of-order instructions for ordered termination. Although in Figure 6The diagram is shown with this particular pipeline architecture in mind, but many variations and substitutions are possible to understand.

[0082] Note that, in (e.g., according to) Figure 5 and Figure 6 In processors with asymmetric cores (microarchitecture), workloads can be dynamically swapped between cores for power management reasons, because these cores, while having different pipeline designs and depths, may have the same or related ISAs. This dynamic core swapping can be performed in a way that is transparent to user applications (and possibly also to the kernel).

[0083] refer to Figure 7 A block diagram of the microarchitecture of a processor core according to yet another embodiment is shown. Figure 7 As shown, core 700 may include a multi-stage ordered pipeline to execute at a very low power consumption level. As one such example, core 700 may have a microarchitecture based on the ARM Cortex A53 design available from ARM Holdings, Inc., Sunnyvale, California. In one implementation, an 8-stage pipeline configured to execute both 32-bit and 64-bit code may be provided. Core 700 includes a fetch unit 710 configured to fetch instructions and provide them to a decode unit 715, wherein the decode unit 715 can decode instructions (e.g., macro instructions of a given ISA such as an ARMv8 ISA). It should also be noted that a queue 730 may be coupled to the decode unit 715 to store the decoded instructions. The decoded instructions are provided to issue logic 725, whereby the decoded instructions may be issued to a given one of a plurality of execution units.

[0084] Also refer to Figure 7 The issue logic 725 can issue instructions to one of a plurality of execution units. In the illustrated embodiment, these execution units include an integer unit 735, a multiplication unit 740, a floating-point / vector unit 750, a dual issue unit 760, and a load / store unit 770. The results of these different execution units can be provided to a write-back (WB) unit 780. It should be understood that although a single write-back unit is shown for ease of illustration, in some implementations, separate write-back units may be associated with each execution unit. Furthermore, it should be understood that although... Figure 7 Each unit and logic shown is represented at a high level, but specific implementations may include more or different structures. Utilizing one or more (such as...) Figure 7 The processor shown (with its pipelined core) can be implemented in many different end products, ranging from mobile devices to server systems.

[0085] refer to Figure 8 A block diagram of the microarchitecture of a processor core according to another embodiment is shown. Figure 8 As shown, core 800 may include a multi-stage, multi-issue, out-of-order pipeline to perform at a very high performance level (which can be compared to...). Figure 7 (Higher power consumption levels occur in core 700). As one example, processor 800 may have a microarchitecture designed according to the ARM Cortex A57. In one implementation, a 15 (or more) stage pipeline configured to execute both 32-bit and 64-bit code may be provided. Furthermore, the pipeline may provide 3-wide (or wider) and 3-issue (or more) operations. Core 800 includes a fetch unit 810 configured to fetch instructions and provide them to a decoder / renamer / dispatcher unit 815 coupled to cache 820. Unit 815 may decode instructions (e.g., macro instructions of the ARMv8 instruction set architecture), rename register references within the instructions, and (ultimately) dispatch the instructions to the selected execution unit. Decoded instructions may be stored in queue 825. Note that although in Figure 8 For ease of illustration, a single queue structure is shown, but it is important to understand that separate queues can be provided for each of several different types of execution units.

[0086] Figure 8 The diagram also shows issue logic 830, from which decoded instructions stored in queue 825 can be issued to selected execution units. Issue logic 830 can also be implemented in specific embodiments where separate issue logic is provided for each of the various types of execution units coupled to it.

[0087] Decoded instructions can be issued to a given one of a plurality of execution units. In the illustrated embodiment, these execution units include one or more integer units 835, multiplication units 840, floating-point / vector units 850, branch units 860, and load / store units 870. In one embodiment, the floating-point / vector unit 850 can be configured to handle 128 or 256 bits of SIMD or vector data. Furthermore, the floating-point / vector execution unit 850 can perform IEEE-754 double-precision floating-point operations. The results from these different execution units can be provided to a write-back unit 880. Note that in some implementations, separate write-back units may be associated with each of the execution units. Furthermore, it should be understood that although… Figure 8 Each unit and logic shown is represented at a high level, but specific implementations may include more or different structures.

[0088] Note in (e.g., according to) Figure 7 and Figure 8In processors with asymmetric cores (microarchitecture), workloads can be dynamically swapped for power management reasons because these cores, while having different pipeline designs and depths, may have the same or related ISAs. This dynamic core swapping can be performed in a way that is transparent to user applications (and possibly also to the kernel).

[0089] Utilize one or more (e.g.) Figures 5-8 Processors designed with pipelined cores (as shown in any one or more of the diagrams) can be implemented in many different end products, ranging from mobile devices to server systems. Now refer to... Figure 9 A block diagram of a processor according to another embodiment of the present invention is shown. Figure 9 In this embodiment, the processor 900 may be a SoC comprising multiple domains, each of which can be controlled to operate at an independent operating voltage and operating frequency. As a specific illustrative example, the processor 900 may be a SoC based on Intel Corporation. Architecture Core TM The processor (e.g., i3, i5, i7, or another such processor). However, other low-power processors (e.g., low-power processors available from Advanced Micro Devices (AMD) of Sunnyvale, California; ARM-based designs from ARM Holdings, Inc. or its licensees; or MIPS-based designs from MIPS Technologies, Inc. of Sunnyvale, California, or its licensees or adopters) may instead exist in other embodiments, such as Apple A7 processors, Qualcomm Snapdragon processors, or Texas Instruments OMAP processors. This SoC can be used in low-power systems (e.g., smartphones, tablets, phablets, Ultrabooks). TM In a computer or other portable computing device, the low-power system may include a heterogeneous system architecture with a processor design based on a heterogeneous system architecture.

[0090] exist Figure 9 In the high-level view shown, processor 900 includes multiple core units 9100-910. nEach core unit may include one or more processor cores, one or more cache memories, and other circuitry. Each core unit 910 may support one or more instruction sets (e.g., x86 instruction set (with some extensions added with newer versions); MIPS instruction set; ARM instruction set (with optional additional extensions such as NEON) or other instruction sets or combinations thereof). Note that some of the core units may be heterogeneous resources (e.g., with different designs). Furthermore, each such core may be coupled to a cache memory (not shown), which in this embodiment may be a shared Level 2 (L2) cache memory. A non-volatile storage device 930 may be used to store various programs and other data. For example, this storage device may be used to store at least some portions of microcode, boot information such as BIOS, other system software, and so on.

[0091] Each core unit 910 may also include an interface (e.g., a bus interface unit) to enable interconnection to additional circuitry of the processor. In one embodiment, each core unit 910 is coupled to a coherent architecture that can act as a main cache coherent on-chip interconnect, which in turn is coupled to a memory controller 935. Furthermore, the memory controller 935 controls communication with memory such as DRAM (in... Figure 9 (The communication is not shown in the diagram for ease of illustration.)

[0092] In addition to the core unit, an additional processing engine exists within the processor, including at least one graphics unit 920. This graphics unit 920 may include one or more graphics processing units (GPUs) to perform graphics processing and possibly perform general-purpose operations on the GPU (so-called GPGPU operations). Furthermore, at least one image signal processor 925 may be present. The signal processor 925 may be configured to process incoming image data received from one or more capture devices, either internally to the SoC or externally.

[0093] Other accelerators may also exist. Figure 9 In the illustration, the video encoder 950 performs encoding operations, including encoding and decoding video information, such as providing hardware acceleration support for high-definition video content. A display controller 955 may also be provided to accelerate display operations, including providing support for internal and external displays of the system. Furthermore, a security processor 945 may be present to perform security operations such as secure boot operations, various password operations, and so on.

[0094] Each unit allows its power consumption to be controlled via a power manager 940, which may include control logic to perform various power management techniques described herein.

[0095] In some embodiments, the processor 900 may further include a non-uniform architecture coupled to a uniform architecture, to which various peripheral devices may be coupled. One or more interfaces 960a-960d enable communication with one or more off-chip devices. This communication may be via various communication protocols, such as PCIe. TM GPIO, USB, I 2 C, UART, MIPI, SDIO, DDR, SPI, HDMI, and other types of communication protocols. Although in Figure 9 The embodiments are shown at this high level, but it is to be understood that the scope of the invention is not limited in this respect.

[0096] Now for reference Figure 10 A block diagram of a representative SoC is shown. In the illustrated embodiment, SoC 1000 may be a multi-core SoC configured for low-power operation and optimized for inclusion in smartphones or other low-power devices such as tablets or other portable computing devices. As an example, SoC 1000 may be implemented using asymmetric or different types of cores, such as a combination of higher-power and / or low-power cores, such as disordered and ordered cores. In different embodiments, these cores may be based on... Architecture TM Core design or ARM architecture design. In other embodiments, a hybrid of Intel and ARM cores can be implemented in a given SoC.

[0097] from Figure 10 As can be seen, the SoC 1000 includes a first core domain 1010 having multiple first cores 10120-10123. In one example, these cores may be low-power cores such as ordered cores. In one embodiment, these first cores may be implemented as ARM Cortex A53 cores. Furthermore, these cores are coupled to a cache memory 1015 of the core domain 1010. Additionally, the SoC 1000 includes a second core domain 1020. Figure 10 In the illustration, the second core domain 1020 has multiple second cores 10220-10223. In one example, these cores may be cores with higher power consumption than the first core 1012. In one embodiment, the second cores may be out-of-order cores, which may be implemented as ARM Cortex A57 cores. Furthermore, these cores are coupled to the cache memory 1025 of the core domain 1020. Note that although... Figure 10 The example shown includes 4 cores in each domain, but it is important to understand that in other examples there may be more or fewer cores in a given domain.

[0098] Further reference Figure 10 It also provides a graphics domain 1030, which may include one or more graphics processing units (GPUs) configured to independently perform graphics workloads (e.g., provided by one or more cores of core domains 1010 and 1020). As an example, in addition to providing graphics and display rendering operations, GPU domain 1030 may also be used to provide display support for various screen sizes.

[0099] As can be seen, various domains are coupled to a coherent interconnect 1040, which in one embodiment may be a cache coherent interconnect architecture, which in turn is coupled to an integrated memory controller 1050. In some examples, the coherent interconnect 1040 may include shared cache memory, such as an L3 cache. In one embodiment, the memory controller 1050 may be a direct memory controller to provide multiple channels of communication with off-chip memory, such as multiple channels of DRAM (in... Figure 10 (Not shown in the diagram for ease of illustration).

[0100] The number of core domains can vary in different examples. For instance, for a low-power SoC suitable for inclusion in a mobile computing device, such as... Figure 10 The limited number of core domains shown may exist. Furthermore, in this low-power SoC, the core domain 1020, which includes higher-power cores, may have an even smaller number of such cores. For example, in one implementation, two cores 1022 may be provided to enable operation at a reduced power consumption level. Additionally, different core domains may be coupled to an interrupt controller to enable dynamic switching of workloads between different domains.

[0101] In other embodiments, a larger number of core domains and additional optional IP logic may be present, as the SoC can be scaled to higher performance (and power) levels for inclusion in other computing devices (e.g., desktop computers, servers, high-performance computing systems, base stations, etc.). As one such example, four core domains, each with a given number of out-of-order cores, may be provided. Furthermore, in addition to optional GPU support (which, as an example, may take the form of a GPGPU), one or more accelerators may be provided to offer optimized hardware support for specific functions (e.g., web services, network processing, switching, etc.). Additionally, input / output interfaces may be present to couple such accelerators to off-chip components.

[0102] Now for reference Figure 11 This shows a block diagram of another example SoC. Figure 11In some embodiments, the SoC 1100 may include various circuitry to enable high performance for multimedia applications, communications, and other functions. Thus, the SoC 1100 is suitable for inclusion in a wide variety of portable devices and other devices, such as smartphones, tablets, smart TVs, and so on. In the illustrated example, the SoC 1100 includes a central processor unit (CPU) domain 1110. In one embodiment, multiple individual processor cores may reside within the CPU domain 1110. As an example, the CPU domain 1110 may be a quad-core processor with four multi-threaded cores. Such a processor may be homogeneous or heterogeneous, such as a mixture of low-power and high-power processor cores.

[0103] Furthermore, a GPU domain 1120 is provided to perform advanced graphics processing in one or more GPUs to handle graphics and compute APIs. In addition to advanced computations that can occur during the execution of multimedia instructions, the DSP unit 1130 may also provide one or more low-power DSPs to handle low-power multimedia applications, such as music playback, audio / video, etc. Furthermore, the communication unit 1140 may include various components to provide connectivity via various wireless protocols, such as cellular communications (including 3G / 4G LTE), and protocols such as Bluetooth. TM Wireless LAN protocols such as IEEE 802.11, etc.

[0104] Furthermore, the multimedia processor 1150 can be used to perform the capture and playback of high-definition video and audio content, including processing of user gestures. The sensor unit 1160 may include multiple sensors and / or sensor controllers to interface with various off-chip sensors present in a given platform. The image signal processor (ISP) 1170 can perform image processing on content captured from one or more cameras (including still cameras and video cameras) on the platform.

[0105] Display processor 1180 can provide support for connectivity to a high-definition display with a given pixel density, including the ability to wirelessly transmit content for playback on such a display. Additionally, location unit 1190 may include a Global Positioning System (GPS) receiver with support for multiple GPS constellations to provide applications with highly accurate positioning information obtained using such a GPS receiver. It should be understood that, although in Figure 11 The example is shown with this specific set of components, but many variations and substitutions are possible.

[0106] Now for reference Figure 12The diagram illustrates a block diagram of an example system that can be used with the embodiments. It can be seen that system 1200 can be a smartphone or other wireless communication device. Baseband processor 1205 is configured to perform various signal processing operations with respect to communication signals to be transmitted from or received by the system. Furthermore, baseband processor 1205 is coupled to application processor 1210, which can be the system's main CPU for executing the operating system and other system software, as well as user applications such as many well-known social media and multimedia apps. Application processor 1210 can also be configured to perform various other computational operations for the device.

[0107] Furthermore, the application processor 1210 may be coupled to a user interface / display 1220, such as a touchscreen display. Additionally, the application processor 1210 may be coupled to a memory system including non-volatile memory (i.e., flash memory 1230) and system memory (i.e., dynamic random access memory (DRAM) 1235). It can also be seen that the application processor 1210 is also coupled to a capture device 1241, such as one or more image capture devices capable of recording video and / or still images.

[0108] Still referencing Figure 12 A universal integrated circuit card (UICC) 1246 is also coupled to the application processor 1210. The UICC 1246 includes a subscriber identity module and may include secure storage and a password processor. The system 1200 may also include a security processor 1250, which is coupled to the application processor 1210. Multiple sensors 1225 are coupled to the application processor 1210 to enable input of various sensed information, such as accelerometer readings and other environmental information. An audio output device 1295 provides an interface for outputting sound, such as in the form of voice communication, played or streaming audio data, etc.

[0109] As also illustrated, a near field communication (NFC) contactless interface 1260 is provided, which communicates in the NFC near field via an NFC antenna 1265. Although in Figure 12 The image shows separate antennas, but it's important to understand that in some implementations, a single antenna or different sets of antennas can be provided to enable various wireless functions.

[0110] A power management integrated circuit (PMIC) 1215 is coupled to an application processor 1210 to perform platform-level power management. To this end, the PMIC 1215 can issue power management requests to the application processor 1210 to enter certain low-power states as needed. Furthermore, based on platform constraints, the PMIC 1215 can also control the power levels of other components of the system 1200.

[0111] To enable communication transmission and reception, various circuits can be coupled between the baseband processor 1205 and the antenna 1290. Specifically, a radio frequency (RF) transceiver 1270 and a wireless local area network (WLAN) transceiver 1275 may be present. Generally, the RF transceiver 1270 can be used to receive and transmit wireless data and calls according to a given wireless communication protocol (e.g., 3G or 4G wireless communication protocol), such as Code Division Multiple Access (CDMA), Global System for Mobile Communication (GSM), Long Term Evolution (LTE), or other protocols. Furthermore, a GPS sensor 1280 may be present. Other wireless communications may also be provided, such as the reception or transmission of radio signals (e.g., AM / FM) and other signals. Additionally, local wireless communication can also be implemented via the WLAN transceiver 1275.

[0112] Now for reference Figure 13 A block diagram of another example system that can be used with the embodiments is shown. Figure 13 In the illustration, system 1300 can be a mobile low-power system, such as a tablet computer, a 2:1 tablet device, a phablet, or other convertible or standalone tablet system. As shown, SoC 1310 is present and can be configured to operate as the application processor of the device.

[0113] Various devices can be coupled to the SoC 1310. In the illustrated diagram, the memory subsystem includes flash memory 1340 and DRAM 1345 coupled to the SoC 1310. Additionally, a touch panel 1320 is coupled to the SoC 1310 to provide display capabilities and user input via touch, including providing a virtual keyboard on the display of the touch panel 1320. For wired network connectivity, the SoC 1310 is coupled to an Ethernet interface 1330. A peripheral hub 1325 is coupled to the SoC 1310 to enable interfacing with various peripheral devices, such as those coupled to the system 1300 via various ports or other connectors.

[0114] In addition to the internal power management circuitry and functions within the SoC 1310, the PMIC 1380 is also coupled to the SoC 1310 to provide platform-based power management, such as based on whether the system is powered by the battery 1390 or by AC power via the AC adapter 1395. Beyond this power-based management, the PMIC 1380 can also perform platform power management activities based on environment and usage conditions. Furthermore, the PMIC 1380 can communicate control and status information to the SoC 1310 to trigger various power management actions within the SoC 1310.

[0115] Still referencing Figure 13 To provide wireless capabilities, the WLAN unit 1350 is coupled to the SoC 1310 and, in turn, to the antenna 1355. In various implementations, the WLAN unit 1350 may provide communication according to one or more wireless protocols.

[0116] As also illustrated, multiple sensors 1360 can be coupled to the SoC 1310. These sensors may include various accelerometers, environmental and other sensors, including user posture sensors. Finally, an audio codec 1365 is coupled to the SoC 1310 to provide an interface to an audio output device 1370. It should be understood, of course, that although in Figure 13 This is the implementation shown in this particular way, but many variations and substitutions are possible.

[0117] Now for reference Figure 14 It shows items such as notebooks and Ultrabooks. TMA block diagram of a representative computer system 1400, such as another small form factor system. Processor 1410, in one embodiment, includes a microprocessor, a multi-core processor, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, or other known processing elements. In the illustrated implementation, processor 1410 acts as a main processing unit and central hub to communicate with many of the various components of system 1400 and may include power management circuitry as described herein. As an example, processor 1410 is implemented as a System-on-Chip (SoC).

[0118] In one embodiment, processor 1410 communicates with system memory 1415. As an illustrative example, system memory 1415 is implemented via multiple memory devices or modules to provide a fixed amount of system memory.

[0119] To provide persistent storage for information such as data, applications, one or more operating systems, etc., the mass storage device 1420 may also be coupled to the processor 1410. In various embodiments, to enable thinner and lighter system designs and to improve system responsiveness, the mass storage device may be implemented via an SSD or it may be implemented primarily using a hard disk drive (HDD), where a smaller amount of SSD storage acts as an SSD cache to enable non-volatile storage of context state and other such information during power-down events, thereby allowing for rapid power-up when system activity resumes. Figure 14 It is also shown that the flash device 1422 can be coupled to the processor 1410, for example, via a serial peripheral interface (SPI). This flash device can provide non-volatile storage for system software, including basic input / output software (BIOS) and other system firmware.

[0120] Various input / output (I / O) devices can reside within the system 1400. Specifically, in Figure 14 The embodiment shown is a display 1424, which may be a high-definition LCD or LED panel that also provides a touchscreen 1425. In one embodiment, the display 1424 may be coupled to the processor 1410 via a display interconnect, which may be implemented as a high-performance graphics interconnect. The touchscreen 1425 may be coupled to the processor 1410 via another interconnect, which in one embodiment may be an I... 2 C interconnect. For example, Figure 14As also shown, in addition to the touchscreen 1425, user input via touch can also occur through the touchpad 1430, which can be configured within the housing and can also be coupled to the same I / O pin as the touchscreen 1425. 2 C interconnect.

[0121] For sensing, computing, and other purposes, various sensors may exist within the system and may be coupled to the processor 1410 in different ways. Some inertial and environmental sensors may be located via the sensor hub 1440 (e.g., via I...). 2 The C interconnect is coupled to the processor 1410. Figure 14 In the illustrated embodiments, these sensors may include an accelerometer 1441, an ambient light sensor (ALS) 1442, a compass 1443, and a gyroscope 1444. Other environmental sensors may include one or more thermal sensors 1446, which in some embodiments are coupled to the processor 1410 via a system management bus (SMBus).

[0122] exist Figure 14 As can also be seen, various peripheral devices can be coupled to the processor 1410 via a low pin count (LPC) interconnect. In the illustrated embodiment, various components can be coupled via an embedded controller 1435. Such components may include a keyboard 1436 (e.g., coupled via a PS / 2 interface), a fan 1437, and a thermal sensor 1439. In some embodiments, a touchpad 1430 may also be coupled to the EC 1435 via a PS / 2 interface. Furthermore, security processors such as a trusted platform module (TPM) 1438 may also be coupled to the processor 1410 via this LPC interconnect.

[0123] System 1400 can communicate with external devices in various ways, including wirelessly. Figure 14 In the illustrated embodiments, various wireless modules are present, each corresponding to a radio device configured for a specific wireless communication protocol. One method for wireless communication in short ranges, such as near-field communication, is via an NFC unit 1445, which in one embodiment can communicate with the processor 1410 via an SMBus. Note that via this NFC unit 1445, devices in close proximity can communicate.

[0124] from Figure 14 It can also be seen that additional wireless units may include other short-range wireless engines, including WLAN unit 1450 and Bluetooth. TM Unit 1452. Utilizing WLAN unit 1450, Wi-FiTM Communication can be achieved via Bluetooth. TM Unit 1452, short-range Bluetooth TM Communication can occur. These units can communicate with processor 1410 via a given link.

[0125] Furthermore, wireless wide-area communication (e.g., according to cellular or other wireless wide-area protocols) can occur via WWAN unit 1456, which can then be coupled to subscriber identity module (SIM) 1457. Additionally, a GPS module 1455 may also be present to enable the reception and use of location information. Note that in Figure 14 In the illustrated embodiment, the WWAN unit 1456 and an integrated capture device such as a camera module 1454 can communicate via a given link.

[0126] To provide audio input and output, an audio processor may be implemented via a digital signal processor (DSP) 1460, which may be coupled to a processor 1410 via a high-definition audio (HDA) link. Similarly, the DSP 1460 may communicate with an integrated encoder / decoder (CODEC) and amplifier 1462, which may in turn be coupled to an output speaker 1463, which may be implemented within a housing. Likewise, the amplifier and CODEC 1462 may be coupled to receive audio input from a microphone 1465, which in one embodiment may be implemented via a dual-array microphone (e.g., a digital microphone array) to provide high-quality audio input, thereby enabling voice-activated control of various operations within the system. It should also be noted that audio output may be provided from the amplifier / CODEC 1462 to a headphone jack 1464. Although in Figure 14 The embodiments are illustrated with these specific components, but it is to be understood that the scope of the invention is not limited in this respect.

[0127] Implementation examples can be found in many different system types. Reference now. Figure 15A A block diagram of a system according to an embodiment of the present invention is shown. Figure 15A As shown, the multiprocessor system 1500 is a point-to-point interconnect system and includes a first processor 1570 and a second processor 1580 coupled via a point-to-point interconnect 1550. Figure 15AAs shown, each of processors 1570 and 1580 can be a multi-core processor, including first and second processor cores (i.e., processor cores 1574a and 1574b and processor cores 1584a and 1584b), although many more cores may be present in the processor. Each processor may include a PCU or other power management logic to perform processor-based power management as described herein.

[0128] Still referencing Figure 15A The first processor 1570 also includes an integrated memory controller (IMC) 1572 and point-to-point (PP) interfaces 1576 and 1578. Similarly, the second processor 1580 includes an IMC 1582 and PP interfaces 1586 and 1588. As shown in Figure 15, IMCs 1572 and 1582 couple the processors to corresponding memories, namely memories 1532 and 1534, which may be part of system memory (e.g., DRAM) locally attached to the respective processors. The first processor 1570 and the second processor 1580 may be coupled to chipset 1590 via PP interconnects 1562 and 1564, respectively. Figure 15A As shown, chipset 1590 includes PP interfaces 1594 and 1598.

[0129] Furthermore, chipset 1590 includes interface 1592 for coupling chipset 1590 to high-performance graphics engine 1538 via PP interconnect 1539. Furthermore, chipset 1590 can be coupled to first bus 1516 via interface 1596. Figure 15A As shown, various input / output (I / O) devices 1514 can be coupled to a first bus 1516 along with a bus bridge 1518, wherein the bus bridge 1518 couples the first bus 1516 to a second bus 1520. Various devices can be coupled to the second bus 1520, including, for example, a keyboard / mouse 1522, a communication device 1526, and a data storage unit 1528 (e.g., a disk drive or other mass storage device), wherein the data storage unit 1528 may include code 1530 in one embodiment. Additionally, audio I / O 1524 can be coupled to the second bus 1520. Embodiments can be incorporated into other types of systems including mobile devices such as smartphones, tablets, netbooks, and ultrabooks. TM ,etc.

[0130] Now for reference Figure 15B A block diagram of a second, more specific exemplary system 1501 according to an embodiment of the present invention is shown. Figure 15Aand Figure 15B Similar elements in the text have similar labels, and Figure 15A Some aspects were from Figure 15B Omitted to avoid ambiguity Figure 15B Other aspects.

[0131] Figure 15B The diagram shows that processors 1570 and 1580 may include integrated memory and I / O control logic (“CL”) 1571 and 1581, respectively. Thus, control logic 1571 and 1581 include an integrated memory controller unit and I / O control logic. Figure 15B The diagram shows that not only are the memories 1532 and 1534 coupled to control logic 1571 and 1581, but the I / O device 1513 is also coupled to control logic 1571 and 1581. The conventional I / O device 1515 is coupled to chipset 1590.

[0132] One or more aspects of at least one embodiment may be implemented by representative code stored on a machine-readable medium, which represents and / or defines logic within an integrated circuit, such as a processor. For example, the machine-readable medium may include instructions representing various logics within a processor. When read by a machine, the instructions cause the machine to fabricate logic to perform the techniques described herein. This representation, referred to as an "IP core," is a reusable unit of logic for an integrated circuit, which may be stored on a tangible machine-readable medium as a hardware model describing the structure of the integrated circuit. This hardware model may be provided to various customers or manufacturing facilities, which load the hardware model onto fabrication machines that manufacture integrated circuits. Integrated circuits may be fabricated such that the circuit performs the operations described in association with any of the embodiments described herein.

[0133] Figure 16This is a block diagram illustrating an IP core development system 1600, which can be used to fabricate integrated circuits to perform operations according to embodiments. The IP core development system 1600 can be used to generate modular, reusable designs that can be incorporated into larger designs or used to construct entire integrated circuits (e.g., SoC integrated circuits). Design facility 1630 can generate software simulations 1610 of the IP core design in a high-level programming language (e.g., C / C++). Software simulation 1610 can be used to design, test, and verify the behavior of the IP core. Register transfer level (RTL) designs can then be created or synthesized from the simulation model. RTL design 1615 is an abstraction of the behavior of an integrated circuit that models the flow of digital signals between hardware registers, including associative logic performed using the modeled digital signals. In addition to RTL design 1615, lower-level designs at the logic or transistor levels can also be created, designed, or synthesized. Thus, the specific details of the initial design and simulation can vary.

[0134] The RTL design 1615 or its equivalent can also be synthesized by a design facility into a hardware model 1620, which may take the form of a hardware description language (HDL) or some other representation of physical design data. The HDL can be further simulated or tested to validate the IP core design. The IP core design can be stored and delivered to a third-party fabrication facility 1665 using non-volatile memory 1640 (e.g., a hard disk, flash memory, or any other non-volatile storage medium). Alternatively, the IP core design can be transmitted via a wired connection 1650 or a wireless connection 1660 (e.g., via the Internet). The fabrication facility 1665 can then fabricate an integrated circuit at least partially based on the IP core design. The fabricated integrated circuit can be configured to perform operations according to the components and / or processes described herein.

[0135] The following description Figures 17A-25 Exemplary architectures and systems for implementing embodiments of the components and / or processes described herein are described in detail. In some embodiments, one or more hardware components and / or instructions described herein are emulated as detailed below, or implemented as software modules.

[0136] Examples of the instructions(s) detailed above can be implemented using the “generic vector-friendly instruction format” detailed below. In other embodiments, this format is not used and another instruction format is used; however, the descriptions below of writing to mask registers, various data transformations (allocation, broadcasting, etc.), addressing, etc., generally apply to the descriptions of examples of the instructions(s) above. Furthermore, exemplary systems, architectures, and pipelines are detailed below. Examples of the instructions(s) above can be executed on such systems, architectures, and pipelines, but are not limited to those detailed above.

[0137] An instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, bit positions) to specify the operation to be performed (e.g., opcode) and the operand(s) on which the operation is performed, and / or other data fields(e.g., mask), etc. Some instruction formats are further decomposed through the definition of instruction templates (or subformats). For example, an instruction template for a given instruction format may be defined as having different subsets of the fields of that instruction format (the included fields are generally in the same order, but at least some have different bit positions because fewer fields are included) and / or be defined as having given fields that are interpreted in different ways. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, as a given instruction template in the instruction template of that instruction format) and includes fields for specifying the operation and operand. For example, a demonstrative ADD instruction has a specific opcode and instruction format, which includes an opcode field to specify the opcode and an operand field to select the operand (source 1 / target and source 2); and this ADD instruction appearing in the instruction stream will have specific content in the operand field for selecting the specific operand. A collection of SIMD extensions known as Advanced Vector Extension (AVX) (AVX1 and AVX2) and using the Vector Extension (VEX) encoding scheme has been published and / or released (e.g., see...). Software Developer's Manual for IA-64 and IA-32 Architectures, September 2014; and see also Advanced Vector Extension Programming Reference, October 2014.

[0138] Exemplary instruction format

[0139] Implementations of the instructions(s) described herein may be implemented in various formats. Furthermore, exemplary systems, architectures, and pipelines are detailed below. Implementations of the instructions(s) may be executed on such systems, architectures, and pipelines, but are not limited to those detailed herein.

[0140] General Vector-Friendly Instruction Format

[0141] Vector-friendly instruction format is an instruction format suitable for vector instructions (e.g., having certain fields specific to vector operations). Although an embodiment in which both vector and scalar operations are supported through vector-friendly instruction format has been described, alternative embodiments use only vector operations of vector-friendly instruction format.

[0142] Figures 17A-17B This is a block diagram illustrating a general vector-friendly instruction format and its instruction template according to an embodiment of the present invention. Figure 17A This is a block diagram illustrating a general vector-friendly instruction format and its category A instruction template according to an embodiment of the present invention; while Figure 17B This is a block diagram illustrating a general vector-friendly instruction format and its Category B instruction template according to an embodiment of the present invention. Specifically, Category A and Category B instruction templates are defined for the general vector-friendly instruction format 1700, both of which include a no-memory-access 1705 instruction template and a memory-access 1720 instruction template. The term "general" in the context of the vector-friendly instruction format means that the instruction format is not bound to any particular instruction set.

[0143] While embodiments of the invention described herein will support the following items in which the vector-friendly instruction format is supported: 64-byte vector operand length (or size) having a data element width (or size) of 32 bits (4 bytes) or 64 bits (8 bytes) (therefore, a 64-byte vector consists of 16 double-word elements or 8 quad-word elements); 64-byte vector operand length (or size) having a data element width (or size) of 16 bits (2 bytes) or 8 bits (1 byte); 32-byte vector operand length (or size) having a data element width (or size) of 32 bits (4 bytes), 64... The data element width (or size) can be 8 bits (8 bytes), 16 bits (2 bytes), or 8 bits (1 byte); and the vector operand length (or size) can be 16 bytes, having a data element width (or size) of 32 bits (4 bytes), 64 bits (8 bytes), 16 bits (2 bytes), or 8 bits (1 byte); however, alternative embodiments may support more, fewer, and / or different vector operand sizes (e.g., 256-byte vector operands) with more, fewer, or different data element widths (e.g., a data element width of 128 bits (16 bytes)).

[0144] Figure 17AThe Category A instruction templates include: 1) within the No Memory Access 1705 instruction template, showing the No Memory Access, Full Rounding Control Operation 1710 instruction template and the No Memory Access, Data Transformation Operation 1715 instruction template; and 2) within the Memory Access 1720 instruction template, showing the Memory Access, Transient 1725 instruction template and the Memory Access, Non-Transient 1730 instruction template. Figure 17B The Category B instruction templates include: 1) within the No Memory Access 1705 instruction template, which shows the No Memory Access, Write Mask Control, Partial Rounding Control type operation 1712 instruction template and the No Memory Access, Write Mask Control, vsize type operation 1717 instruction template; and 2) within the Memory Access 1720 instruction template, which shows the Memory Access, Write Mask Control 1727 instruction template.

[0145] General Vector Friendly Command Format 1700 includes the following: Figures 17A-17B The following fields are listed in the order shown.

[0146] Format field 1740 - A specific value in this field (instruction format identifier value) uniquely identifies a vector-friendly instruction format, thus indicating that an instruction adopting the vector-friendly instruction format appears in the instruction stream. Therefore, this field is optional, as it is not required for instruction sets that only have a general vector-friendly instruction format.

[0147] The basic operation field 1742 distinguishes different basic operations.

[0148] Register index field 1744 – its contents directly or by address generate the location of the specified source and target operands, whether they are in registers or memory. These include a sufficient number of bits to select N registers from a PxQ (e.g., 32x512, 16x128, 32x1024, 64x1024) register file. While in one embodiment N can be up to three source and one target registers, alternative embodiments may support more or fewer source and target registers (e.g., up to two sources, where one of these sources also acts as a target; up to three sources, where one of these sources also acts as a target; up to two sources and one target).

[0149] Modifier field 1746 distinguishes between instructions in the general vector instruction format that specify memory access and those that do not; that is, it differentiates between the no-memory-access instruction template 1705 and the memory-access instruction template 1720. Memory access operations read and / or write to the memory hierarchy (in some cases, using values ​​in registers to specify the source and / or destination addresses), while non-memory access operations do not read and / or write to the memory hierarchy (e.g., the source and destination are registers). Although in one embodiment this field also selects between three different ways of performing memory address calculation, alternative embodiments may support more, fewer, or different ways of performing memory address calculation.

[0150] Enhanced Operation Field 1750 – Its content distinguishes which of the various operations, in addition to the basic operation, should be performed. This field is context-dependent. In one embodiment of the invention, this field is divided into Category Field 1768, Alpha Field 1752, and Beta Field 1754. Enhanced Operation Field 1750 allows a common group of operations to be performed in a single instruction, rather than two, three, or four instructions.

[0151] The scaling field 1760 – its content allows scaling the contents of the index field for memory address generation (e.g., for using 2). 缩放比例 *Address generation of index + base address.

[0152] Displacement field 1762A – its contents are used as part of memory address generation (e.g., for memory addresses using 2). 缩放比例 *Address generation of index + base address + offset.

[0153] The displacement factor field 1762B (note that placing displacement field 1762A directly above displacement factor field 1762B indicates that one or the other is being used) – its contents are used as part of the address generation; it specifies the displacement factor scaled by the size (N) of the memory access – where N is the number of bytes in the memory access (e.g., for a memory access using 2...). 缩放比例 *Address generation from index + base address + scaled displacement). Redundant low-order bits are ignored, and therefore, the contents of the displacement factor field are multiplied by the total size (N) of the memory operand to generate the final displacement to be used to calculate the effective address. The value of N is determined by the processor hardware at runtime based on the full opcode field 1774 (described later herein) and the data manipulation field 1754C. The displacement field 1762A and the displacement factor field 1762B are optional because they are not used in the No Memory Access 1705 instruction template, and / or different embodiments may implement only one of them or neither.

[0154] The data element width field 1764 distinguishes which of several data element widths should be used (in some embodiments, for all instructions; in other embodiments, for only some instructions). This field is optional because it is not needed if only one data element width is supported and / or the data element width is supported using some aspect of the opcode.

[0155] The write mask field 1770—whose content controls, based on the position of each data element, whether that position in the target vector operation object reflects the result of the basic and enhanced operations. Category A instruction templates support merge-write masking, while Category B instruction templates support both merge-write masking and zero-write masking. When merging, the vector mask allows any set of elements in the target to be protected from updates during the execution of any operation (specified by the basic and enhanced operations); in another embodiment, the old value of each element in the target with a corresponding mask bit of 0 is preserved. In contrast, the zero-vector mask allows any set of elements in the target to be zeroed during the execution of any operation (specified by the basic and enhanced operations); in one embodiment, the elements of the target are set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the performed operation (i.e., the span of the modified elements, from first to last); however, the modified elements do not necessarily have to be contiguous. Thus, the write mask field 1770 allows for some vector operations, including load, store, arithmetic, logical, etc. Although an embodiment of the invention has been described in which the contents of the write mask field 1770 select one of several write mask registers containing the write mask to be used (therefore the contents of the write mask field 1770 indirectly identify the mask to be performed), alternative embodiments are provided as substitutes or additions that allow the contents of the mask write field 1770 to directly specify the mask to be performed.

[0156] The immediate field 1772 – its content allows for the specification of immediate. This field is optional because it does not exist in implementations of generic vector-friendly formats that do not support immediate, and it does not exist in instructions that do not use immediate.

[0157] Category field 1768 – Its content distinguishes different categories of instructions. (See reference) Figures 17A-17B This field allows you to choose between Category A and Category B instructions. Figures 17A-17B In this context, rounded rectangles are used to indicate that a specific value exists in a field (e.g., in...). Figures 17A-17B (This refers to category A (1768A) and category B (1768B) for category field 1768).

[0158] Category A instruction template

[0159] In the case of the non-memory access 1705 instruction template of category A, the alpha field 1752 is interpreted as the RS field 1752A, the content of which distinguishes which of the different enhanced operation types should be executed (for example, the instruction templates for non-memory access rounding operation 1710 and non-memory access data transformation operation 1715 specify rounding 1752A.1 and data transformation 1752A.2, respectively), while the beta field 1754 distinguishes which of the specified type of operation should be executed. In the non-memory access 1705 instruction template, the scaling field 1760, the displacement field 1762A, and the displacement scaling field 1762B are absent.

[0160] No memory access instruction template - Fully round-control operation

[0161] In the instruction template of the No Memory Access Full Rounding Control Operation 1710, the beta field 1754 is interpreted as the rounding control field 1754A, the contents of which provide static rounding. While the rounding control field 1754A in the described embodiment of the invention includes a suppress all floating point exceptions (SAE) field 1756 and a rounding operation control field 1758, alternative embodiments may support encoding both concepts into the same field or having only one or the other of these concepts / fields (e.g., only the rounding operation control field 1758).

[0162] SAE field 1756 – its content distinguishes whether exception event reporting is disabled; when the content of SAE field 1756 indicates that suppression is enabled, a given instruction will not report any kind of floating-point exception flag and will not trigger any floating-point exception handler.

[0163] The rounding operation control field 1758 distinguishes which of a set of rounding operations to perform (e.g., round up, round down, round to zero, and round to nearest). Thus, the rounding operation control field 1758 allows the rounding mode to be changed per instruction. In one embodiment of the invention, where the processor includes a control register for specifying the rounding mode, the content of the rounding operation control field 1750 overrides that register value.

[0164] No memory access instruction template - data transformation operation

[0165] In the instruction template 1715 for no memory access data transformation operation, the beta field 1754 is interpreted as the data transformation field 1754B, the contents of which distinguish which of several data transformations is to be performed (e.g., no data transformation, dispatch, broadcast).

[0166] In the case of memory access instruction template 1720 of category A, alpha field 1752 is interpreted as eviction hint field 1752B, the content of which distinguishes which eviction hint to use (in... Figure 17A In the memory access transient 1725 instruction template and the memory access non-transient 1730 instruction template, transient 1752B.1 and non-transient 1752B.2 are specified respectively, while the beta field 1754 is interpreted as the data manipulation field 1754C, the content of which distinguishes which of several data manipulation operations (also called primitives) should be performed (e.g., no manipulation; broadcast; source upcast; and destination downcast). The memory access 1720 instruction template includes a scaling field 1760 and optionally includes a displacement field 1762A or a displacement scaling field 1762B.

[0167] Vector memory instructions perform vector loading from and vector storing to memory, with translation support. Like regular vector instructions, vector memory instructions transfer data to / from memory element by element, where the actual data transferred is determined by the contents of an element vector mask selected as the write mask.

[0168] Memory access instruction template - transient

[0169] Transient data is data that is likely to be reused quickly enough to benefit from caching. However, this is a hint, and different processors may implement it in different ways, including ignoring the hint entirely.

[0170] Memory access instruction template - non-transient

[0171] Non-transient data is data that is unlikely to be fast enough to benefit from cached reuse in the L1 cache and should be given priority for eviction. However, this is a hint, and different processors may implement it in different ways, including ignoring the hint entirely.

[0172] Category B instruction template

[0173] In the case of instruction template of category B, alpha field 1752 is interpreted as write mask control (Z) field 1752C, the content of which distinguishes whether the write mask controlled by write mask field 1770 should be merged or zeroed.

[0174] In the case of the non-memory access 1705 instruction template of category B, a portion of the beta field 1754 is interpreted as the RL field 1757A, the content of which distinguishes which of the different enhanced operation types should be executed (for example, for the no-memory access, write mask control, partial rounding control type operation 1712 instruction template and the no-memory access, write mask control, VSIZE type operation 1717 instruction template, rounding 1757A.1 and vector length (VSIZE) 1757A.2 are specified respectively), while the remainder of the beta field 1754 distinguishes which of the specified types of operations should be executed. In the no-memory access 1705 instruction template, the scaling field 1760, the displacement field 1762A, and the displacement scaling field 1762B are absent.

[0175] In the instruction template 1710, which is a no-memory-access, write-mask-controlled, partial-round-control operation, the remainder of the beta field 1754 is interpreted as the rounding operation field 1759A and exception reporting is disabled (the given instruction does not report any kind of floating-point exception flag and does not raise any floating-point exception handler).

[0176] Rounding operation control field 1759A – Like rounding operation control field 1758, its contents distinguish which of a set of rounding operations to perform (e.g., round up, round down, round to zero, and round to nearest). Thus, rounding operation control field 1759A allows the rounding mode to be changed on a per-instruction basis. In one embodiment of the invention, where the processor includes a control register for specifying the rounding mode, the contents of rounding operation control field 1750 overwrite that register value.

[0177] In the instruction template 1717 for No Memory Access, Write Mask Control, and VSIZE Operation, the remainder of the beta field 1754 is interpreted as the vector length field 1759B, the contents of which distinguish which of several data vector lengths to be executed on (e.g., 128, 256, or 512 bytes).

[0178] In the case of the Class B memory access 1720 instruction template, a portion of the beta field 1754 is interpreted as a broadcast field 1757B, the content of which distinguishes whether a broadcast data manipulation operation is to be performed, while the remainder of the beta field 1754 is interpreted as a vector length field 1759B. The memory access 1720 instruction template includes a scaling field 1760 and optionally includes a displacement field 1762A or a displacement scaling field 1762B.

[0179] Regarding the general vector-friendly instruction format 1700, the complete opcode field 1774 is shown as including a format field 1740, a basic operation field 1742, and a data element width field 1764. While one embodiment is shown in which the complete opcode field 1774 includes all of these fields, embodiments that do not support all of these fields include fewer fields. The complete opcode field 1774 provides the operation code (opcode).

[0180] The enhanced operation field 1750, data element width field 1764, and write mask field 1770 allow these features to be specified per instruction in a generic vector-friendly instruction format.

[0181] The combination of the write mask field and the data element width field creates typed instructions because they allow masks to be applied based on different data element widths.

[0182] The various instruction templates found within categories A and B are advantageous in different situations. In some embodiments of the invention, different processors or different cores within a processor may support only category A, only category B, or both categories. For example, a high-performance general-purpose out-of-order core intended for general-purpose computing may support only category B, a core intended primarily for graphics and / or scientific (throughput) computing may support only category A, and a core intended for both may support both categories (of course, a core having some mixture of templates and instructions from both categories, but not all templates and instructions from both categories, is within the scope of the invention). Additionally, a single processor may include multiple cores, all of which support the same category or different cores supporting different categories. For example, in a processor with separate graphics and general-purpose cores, one of the graphics cores intended primarily for graphics and / or scientific computing may support only category A, while one or more of the general-purpose cores may be a high-performance general-purpose core intended for general-purpose computing (with out-of-order execution and register renaming) that supports only category B. Another processor without a separate graphics core may include one or more general-purpose ordered or out-of-order cores supporting both category A and category B. Of course, in different embodiments of the invention, features from one category may also be implemented in another category. Programs written in high-level languages ​​will be placed (e.g., compiled just-in-time or statically) in various executable forms, including: 1) forms having only instructions from one or more categories supported by the target processor for execution; or 2) forms having alternative routines written using different combinations of instructions from all categories and having control flow code that selects the routine to be executed based on the instructions supported by the processor currently executing the code.

[0183] Exemplary Vector-Friendly Instruction Format

[0184] Figures 18A-18C This is a block diagram illustrating an exemplary vector-friendly instruction format according to an embodiment of the present invention. Figure 18A The diagram illustrates a specific vector-friendly instruction format 1800 in the sense that it specifies the position, size, interpretation, and order of fields, as well as the values ​​of some of these fields. The specific vector-friendly instruction format 1800 can be used to extend the x86 instruction set so that some of the fields are similar to or identical to those used in existing x86 instruction sets and their extensions (e.g., AVX). This format is consistent with the prefix-encoded fields, real opcode byte fields, MOD R / M fields, SIB fields, shift fields, and instantaneous fields of existing x86 instruction sets with extensions. The diagram illustrates... Figures 18A-18C The fields mapped to from Figures 17A-17B The field.

[0185] It should be understood that although embodiments of the invention are described with reference to a specific vector-friendly instruction format 1800 in the context of the general vector-friendly instruction format 1700 for illustrative purposes, the invention is not limited to the specific vector-friendly instruction format 1800 unless otherwise stated. For example, the general vector-friendly instruction format 1700 envisions various possible sizes for various fields, while the specific vector-friendly instruction format 1800 is shown as a field with a specific size. As a specific example, although the data element width field 1764 is shown as a one-bit field in the specific vector-friendly instruction format 1800, the invention is not limited thereto (that is, the general vector-friendly instruction format 1700 envisions other sizes for the data element width field 1764).

[0186] General Vector Friendly Command Format 1700 includes by Figure 18A The following fields are listed below in the order shown.

[0187] The EVEX prefix (bytes 0-3) 1802- is encoded as a four-byte form.

[0188] Format field 1740 (EVEX byte 0, bits [7:0]) - The first byte (EVEX byte 0) is format field 1740 and it contains 0x62 (a unique value used in one embodiment of the invention to distinguish vector-friendly instruction formats).

[0189] The second to fourth bytes (EVEX bytes 1-3) include several bit fields that provide specific capabilities.

[0190] The REX field 1805 (EVEX byte 1, bits [7-5]) consists of the EVEX.R bit field (EVEX byte 1, bits [7]-R), the EVEX.X bit field (EVEX byte 1, bits [6]-X), and the EVEX.B byte 1, bits [5]-B). The EVEX.R, EVEX.X, and EVEX.B bit fields provide the same functionality as the corresponding VEX bit fields and are encoded using one's complement form, i.e., ZMM0 is encoded as 1111B and ZMM15 is encoded as 0000B. The other fields of the instruction are encoded with the lower three bits of the register index (rrr, xxx, and bbb) as is known in the art, so that Rrrr, Xxxx, and Bbbb can be formed by adding EVEX.R, EVEX.X, and EVEX.B.

[0191] REX' field 1810 - This is the first part of REX' field 1810 and is the EVEX.R' bit field (EVEX byte 1, bit [4] - R') used to encode the high 16 or low 16 of the extended 32 register set. In one embodiment of the invention, this bit, along with the other bits shown below, is stored in bit-inverted format to distinguish it from the BOUND instruction (in the known x86 32-bit mode), whose actual opcode byte is 62, but does not accept the value 11 in the MOD field in the MOD R / M field (described below); an alternative embodiment of the invention does not store this bit and the other bits indicated below in inverted format. The value 1 is used to encode the low 16 registers. In other words, R'Rrrr is formed by combining EVEX.R', EVEX.R, and other RRRs from other fields.

[0192] Opcode mapping field 1815 (EVEX byte 1, bits [3:0]-mmmm) - its contents encode the implied dominant opcode byte (0F, 0F 38, or 0F 3).

[0193] The data element width field 1764 (EVEX byte 2, bits [7]-W) is represented by the symbol EVEX.W. EVEX.W is used to define the granularity (size) of the data type (32-bit data element or 64-bit data element).

[0194] The function of EVEX.vvvv 1820 (EVEX byte 2, bits [6:3] -vvvv) -EVEX.vvvv can include the following: 1) EVEX.vvvv encodes the first source register operand specified in inverted (ones' complement) form, and is valid for instructions with two or more source operands; 2) EVEX.vvvv encodes the destination register operand specified in ones' complement form for certain vector shifts; or 3) EVEX.vvvv does not encode any operands, this field is reserved and should contain 1111b. Thus, the EVEX.vvvv field 1820 encodes the four lower-order bits of the first source register specifier stored in inverted (ones' complement) form. Depending on the instruction, an additional different EVEX bit field is used to extend the specifier size to 32 registers.

[0195] EVEX.U 1768 Category field (EVEX byte 2, bit [2]-U) - If EVEX.U = 0, it indicates category A or EVEX.U0; if EVEX.U = 1, it indicates category B or EVEX.U1.

[0196] The prefix encoding field 1825 (EVEX byte 2, bits [1:0]-pp) provides additional bits for the basic operation field. Besides providing support for legacy SSE instructions using the EVEX prefix format, this also has the benefit of compressing the SIMD prefix (the EVEX prefix requires only 2 bits instead of one byte to represent the SIMD prefix). In one embodiment, to support legacy SSE instructions using SIMD prefixes (66H, F2H, F3H) in both legacy and EVEX prefix formats, these legacy SIMD prefixes are encoded into the SIMD prefix encoding field; and are expanded to the legacy SIMD prefix at runtime before being provided to the decoder's PLA (thus the PLA can execute both legacy and EVEX formats of these legacy instructions without modification). While newer instructions can directly use the contents of the EVEX prefix encoding field as opcode expansion, some embodiments expand in a similar manner for consistency, but allow these legacy SIMD prefixes to specify different meanings. Alternative embodiments may redesign the PLA to support 2-bit SIMD prefix encoding, thus eliminating the need for expansion.

[0197] Alpha field 1752 (EVEX byte 3, bit [7] - EH; also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.WriteMaskControl, and EVEX.N; also illustrated with α) - As previously stated, this field is context-dependent.

[0198] Beta field 1754 (EVEX byte 3, bits [6:4] - SSS; also known as EVEX.S 2-0 EVEX.r 2-0 ,EVEX.rr1,EVEX.LL0,EVEX.LLB; also illustrated with βββ) - As mentioned before, this field is context-dependent.

[0199] REX' field 1810 - This is the remainder of the REX' field and is the EVEX.V' bit field (EVEX byte 3, bit [3] - V') that can be used to encode the high 16 or low 16 of the extended 32 register set. This bit is stored in bit-inverted format. The value 1 is used to encode the low 16 registers. In other words, V'VVVV is formed by combining EVEX.V' and EVEX.vvvv.

[0200] The write mask field 1770 (EVEX byte 3, bits [2:0]-kkk) – its contents specify the index of the register in the write mask register as described above. In one embodiment of the invention, the specific value EVEX.kkk = 000 has a special behavior that implies that no write mask is used for a particular instruction (this can be achieved in various ways, including using a write mask that is hardwired to all one or hardware that bypasses the masking hardware).

[0201] The actual opcode field 1830 (byte 4) is also known as the opcode byte. Part of the opcode is specified in this field.

[0202] The MOD R / M field 1840 (byte 5) includes the MOD field 1842, the Reg field 1844, and the R / M field 1846. As previously mentioned, the content of the MOD field 1842 distinguishes between memory access and non-memory access operations. The function of the Reg field 1844 can be summarized in two cases: encoding the destination register operand or the source register operand, or being treated as an opcode extension and not used to encode any instruction operand. The function of the R / M field 1846 can include: encoding an instruction operand that references a memory address, or encoding the destination register operand or the source register operand.

[0203] Scaling, Index, Base (SIB) bytes (byte 6) - As previously mentioned, the contents of the scaling field 1850 are used for memory address generation. SIB.xxx 1854 and SIB.bbb 1856 - The contents of these fields have been previously mentioned regarding register indices Xxxx and Bbbb.

[0204] Displacement field 1762A (bytes 7-10) - When MOD field 1842 contains 10, bytes 7-10 are displacement field 1762A, and it works in the same way as the traditional 32-bit displacement (disp32) and operates at the byte granularity.

[0205] Byte 7 (Displacement Factor Field 1762B) – When MOD field 1842 contains 0s and 1s, byte 7 is displacement factor field 1762B. This field is located in the same position as the traditional x86 instruction set 8-bit displacement (disp8), which operates at a byte granularity. Because disp8 is sign-extended, it can only be addressed between offsets of -128 and 127 bytes; for a 64-byte cache line, disp8 uses 8 bits, which can be set to only four truly useful values: -128, -64, 0, and 64; since a larger range is often required, disp32 is used; however, disp32 requires 4 bytes. Unlike disp8 and disp32, displacement factor field 1762B is a reinterpretation of disp8; when using displacement factor field 1762B, the actual displacement is determined by multiplying the content of the displacement factor field by the size (N) of the memory operand access. This type of displacement is called disp8*N. This reduces the average instruction length (a single byte is used for displacement, but with a much larger range). This compressed displacement is based on the assumption that the effective displacement is a multiple of the granularity of the memory access, and therefore, redundant low-order bits of the address offset do not need to be encoded. In other words, the displacement factor field 1762B replaces the traditional x86 instruction set 8-bit displacement. Thus, the displacement factor field 1762B is encoded in the same way as the x86 instruction set 8-bit displacement (therefore no change in the ModRM / SIB encoding rules), with the only exception that disp8 is overloaded to disp8*N. In other words, there is no change in the encoding rules or encoding length, only in how the hardware interprets the displacement value (the hardware needs to scale the displacement according to the size of the memory operand to obtain the byte-level address offset). The immediate field 1772 operates as described above.

[0206] Full opcode field

[0207] Figure 18B This is a block diagram illustrating the fields constituting a specific vector-friendly instruction format 1800 for a complete opcode field 1774 according to an embodiment of the present invention. Specifically, the complete opcode field 1774 includes a format field 1740, a basic operation field 1742, and a data element width (W) field 1764. The basic operation field 1742 includes a prefix encoding field 1825, an opcode mapping field 1815, and a real opcode field 1830.

[0208] Register index field

[0209] Figure 18C This is a block diagram illustrating the fields of a specific vector-friendly instruction format 1800 constituting register index field 1744 according to an embodiment of the present invention. Specifically, register index field 1744 includes REX field 1805, REX' field 1810, MODR / M.reg field 1844, MODR / Mr / m field 1846, VVVV field 1820, xxx field 1854, and bbb field 1856.

[0210] Enhance operation fields

[0211] Figure 18D This is a block diagram illustrating the fields constituting a specific vector-friendly instruction format 1800 of the enhanced operation field 1750 according to an embodiment of the present invention. When the category (U) field 1768 contains 0, it represents EVEX.U0 (category A 1768A); when it contains 1, it represents EVEX.U1 (category B 1768B). When U = 0 and the MOD field 1842 contains 11 (indicating no memory access operation), the alpha field 1752 (EVEX byte 3, bits [7]-EH) is interpreted as the rs field 1752A. When the rs field 1752A contains 1 (rounded 1752A.1), the beta field 1754 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the rounding control field 1754A. The rounding control field 1754A includes a one-bit SAE field 1756 and a two-bit rounding operation field 1758. When the rs field 1752A contains 0 (data transformation 1752A.2), the beta field 1754 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the three-bit data transformation field 1754B. When U = 0 and the MOD field 1842 contains 00, 01, or 10 (indicating a memory access operation), the alpha field 1752 (EVEX byte 3, bits [7]-EH) is interpreted as the eviction hint (EH) field 1752B and the beta field 1754 (EVEX byte 3, bits [6:4]-SSS) is interpreted as the three-bit data manipulation field 1754C.

[0212] When U = 1, the alpha field 1752 (EVEX byte 3, bits [7]-EH) is interpreted as the write mask control (Z) field 1752C. When U = 1 and the MOD field 1842 contains 11 (indicating no memory access operation), a portion of the beta field 1754 (EVEX byte 3, bits [4]-S0) is interpreted as the RL field 1757A; when it contains 1 (rounded to 1757A.1), the remainder of the beta field 1754 (EVEX byte 3, bits [6-5]-S0) is interpreted as the RL field 1757A.2-1 The remainder of the beta field 1754 (EVEX byte 3, bits [6-5]-S) is interpreted as the rounding operation field 1759A, while when the RL field 1757A contains 0 (VSIZE 1757.A2), the ... and when the RL field 1757A contains 0 (VSIZE 1757.A2), the remainder of the beta field 1754 (EVEX byte 3, bits [6-5]-S) is interpreted as 2-1 ) is interpreted as the vector length field 1759B (EVEX byte 3, bits [6-5]-L) 1-0 When U=1 and MOD field 1842 contains 00, 01, or 10 (indicating a memory access operation), beta field 1754 (EVEX byte 3, bits [6:4]-SSS) is interpreted as vector length field 1759B (EVEX byte 3, bits [6-5]-L). 1-0 ) and broadcast field 1757B (EVEX byte 3, bit [4]-B).

[0213] Exemplary Register Architecture

[0214] Figure 19 This is a block diagram of a register architecture 1900 according to an embodiment of the present invention. In the illustrated embodiment, there are 32 vector registers 1910, each 512 bits wide; these registers are referred to as zmm0 to zmm31. The lower 256 bits of the lower 16 zmm registers are overwritten on registers ymm0-16. The lower 128 bits of the lower 16 zmm registers (the lower 128 bits of the ymm registers) are overwritten on registers xmm0-15. A specific vector-friendly instruction format 1800 operates on these overwritten register files as shown in the following table.

[0215]

[0216]

[0217] In other words, the vector length field 1759B selects between a maximum length and one or more other shorter lengths, each of which is half the length of the previous length; and no instruction template with the vector length field 1759B operates at the maximum vector length. Additionally, in one embodiment, the Category B instruction template of the specific vector-friendly instruction format 1800 operates on compressed or scalar single / double-precision floating-point data and compressed or scalar integer data. Scalar operations are performed at the lowest-order data element location in the zmm / ymm / xmm registers; higher-order data element locations are either kept the same as before the instruction or zeroed out, depending on the embodiment.

[0218] Write mask register 1915 – In the illustrated embodiment, there are eight write mask registers (k0 to k7), each 64 bits in size. In an alternative embodiment, write mask register 1915 is 16 bits in size. As previously stated, in one embodiment of the invention, vector mask register k0 cannot be used as a write mask; when the encoding that would normally indicate k0 is used as the write mask, it selects the hardwired write mask 0xFFFF, which effectively disables write masking for that instruction.

[0219] General Purpose Registers 1925 - In the illustrated embodiment, there are sixteen 64-bit general purpose registers that, together with the existing x86 addressing modes, are used to address memory operation objects. These registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0220] Scalar Floating-Point Stack Register File (x87 Stack) 1945 (MMX Compact Integer Flat Register File 1950 is a pseudonym thereon) - In the illustrated embodiment, the x87 stack is an octet stack used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using the x87 instruction set extension; while the MMX register is used to perform operations on 64-bit compact integer data, and to hold the operation objects for some operations performed between the MMX and XMM registers.

[0221] Alternative embodiments of the present invention may use wider or narrower registers. Furthermore, alternative embodiments of the present invention may use more, fewer, or different register files and registers.

[0222] Exemplary core architecture, processor, and computer architecture

[0223] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, such core implementations may include: 1) general-purpose ordered cores intended for general-purpose computing; 2) high-performance general-purpose unordered cores intended for general-purpose computing; and 3) dedicated cores primarily intended for graphics and / or scientific (throughput) computing. Different processor implementations may include: 1) CPUs comprising one or more general-purpose ordered cores intended for general-purpose computing and / or one or more general-purpose unordered cores intended for general-purpose computing; and 2) coprocessors comprising one or more dedicated cores primarily intended for graphics and / or scientific (throughput) computing. Such different processors lead to different computer system architectures, which may include: 1) a coprocessor on a separate chip 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 this case, such a coprocessor is sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or a dedicated core); and 4) a system-on-a-chip that may include the described CPU (sometimes referred to as one or more application cores or one or more application processors), the coprocessors described above, and additional functionality on the same die. An exemplary core architecture is described next, followed by a description of exemplary processors and computer architectures.

[0224] Exemplary core architecture

[0225] Ordered and disordered core diagrams

[0226] Figure 20A This is a block diagram illustrating both an exemplary ordered pipeline and an exemplary register renaming, unordered issue / execution pipeline according to an embodiment of the present invention. Figure 20B The diagram illustrates an exemplary embodiment of an ordered architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core, according to embodiments of the present invention. Figures 20A-20B The solid boxes in the diagram illustrate ordered pipelines and ordered kernels, while the optional dashed boxes illustrate register renaming, out-of-order issue / execute pipelines, and kernels. Given that ordered aspects are a subset of out-of-order aspects, the out-of-order aspects will be described.

[0227] exist Figure 20A In the processor pipeline 2000, there are fetch phase 2002, length decoding phase 2004, decoding phase 2006, allocation phase 2008, renaming phase 2010, scheduling (also known as dispatch or issue) phase 2012, register read / memory read phase 2014, execution phase 2016, write-back / memory write phase 2018, exception handling phase 2022, and commit phase 2024.

[0228] Figure 20B The processor core 2090 is shown to include a front-end unit 2030 coupled to an execution engine unit 2050, and both are coupled to a memory unit 2070. The core 2090 can be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. Alternatively, the core 2090 can be a dedicated core, such as a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, and so on.

[0229] Front-end unit 2030 includes branch prediction unit 2032 coupled to instruction cache unit 2034, instruction cache unit 2034 coupled to translation lookaside buffer (TLB) 2036, TLB 2036 coupled to instruction fetch unit 2038, instruction fetch unit 2038 coupled to decoding unit 2040. Decoding unit 2040 (or decoder) decodes instructions and generates one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals as outputs. These micro-operations, microcode entry points, microinstructions, other instructions, or other control signals are decoded from, or otherwise reflect, the original instructions, or are derived from the original instructions. Decoding unit 2040 can be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROM), and so on. In one embodiment, core 2090 includes a microcode ROM or other medium that stores microcode for certain macro instructions (e.g., in decoding unit 2040 or otherwise within front-end unit 2030). Decoding unit 2040 is coupled to rename / allocator unit 2052 in execution engine unit 2050.

[0230] Execution engine unit 2050 includes a rename / allocator unit 2052 coupled to retirement unit 2054 and a set of one or more scheduler units 2056. The scheduler units 2056 represent any number of different schedulers, including reservation stations, central instruction windows, etc. The scheduler units 2056 are coupled to one or more physical register file units 2058. Each of the physical register file units 2058 represents one or more physical register files, which store one or more different data types, such as scalar integers, scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer as the address of the next instruction to be executed), etc. In one embodiment, physical register file unit 2058 includes vector register units, write mask register units, and scalar register units. These register units may provide architectural vector registers, vector mask registers, and general-purpose registers. One or more physical register file units 2058 overlap with retirement unit 2054 to illustrate various ways that can be used to implement register renaming and out-of-order execution (e.g., using one or more reorder buffers and one or more retirement register files; using one or more future files, one or more history buffers, and one or more retirement register files; using register maps and register pools; etc.). Retirement unit 2054 and one or more physical register file units 2058 are coupled to one or more execution clusters 2060. One or more execution clusters 2060 include a set of one or more execution units 2062 and a set of one or more memory access units 2064. Execution units 2062 can perform various operations (e.g., shift, addition, subtraction, multiplication) on various types of data (e.g., scalar floating-point, compressed integer, compressed floating-point, vector integer, vector floating-point). While some embodiments may include several execution units dedicated to a particular function or set of functions, other embodiments may include only one execution unit or multiple execution units that perform all functions. One or more scheduler units 2056, one or more physical register file units 2058, and one or more execution clusters 2060 are shown as possibly multiple, because some embodiments create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / compacted integer / compacted floating-point / vector integer / vector floating-point pipelines and / or memory access pipelines, each having its own scheduler unit, physical register file unit, and / or execution cluster - and in the case of separate memory access pipelines, some embodiments are implemented in which only the execution cluster of this pipeline has one or more memory access units 2064).It should also be understood that, in the case of using separate pipelines, one or more of these pipelines may be issued / executed out of order, while the rest are ordered.

[0231] A set of memory access units 2064 is coupled to memory unit 2070, which includes a data TLB unit 2072. The data TLB unit 2072 is coupled to data cache unit 2074, and the data cache unit 2074 is coupled to level 2 (L2) cache unit 2076. In one exemplary embodiment, memory access unit 2064 may include a load unit, a memory address unit, and a memory data unit, each of which is coupled to the data TLB unit 2072 in memory unit 2070. Instruction cache unit 2034 is further coupled to the level 2 (L2) cache unit 2076 in memory unit 2070. The L2 cache unit 2076 is coupled to one or more other levels of cache and ultimately to main memory.

[0232] As an example, the exemplary register renaming, out-of-order issue / execution core architecture can implement pipeline 2000 as follows: 1) Instruction fetch 2038 executes fetch and length decoding phases 2002 and 2004; 2) Decoding unit 2040 executes decoding phase 2006; 3) Rename / allocator unit 2052 executes allocation phase 2008 and rename phase 2010; 4) (one or more) scheduler unit 2056 executes scheduling phase 2012; 5) (one or more) physical register file unit 2058 and memory unit 2070 execute register read / memory read phase 2014; execution cluster 2060 executes execution phase 2016; 6) memory unit 2070 and (one or more) physical register file unit 2058 execute write-back / memory write phase 2018; 7) Various units may be involved in exception handling phase 2022; and 8) retirement unit 2054 and (one or more) physical register file unit 2058 execute commit phase 2024.

[0233] Core 2090 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added with newer versions); the MIPS instruction set of MIPS Technologies, Inc., Sunnyvale, California; the ARM instruction set of ARM Holdings, Inc., Sunnyvale, California (with optional additional extensions, such as NEON)), including one or more of the instructions described herein. In one embodiment, core 2090 includes logic to support compressed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using compressed data.

[0234] It should be understood that the core can support multithreaded processing (two or more parallel sets of operations or threads), and can support multithreaded processing in various ways, including time-sliced ​​multithreaded processing, concurrent multithreaded processing (where a single physical core provides a logical core for each thread of concurrent multithreaded processing on that physical core), or a combination of these (e.g., time-sliced ​​fetching and decoding, followed by concurrent multithreaded processing, such as...). (as in Hyperthreading technology).

[0235] Although register renaming is described in an out-of-order execution context, it should be understood that register renaming can be used in ordered architectures. While the illustrated embodiment of the processor also includes separate instruction and data cache units 2034 / 2074 and a shared L2 cache unit 2076, alternative embodiments may have a single internal cache for both instructions and data, such as a Level 1 (L1) internal cache or multiple levels of internal caches. In some embodiments, the system may include a combination of internal caches and external caches located outside the core and / or processor. Alternatively, all caches may be located outside the core and / or processor.

[0236] Specific exemplary ordered core architecture

[0237] Figures 21A-21B The diagram illustrates a more specific exemplary ordered core architecture, which will be one of several logic blocks (including other cores of the same and / or different types) in the chip. The logic blocks communicate with certain fixed-function logic, memory I / O interfaces, and other necessary I / O logic via a high-bandwidth interconnect network (e.g., a ring network), depending on the application.

[0238] Figure 21A This is a block diagram of a single processor core according to an embodiment of the invention, its connection to an on-chip interconnect network 2102, and its local subset 2104 of the Level 2 (L2) cache. In one embodiment, the instruction decoder 2100 supports the x86 instruction set with a compact data instruction set extension. The L1 cache 2106 allows low-latency access to cache memory in scalar and vector units. Although in one embodiment (for design simplification), scalar units 2108 and vector units 2110 use separate sets of registers (scalar register 2112 and vector register 2114, respectively), and data transferred between them is written to memory and then read back from the Level 1 (L1) cache 2106, alternative embodiments of the invention may use different schemes (e.g., using a single set of registers or including a communication path that allows data to be transferred between two register files without being written and read back).

[0239] The local subset 2104 of the L2 cache is part of the global L2 cache, which is divided into separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset 2104 of the L2 cache. Data read by a processor core is stored in its L2 cache subset 2104 and can be accessed quickly, with these accesses occurring in parallel with other processor cores accessing their own local subsets of the L2 cache. Data written by a processor core is stored in its own L2 cache subset 2104 and can be flushed from other subsets as needed. The ring network ensures the consistency of shared data. The ring network is bidirectional to allow agents such as processor cores, L2 caches, and other logical blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0240] Figure 21B This is according to an embodiment of the present invention. Figure 21A An expanded view of a portion of the processor core. Figure 21B This includes the L1 data cache 2106A portion of L1 cache 2104, and further details regarding vector unit 2110 and vector register 2114. Specifically, vector unit 2110 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 2128) that executes one or more of integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports allocation of register inputs using allocation unit 2120, numerical conversions using value conversion units 2122A-B, and copying of memory inputs using copy unit 2124. Write mask register 2126 allows assertion result vector writing.

[0241] Figure 22 This is a block diagram of a processor 2200 according to an embodiment of the present invention. The processor 2200 may have more than one core, may have an integrated memory controller, and may have integrated graphics. Figure 22 The solid box in the figure illustrates a processor 2200 having a single core 2202A, a system agent 2210, and a group of one or more bus controller units 2216, while the optional addition of the dashed box illustrates an alternative processor 2200 having multiple cores 2202A-N, a group of one or more integrated memory control units 2214 in the system agent units 2210, and dedicated logic 2208.

[0242] Therefore, different implementations of processor 2200 may include: 1) a CPU in which dedicated logic 2208 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores) and cores 2202A-N are one or more general-purpose cores (e.g., general-purpose ordered cores, general-purpose unordered cores, or a combination of both); 2) a coprocessor in which cores 2202A-N are a large number of dedicated cores primarily intended for graphics and / or scientific (throughput); and 3) a coprocessor in which cores 2202A-N are a large number of general-purpose ordered cores. Thus, processor 2200 can be a general-purpose processor, coprocessor, or dedicated processor, such as a network or communication processor, compression engine, graphics processor, GPGPU (General-Purpose Graphics Processing Unit), high-throughput many-integrated-core (MIC) coprocessor (including 30 or more cores), embedded processor, etc. The processor may be implemented on one or more chips. Processor 2200 may be part of one or more substrates and / or may be implemented on one or more substrates using any of several process technologies, such as BiCMOS, CMOS, or NMOS.

[0243] The memory hierarchy includes one or more levels of cache within the core, a set or one or more shared cache units 2206, and external memory (not shown) coupled to the set of integrated memory controller units 2214. The set of shared cache units 2206 may include one or more intermediate level caches (e.g., level 2 (L2), level 3 (L3), level 4 (4), or other levels of cache), a last level cache (LLC), and / or combinations thereof. While in one embodiment the integrated graphics logic 2208, the set of shared cache units 2206, and the system proxy units 2210 / (one or more) integrated memory controller units 2214 are interconnected using ring-based interconnect units 2212, alternative embodiments may use any number of known techniques to interconnect such units. In one embodiment, consistency is maintained between one or more cache units 2206 and the cores 2202A-N.

[0244] In some embodiments, one or more of the cores 2202A-N are capable of multithreaded processing. System agent 2210 includes those components that coordinate and operate the cores 2202A-N. System agent unit 2210 may include, for example, a power control unit (PCU) and a display unit. The PCU may be, or may include, the logic and components required to regulate the power state of the cores 2202A-N and the integrated graphics logic 2208. The display unit is used to drive one or more externally connected displays.

[0245] The 2202A-N cores can be homogeneous or heterogeneous in terms of their instruction sets; that is, two or more cores in the 2202A-N cores can execute the same instruction set, while other cores can execute only a subset of that instruction set or a different instruction set.

[0246] Exemplary computer architecture

[0247] Figures 23-24 This is a block diagram of an exemplary computer architecture. Other system designs and configurations known in the art for laptops, desktop computers, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, 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 are also suitable. In summary, a wide variety of systems or electronic devices capable of incorporating the processors and / or other execution logic disclosed herein are generally suitable.

[0248] Now for reference Figure 23 A block diagram of a system 2300 according to an embodiment of the present invention is shown. System 2300 may include one or more processors 2310, 2315 coupled to a controller hub 2320. In one embodiment, controller hub 2320 includes a graphics memory controller hub (GMCH) 2390 and an input / output hub (IOH) 2350 (which may be on separate chips); GMCH 2390 includes a memory and a graphics controller coupled to a memory 2340 and a coprocessor 2345; IOH 2350 couples an input / output (I / O) device 2360 to GMCH 2390. Alternatively, one or both of the memory and the graphics controller are integrated within the processor (as described herein), memory 2340 and coprocessor 2345 are directly coupled to processor 2310, and controller hub 2320 and IOH 2350 are on a single chip.

[0249] The option of an additional 2315 processor is available. Figure 23 The text is represented by dashed lines. Each processor 2310, 2315 may include one or more of the processing cores described herein and may be a version of processor 2200.

[0250] The memory 2340 may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of both. In at least one embodiment, the controller hub 2320 communicates with one or more processors 2310, 2315 via a multi-point branch bus (e.g., frontside bus, FSB), a point-to-point interface (e.g., QuickPath Interconnect, QPI), or a similar connection 2395.

[0251] In one embodiment, the coprocessor 2345 is a dedicated processor, such as a high-throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, and so on. In one embodiment, the controller hub 2320 may include an integrated graphics accelerator.

[0252] Between physical resources 2310 and 2315, there can be various differences in the range of value metrics, including architectural characteristics, microarchitectural characteristics, thermal characteristics, power consumption characteristics, and so on.

[0253] In one embodiment, processor 2310 executes instructions that control general-type data processing operations. Embedded within these instructions may be coprocessor instructions. Processor 2310 identifies these coprocessor instructions as types that should be executed by an attached coprocessor 2345. Therefore, processor 2310 issues these coprocessor instructions (or control signals representing coprocessor instructions) to coprocessor 2345 on a coprocessor bus or other interconnect. One or more coprocessors 2345 receive and execute the received coprocessor instructions.

[0254] Now for reference Figure 24 A block diagram of a SoC 2400 according to an embodiment of the present invention is shown. Figure 22 Similar elements in the text are labeled with similar numbers. Additionally, dashed boxes are an optional feature on more advanced SoCs. Figure 24In this embodiment, one or more interconnect units 2402 are coupled to: an application processor 2410, which includes a set of one or more cores 202A-N and one or more shared cache units 2206; a system proxy unit 2210; one or more bus controller units 2216; one or more integrated memory controller units 2214; a set of one or more coprocessors 2420, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 2430; a direct memory access (DMA) unit 2432; and a display unit 2440 for coupling to one or more external displays. In one embodiment, one or more coprocessors 2420 include a dedicated processor, such as a network or communication processor, a compression engine, a GPGPU, a high-throughput MIC processor, an embedded processor, etc.

[0255] Embodiments of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the invention can be implemented as computer programs or program code that execute 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.

[0256] Program code can be applied to input instructions 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, the processing system includes any system having a processor, such as a digital signal processor (DSP), microcontroller, application-specific integrated circuit (ASIC), or microprocessor.

[0257] The program code can be implemented using high-level procedural or object-oriented programming languages ​​to communicate with the processing system. If desired, the program code can also be implemented using assembly or machine language. In fact, the mechanisms described in this article are not limited to any particular programming language. In any case, the language can be a compiled or interpreted language.

[0258] One or more aspects of at least one embodiment may be implemented by representative instructions representing various logics within a processor, stored on a machine-readable medium, which, when read by a machine, cause the machine-made logic to perform the techniques described herein. This representation, referred to as an "IP core," may be stored on a tangible machine-readable medium and provided to various customer or manufacturing facilities for loading into the manufacturing machine that actually manufactures the logic or processor.

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

[0260] Therefore, embodiments of the present invention also include a non-transitory tangible machine-readable medium containing instructions or design data, such as a Hardware Description Language (HDL), that defines the features of the structures, circuits, devices, processors, and / or systems described herein. Such embodiments may also be referred to as program products.

[0261] Simulation (including binary conversion, code transformation, etc.)

[0262] In some cases, instruction translators can be used to translate instructions from a source instruction set to a target instruction set. For example, an instruction translator can transform (e.g., using static binary translation, including dynamic binary translation with dynamic compilation), morph, emulate, or otherwise translate instructions into one or more other instructions to be processed by the kernel. Instruction translators can be implemented in software, hardware, firmware, or a combination thereof. Instruction translators can be on the processor, off-processor, or partially on-processor and partially off-processor.

[0263] Figure 25 This is a block diagram comparing an embodiment of the invention with the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set. In the illustrated embodiment, the instruction converter is a software instruction converter, although alternatively, the instruction converter can be implemented using software, firmware, hardware, or various combinations thereof. Figure 25 A program of high-level language 2502 is shown to be compiled by x86 compiler 2504 to generate x86 binary code 2506, which can be natively executed by a processor having at least one x86 instruction set core 2516. A processor having at least one x86 instruction set core 2516 means any processor that can perform substantially the same function as an Intel processor having at least one x86 instruction set core by compatiblely executing or otherwise processing (1) a substantial portion of the instruction set of an Intel x86 instruction set core or (2) a version of object code for an application or other software targeted to run on an Intel processor having at least one x86 instruction set core, so as to achieve substantially the same result as an Intel processor having at least one x86 instruction set core. x86 compiler 2504 means a compiler operable to generate x86 binary code 2506 (e.g., object code), which can be executed on a processor 2516 having at least one x86 instruction set core with or without additional linking processing. Similarly, Figure 25A program in high-level language 2502 is shown to be compiled using a replacement instruction set compiler 2508 to generate replacement instruction set binary code 2510, which can be natively executed by a processor 2514 without at least one x86 instruction set core (e.g., a processor with a core executing the MIPS instruction set of MIPS Technologies, Inc., .C., and / or the ARM instruction set of ARM Holdings, Inc., .C., .C., .C., .C., .Instruction converter 2512 is used to translate x86 binary code 2506 into code that can be natively executed by a processor 2514 without an x86 instruction set core. This translated code is unlikely to be identical to the replacement instruction set binary code 2510, as an instruction converter capable of doing so would be difficult to manufacture; however, the translated code will implement general operations and consist of instructions from the replacement instruction set. Thus, instruction converter 2512 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device without an x86 instruction set processor or core to execute x86 binary code 2506 through emulation, simulation, or any other process.

[0264] Logic used to adjust the refresh rate of the display device

[0265] Now for reference Figure 26 This diagram illustrates a block diagram of a system 2600 according to one or more embodiments. In some embodiments, system 2600 may be all or part of an electronic device or component. For example, system 2600 may be a cellular phone, computer, server, network device, system-on-a-chip (SoC), controller, wireless transceiver, wearable device, etc. Furthermore, in some embodiments, system 2600 may be part of a group of associated or interconnected devices, such as a data center, computing cluster, etc.

[0266] like Figure 26 As shown, system 2600 may include computing device 2610 coupled to one or more input devices 2640 and display devices 2650. Additionally, although in Figure 26 Not shown, but system 2600 may include other components. One or more input devices 2640 may allow a user to provide input to computing device 2610 (e.g., keyboard, computer mouse, joystick, touchscreen, voice interface, gesture interface, etc.). Display device 2650 may be a device capable of displaying video and other image content (e.g., monitor, television, projector, etc.). As shown, in some embodiments, one or more input devices 2640 and display device 2650 may be external to computing device 2610. However, in other embodiments, one or more input devices 2640 and / or display device 2650 may be included within computing device 2610.

[0267] In one or more embodiments, computing device 2610 may include one or more processors 2620 and memory 2630. Memory 2630 may be implemented using any type(s) of computer memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM), non-volatile memory (NVM), a combination of DRAM and NVM, etc.). Processor 2620 may be a hardware processing device (e.g., central processing unit (CPU), system-on-a-chip (SoC), etc.).

[0268] In one or more embodiments, memory 2630 may include adaptive refresh logic 2635 to dynamically adjust the refresh rate of display device 2650. For example, adaptive refresh logic 2635 may reduce the refresh rate of display device 2650 when it is detected that input device(s)(s) has not received any user input for at least a minimum time period. Additionally, adaptive refresh logic 2635 may reduce the refresh rate when it is detected that the updated portion of a frame displayed on display device 2650 is below a minimum size. Furthermore, adaptive refresh logic 2635 may reduce the refresh rate when it is detected that the rate at which the displayed frame is updated is less than the refresh rate. Reference is made below. Figure 27-33 Further describe the functionality of the adaptive refresh logic 2635.

[0269] In some embodiments, the adaptive refresh logic 2635 may be implemented as software instructions (e.g., executable by one or more processors 2620). For example, the adaptive refresh logic 2635 may be implemented in the operating system of the computing device 2610. However, embodiments are not limited in this respect. For example, in some embodiments, the adaptive refresh logic 2635 may be implemented in other software (e.g., graphics driver, application), hardware (e.g., processor 2620, computing device 2610, display device 2650, display engine, graphics processor, external device), etc.

[0270] Now for reference Figure 27 A flowchart of a method 2700 according to one or more embodiments is shown. In various embodiments, method 2700 may be executed by processing logic, which may include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions running on the processing device), or a combination thereof. In some implementations, method 2700 may utilize... Figure 26One or more components shown (e.g., adaptive refresh logic 2635, processor(s) 2620, etc.) are used to execute the method. In firmware or software embodiments, method 2700 may be implemented by computer-executable instructions stored in a non-transitory machine-readable medium (e.g., optical, semiconductor, or magnetic storage device). For illustrative purposes, reference may be made below. Figure 26 and Figure 28 To describe the actions involved in method 2700, Figure 26 and Figure 28 Examples according to one or more embodiments are shown. However, the scope of the various embodiments discussed herein is not limited in this respect.

[0271] Box 2710 may include determining the time elapsed since the last user interaction. For example, refer to... Figure 26 The adaptive refresh logic 2635 can determine the time elapsed since the last input (e.g., keyboard input, mouse movement, voice command, etc.) received via one or more input devices 2640. In one or more embodiments, the adaptive refresh logic 2635 may be implemented in the operating system of the computing device 2610.

[0272] Box 2720 may include determining the size of the updated region in the frame. For example, refer to Figure 26 The adaptive refresh logic 2635 can determine the size of an image region or portion on the display device 2650 that is being changed between frames. In one or more embodiments, the size of the updated region can be defined as an absolute value (e.g., 10 by 20 pixels) or a relative proportion (e.g., 25 percent, a quarter, 0.25, etc.).

[0273] Box 2730 may include determining the uniform frequency of screen updates. For example, refer to Figure 26 The adaptive refresh logic 2635 can determine a uniform frequency (i.e., repeated at the same interval) at which the frames displayed on the display device 2650 are modified to include new image content.

[0274] Diamond 2740 may include determining whether the time elapsed since the last user interaction exceeds a time threshold. For example, refer to... Figure 26The adaptive refresh logic 2635 determines whether the time elapsed since the last input received via one or more input devices 2640 is greater than a stored time threshold (e.g., 100 milliseconds). If it is determined at diamond 2740 that the time elapsed since the last user interaction does not exceed the time threshold, method 2700 continues at diamond 2780 (as described below). However, if it is determined at diamond 2740 that the elapsed time exceeds the time threshold, method 2700 continues at diamond 2750.

[0275] The rhombus 2750 may include determining whether the size of the updated region is below a size threshold. In some embodiments, the size threshold may be specified as a percentage of the full frame size. For example, refer to Figure 26 The adaptive refresh logic 2635 determines whether the portion of the displayed image that is updated between frames is smaller than a size threshold (e.g., a defined percentage). If it is determined at rhombus 2750 that the size of the updated region is less than the size threshold, then method 2700 continues at rhombus 2770 (as described below). However, if it is determined at rhombus 2750 that the size of the updated region is not less than the size threshold, then method 2700 continues at rhombus 2760.

[0276] Diamond 2760 may include determining whether the uniform frequency of screen updates is lower than the current refresh rate. For example, refer to Figure 26 The adaptive refresh logic 2635 can determine that the display frame is being updated at a uniform rate lower than the current refresh rate of the display device 2650.

[0277] If it is determined at diamond 2760 that the uniform frequency of screen updates is lower than the current refresh rate, or if it is determined at diamond 2750 that the size of the updated area is lower than a size threshold, then at diamond 2770, it is determined whether the display device is currently at the target reduced refresh rate. If it is determined at diamond 2770 that the display device is not currently at the target reduced refresh rate, then at box 2775, the refresh rate is set to the target reduced refresh rate. After setting the target reduced refresh rate, method 2700 returns to box 2710 (i.e., repeatedly determining the time elapsed since the last user interaction). However, if it is determined at diamond 2770 that the display device is currently at the target reduced refresh rate, method 2700 returns to box 2710 without changing the refresh rate.

[0278] Note that, as shown in boxes / diamonds 2740-2775, the refresh rate can be reduced when it is determined that the elapsed time of the last input is greater than the time threshold and the update area size is lower than the size threshold, or when it is determined that the elapsed time of the last input is greater than the time threshold and the uniform update frequency is lower than the refresh rate.

[0279] Now for reference Figure 28A timeline diagram 2800 is shown according to one or more embodiments. Specifically, timeline diagram 2800 illustrates the occurrence of graphical breaks 2810 at various points in time (increasing from left to right). Figure 28 As shown in the leftmost portion, interrupt 2810 is initially split into first cycles 2820, which correspond to the default refresh rate (e.g., 60Hz). In some embodiments, interrupt 2810 may be a Vertical Blank Interval (VBI) interrupt.

[0280] Suppose event 2830 describes the time point in some embodiments where the monitored conditions lead to a decrease in the refresh rate. For example, event 2830 could describe a determination that the elapsed time of the last input is greater than a time threshold and the update region size is less than a size threshold, or a determination that the elapsed time of the last input is greater than a time threshold and the uniform update frequency is less than the refresh rate (i.e., in...). Figure 27 (As shown in boxes / diamonds 2740-2775). Therefore, after event 2830, interrupt 2810 is separated into a second cycle 2840 corresponding to the reduced refresh rate (e.g., 30Hz). Note that the number of interrupts is reduced when a reduced refresh rate is used. Therefore, some embodiments can reduce power consumption associated with video processing.

[0281] Refer again Figure 27 If, at diamond 2740, it is determined that the elapsed time since the last user interaction does not exceed a time threshold, or if, at diamond 2760, it is determined that the uniform frequency of screen updates is not lower than the current refresh rate, then at diamond 2780, it is determined whether the display device is currently at the default refresh rate. If, at diamond 2780, it is determined that the display device is not currently at the default refresh rate, then at box 2785, the refresh rate is set to the default refresh rate. After setting the default reduced rate, method 2700 returns to box 2710. However, if, at diamond 2780, it is determined that the display device is currently at the default refresh rate, then method 2700 returns to box 2710 without changing the refresh rate.

[0282] Note that after reducing the refresh rate (as discussed in reference boxes / diamonds 2740-2775 above), the refresh rate can be returned to the default refresh rate when it is determined that the time period since the user input (e.g., user input after the refresh rate reduction) is no greater than a time threshold, or when it is determined that the update area size is no less than a size threshold and the uniform update frequency is no less than the refresh rate.

[0283] Refer again Figure 28Event 2850 describes the time point in some embodiments where the monitored conditions lead to an increase in the refresh rate. For example, event 2850 might describe a determination that the elapsed time since the last input is no greater than a time threshold, or a determination that the updated region size is no less than a size threshold and the uniform update frequency is no less than the refresh rate (i.e., in...). Figure 27 (As shown in boxes / diamonds 2740-2785). Therefore, after event 2850, interrupt 2810 is again separated by the first cycle 2820 corresponding to the default refresh rate (e.g., 60Hz).

[0284] Refer again Figure 27 In some embodiments, method 2700 may be repeated cyclically to continuously monitor the elapsed time of the last input, the update region size, and the uniform update frequency, and adjust the refresh rate upward and downward based on these monitored parameters. Additionally, in some embodiments, method 2700 may be performed with multiple levels of refresh rate reduction. For example, rhombuses 2740-2750 may be evaluated at multiple levels of time / size thresholds, such that a certainty at each level results in setting the refresh rate to an increasingly lower refresh rate. In such an example, the refresh rate may be reduced downward in multiple steps, corresponding to increasingly larger time thresholds and / or increasingly smaller size thresholds. Furthermore, rhombus 2760 may be evaluated at multiple levels corresponding to multiple reductions in the refresh rate.

[0285] Now for reference Figure 29 A flowchart of method 2900 according to one or more embodiments is shown. Block 2910 may include presenting a plurality of video frames on a display device by a computing device. Block 2920 may include determining a time period since the last interaction between the user and the input device by adaptive refresh logic of the computing device. For example, refer to Figure 26 When a video image is presented on display device 2650, adaptive refresh logic 2635 can determine the time elapsed since the last input received via input device (one or more) 2640.

[0286] Block 2930 may include adaptive refresh logic determining whether the time period since the last user interaction exceeds a time threshold. Block 2940 may include, in response to determining that the time period since the last user interaction exceeds the time threshold, the adaptive refresh logic causing the display device to operate at a reduced refresh rate. For example, refer to... Figure 26 The adaptive refresh logic 2635 can determine that the time elapsed since the last input received via one or more input devices 2640 is greater than a stored time threshold, and in response, can reduce the refresh rate of the display device 2650. In some embodiments, the adaptive refresh logic can be implemented in the operating system of the computing device. After block 2940, method 2900 is completed.

[0287] Now for reference Figure 30 The diagram illustrates a flowchart of method 3000 according to one or more embodiments. Block 3010 may include presenting a plurality of video frames on a display device. Block 3020 may include determining whether a time period since the last user interaction exceeds a time threshold. Block 3030 may include determining whether the update region size of a video frame is below a size threshold. Block 3040 may include causing the display device to operate at a reduced refresh rate in response to determining that the time period since the last user interaction exceeds the time threshold and the update region size is below the size threshold. After block 3040, method 3000 completes.

[0288] Now for reference Figure 31 A flowchart of method 3100 according to one or more embodiments is shown. Block 3110 may include presenting a plurality of video frames on a display device at a first refresh rate. Block 3120 may include determining whether a time period since the last user input exceeds a time threshold. Block 3130 may include determining whether the update frequency of the video frames is lower than the first refresh rate. Block 3040 may include causing the display device to operate at a reduced refresh rate in response to determining that the time period since the last user interaction exceeds the time threshold and the update frequency of the video frames is lower than the first refresh rate. After block 3140, method 3100 is completed.

[0289] In various embodiments, methods 2900, 3000, and / or 3100 may be executed by processing logic, which may include hardware (e.g., processing devices, circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions running on a processing device), or a combination thereof. In some implementations, methods 2900, 3000, and / or 3100 may utilize... Figure 26 One or more components shown (e.g., adaptive refresh logic 2635, processor(s) 2620, operating system 2632, etc.) are executed. In firmware or software embodiments, methods 2900, 3000, and / or 3100 may be implemented by computer-executable instructions stored in a non-transitory machine-readable medium (e.g., optical, semiconductor, or magnetic storage devices). For illustrative purposes, see reference to Figures 26-28 To describe the actions involved in methods 2900, 3000, and / or 3100, Figures 26-28 Examples according to one or more embodiments are shown. However, the scope of the various embodiments discussed herein is not limited in this respect.

[0290] Now for reference Figure 32 A schematic diagram of an example computing device 3200 is shown. In some examples, computing device 3200 may generally correspond to Figure 26 The computing device 2610 shown is illustrated. As shown, the computing device 3200 may include a user input device 3201, a display device 3203, one or more hardware processors 3202, and a machine-readable storage medium 3206. The machine-readable storage medium 3206 may be a non-transitory medium and may store instructions 3210-3230. Instructions 3210-3230 may be executed by one or more hardware processors 3202.

[0291] Instruction 3210 can be executed to monitor the user input device while video frames are rendered on the display device at a refresh rate at a first level. Instruction 3220 can be executed to determine that a time period since the last user interaction with the user input device exceeds a time threshold. Instruction 3230 can be executed to reduce the refresh rate of the display device to a second level in response to determining that the time period since the last user interaction exceeds the time threshold. In some embodiments, the first level of refresh rate is at least twice the second level of refresh rate. In some embodiments, the last user interaction was user input using an input device (e.g., keyboard, mouse, touchpad, touchscreen, etc.).

[0292] Now for reference Figure 33 This illustrates a machine-readable storage medium 3300 with storage instructions 3310-3130 according to some implementations. Instructions 3310-3130 can be processed by any number of processors (e.g., Figure 26 The processor(s) 2620(s) shown execute the data. The machine-readable storage medium 3300 can be any non-transitory computer-readable medium, such as optical, semiconductor, or magnetic storage devices.

[0293] Instruction 3310 can be executed to render multiple video frames on the display device. Instruction 3320 can be executed to determine whether the time period since the last user interaction with the input device exceeds a time threshold. Instruction 3330 can be executed to cause the display device to operate at a reduced refresh rate in response to determining that the time period since the last user interaction exceeds the time threshold.

[0294] The following terms and / or examples are further embodiments.

[0295] In Example 1, a computing device for reducing refresh rate includes a processor and a machine-readable storage medium storing instructions. The instructions can be executed by the hardware processor to: monitor a user input device while video frames are being presented on a display device at a first refresh rate; determine whether a time period since the last user interaction with the user input device exceeds a time threshold; and reduce the refresh rate of the display device to a second level in response to determining that the time period since the last user interaction exceeds the time threshold.

[0296] In Example 2, the subject of Example 1 may optionally include instructions executable to return the refresh rate of the display device to the first level in response to determining that the time period since user interaction is below the time threshold.

[0297] In Example 3, the subject matter of Examples 1-2 may optionally include instructions executable to determine whether the update region size of a video frame is below a size threshold; and to reduce the refresh rate of the display device in response to: determining that the time period since the last user interaction exceeds the time threshold; and determining that the update region size of the video frame is below the size threshold.

[0298] In Example 4, the subject matter of Examples 1-3 may optionally include instructions executable to return the refresh rate of the display device to the first level in response to determining that the update region size of the video frame is not less than the size threshold.

[0299] In Example 5, the subject matter of Examples 1-4 may optionally include instructions executable to determine whether the update frequency of the video frame is lower than the refresh rate; and to reduce the refresh rate of the display device in response to: determining that the time period since the last user interaction exceeds the time threshold; and determining that the update frequency of the video frame is lower than the refresh rate.

[0300] In Example 6, the subject matter of Examples 1-5 may optionally include instructions executable to return the refresh rate of the display device to the first level in response to determining that the update frequency of the video frames is not lower than the refresh rate.

[0301] In Example 7, the subject of Examples 1-6 may optionally include the size threshold being specified as a specific percentage of the full frame size.

[0302] In Example 8, the subject of Examples 1-7 may optionally include the last user interaction including user input using an input device.

[0303] In Example 9, a method for reducing the refresh rate may include: presenting a plurality of video frames on a display device by a computing device; determining a time period since the last user interaction with an input device by adaptive refresh logic of the computing device; determining by the adaptive refresh logic whether the time period since the last user interaction exceeds a time threshold; and, in response to determining that the time period since the last user interaction exceeds the time threshold, causing the display device to operate at a reduced refresh rate by the adaptive refresh logic.

[0304] In Example 10, the subject of Example 9 may optionally include, after causing the display device to operate at a reduced refresh rate: determining that the time period since the last user interaction is lower than the time threshold; and in response to determining that the time period since the last user interaction is lower than the time threshold, causing the display device to operate at a default refresh rate, wherein the default refresh rate is higher than the reduced refresh rate.

[0305] In Example 11, the subject matter of Examples 9-10 may optionally include determining whether the update region size of a video frame is below a size threshold; and causing the display device to operate at a reduced refresh rate in response to: determining that the time period since the last user interaction exceeds the time threshold; and determining that the update region size of the video frame is below the size threshold.

[0306] In Example 12, the subject matter of Examples 9-11 may optionally include, after causing the display device to operate at a reduced refresh rate, causing the display device to operate at a default refresh rate in response to determining that the update region size of the video frame is not less than the size threshold.

[0307] In Example 13, the subject matter of Examples 9-12 may optionally include determining whether the update frequency of the video frame is lower than the refresh rate; and causing the display device to operate at a reduced refresh rate in response to: determining that the time period since the last user interaction exceeds the time threshold; and determining that the update frequency of the video frame is lower than the refresh rate.

[0308] In Example 14, the subject matter of Examples 9-13 may optionally include, after causing the display device to operate at a reduced refresh rate, causing the display device to operate at a default refresh rate in response to determining that the update frequency of the video frames is not lower than the refresh rate.

[0309] In Example 15, the subject matter of Examples 9-14 may optionally include: the adaptive refresh logic is implemented in the operating system of the computing device.

[0310] In Example 16, a computing device for reducing refresh rates may include: one or more processors; and a memory storing a plurality of instructions that, when executed by the one or more processors, cause the computing device to perform the method described in any of Examples 9 to 15.

[0311] In Example 17, at least one machine-readable medium may store data thereon, which, if used by at least one machine, causes the at least one machine to perform the method described in any of Examples 9 to 15.

[0312] In Example 18, an electronic device includes means for performing the method described in any one of Examples 9 to 15.

[0313] In Example 19, an article includes a non-transitory machine-readable storage medium storing instructions for reducing the refresh rate, the instructions, when executed, causing a processor to: present a plurality of video frames on a display device; determine whether a time period since the last user interaction with an input device exceeds a time threshold; and in response to determining that the time period since the last user interaction exceeds the time threshold, cause the display device to operate at a reduced refresh rate.

[0314] In Example 20, the subject of Example 19 may optionally include instructions executable to return the refresh rate of the display device to a default level in response to determining that the time period since user interaction is below the time threshold, wherein the default refresh rate is higher than the reduced refresh rate.

[0315] In Example 21, the subject matter of Examples 19-20 may optionally include instructions executable to: determine whether the update region size of a video frame is below a size threshold; and reduce the refresh rate of the display device in response to: determining that the time period since the last user interaction exceeds the time threshold; and determining that the update region size of the video frame is below the size threshold.

[0316] In Example 22, the subject matter of Examples 19-21 may optionally include instructions executable to: determine whether the update frequency of the video frames is lower than the refresh rate; and reduce the refresh rate of the display device in response to: determining that the time period since the last user interaction exceeds the time threshold; and determining that the update frequency of the video frames is lower than the refresh rate.

[0317] In Example 23, the subject of Examples 19-22 may optionally include the size threshold as a specific percentage of the full frame size.

[0318] In Example 24, an apparatus for reducing refresh rate includes: means for presenting a plurality of video frames on a display device; means for determining a time period since the last user interaction with an input device; means for determining whether the time period since the last user interaction exceeds a time threshold; and means for causing the display device to operate at a reduced refresh rate in response to determining that the time period since the last user interaction exceeds the time threshold.

[0319] In Example 25, the subject of Example 24 may optionally include means for performing the following: after causing the display device to operate at a reduced refresh rate: determining that the time period since the last user interaction is below the time threshold; and in response to determining that the time period since the last user interaction is below the time threshold, causing the display device to operate at a default refresh rate, wherein the default refresh rate is higher than the reduced refresh rate.

[0320] In Example 26, the subject matter of Examples 24-25 may optionally include means for determining whether the update region size of a video frame is below a size threshold; and means for causing the display device to operate at a reduced refresh rate in response to: determining that the time period since the last user interaction exceeds the time threshold; and determining that the update region size of the video frame is below the size threshold.

[0321] In Example 27, the subject matter of Examples 24-26 may optionally include: means for causing the display device to operate at a default refresh rate in response to determining that the size of the updated region of the video frame is not less than the size threshold after causing the display device to operate at a reduced refresh rate.

[0322] In Example 28, the subject matter of Examples 24-27 may optionally include means for determining whether the update frequency of the video frame is lower than the refresh rate; and means for causing the display device to operate at a reduced refresh rate in response to: determining that the time period since the last user interaction exceeds the time threshold; and determining that the update frequency of the video frame is lower than the refresh rate.

[0323] In Example 29, the subject matter of Examples 24-28 may optionally include: means for causing the display device to operate at a default refresh rate in response to determining that the update frequency of the video frames is not lower than the refresh rate after causing the display device to operate at a reduced refresh rate.

[0324] According to one or more embodiments, the display refresh rate can be dynamically adjusted based on conditions indicating a reduction in the viewing experience. In some examples, the refresh rate can be reduced if the time since the last user input exceeds a time threshold, if the updated frame portion is below a size threshold, if the frame update frequency is lower than the refresh rate, or a combination of these. Therefore, some embodiments can reduce the power consumption associated with displaying video frames.

[0325] Note that, although Figures 26-33 Various example implementations are illustrated, but other variations are possible. For example, it is envisioned that one or more embodiments may utilize the reference. Figures 1-25 Some or all of the example devices and systems described are to be implemented. Note that in Figures 1-33 The examples shown are provided for illustrative purposes and are not intended to limit any embodiments. Specifically, while embodiments may be shown in a simplified form for clarity, embodiments may include any number and / or arrangement of processors, cores, and / or additional components (e.g., buses, storage media, connectors, power components, buffers, interfaces, etc.). For example, some embodiments are contemplated to include any number of components in addition to those shown, and different arrangements of the shown components may occur in certain implementations. Furthermore, it is contemplated that... Figures 1-33 The specific details shown in the examples can be used anywhere in one or more embodiments.

[0326] It is possible to understand various combinations of the examples above. Embodiments can be used in many different types of systems. For example, in one embodiment, a communication device may be arranged to perform the various methods and techniques described herein. Of course, the scope of the invention is not limited to communication devices, but other embodiments may refer to other types of means for processing instructions, or one or more machine-readable media comprising instructions that, in response to execution on a computing device, cause the device to implement one or more methods and techniques described herein.

[0327] Throughout this specification, references to "an embodiment" or "one embodiment" mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one implementation covered within the present invention. Therefore, the appearance of the phrase "an embodiment" or "in one embodiment" does not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics may be configured in other suitable forms besides the specific embodiments illustrated, and all such forms are covered within the scope of the claims of this application.

[0328] Although the invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate many modifications and variations that can be made from these embodiments. It is intended that the appended claims cover all such modifications and variations that fall within the true spirit and scope of the invention.

Claims

1. A computing device for reducing refresh rate, comprising: Hardware processor; as well as A machine-readable storage medium storing instructions that can be executed by the hardware processor: During the presentation of video frames on a display device, the user input device is monitored, wherein the hardware processor is external to the display device; Control the display device to operate at a first refresh rate; Determine whether the time period since the last user interaction with the user input device exceeds a time threshold; Determine whether the update region size of the video frame is lower than the size threshold; Determine whether the update frequency of the video frame is lower than the first refresh rate; as well as The display device is controlled to operate at a second refresh rate in response to one of the following: Determine that the time period since the last user interaction exceeds the time threshold and determine that the update region size of the video frame is lower than the size threshold; and It is determined that the time period since the last user interaction exceeds the time threshold and that the video frame update frequency is lower than the first refresh rate. The control of the display device to operate at the first refresh rate or the second refresh rate includes: adjusting the period of the vertical blanking interval interruption so that the display device operates at the first refresh rate or the second refresh rate.

2. The computing device of claim 1, wherein the instructions are executable to: In response to determining that the time period since user interaction is less than the time threshold, the display device is controlled to operate at the first refresh rate.

3. The computing device of claim 1, wherein the instructions are executable to: In response to determining that the size of the updated region of the video frame is not lower than the size threshold, the display device is controlled to operate at the first refresh rate.

4. The computing device of claim 1, wherein the instructions are executable to: In response to determining that the update frequency of the video frame is not lower than the first refresh rate, the display device is controlled to operate at the first refresh rate.

5. The computing device as claimed in claim 1, wherein, The size threshold is specified as a specific percentage of the full frame size.

6. The computing device as claimed in claim 1, wherein, The previous user interaction included user input made using an input device.

7. A method for reducing refresh rate, comprising: Multiple video frames are presented on a display device by a computing device; The display device is controlled to operate at a first refresh rate by the adaptive refresh logic of the computing device, wherein the adaptive refresh logic is external to the display device; At multiple points in time: The adaptive refresh logic determines the time period since the last user interaction with the input device; The adaptive refresh logic determines whether the time period since the last user interaction has exceeded a time threshold. The adaptive refresh logic determines whether the update frequency of the video frame is lower than the first refresh rate; The adaptive refresh logic determines whether the size of the updated region of the video frame is lower than a size threshold. At the first time point, in response to determining that the time period since the last user interaction exceeds the time threshold and the video frame update frequency is lower than the first refresh rate, the adaptive refresh logic controls the display device to operate at a second refresh rate; and At the second time point, in response to determining that the time period since the last user interaction exceeds the time threshold and determining that the update region size of the video frame is lower than the size threshold, the adaptive refresh logic controls the display device to operate at a third refresh rate. The adaptive refresh logic controlling the display device to operate at the first refresh rate, the second refresh rate, or the third refresh rate includes: adjusting the period of the vertical blank interval interruption so that the display device operates at the first refresh rate, the second refresh rate, or the third refresh rate.

8. The method of claim 7, further comprising, after controlling the display device to operate at the second refresh rate: Determine that the time period since the last user interaction is lower than the stated time threshold; and In response to determining that the time period since the last user interaction is less than the time threshold, the display device operates at the first refresh rate.

9. The method of claim 7, further comprising, after causing the display device to operate at the third refresh rate: In response to determining that the size of the updated region of the video frame is not less than the size threshold, the display device operates at the first refresh rate.

10. The method of claim 7, further comprising, after controlling the display device to operate at a third refresh rate: Determine that the time period since the last user interaction is lower than the stated time threshold; and In response to determining that the time period since the last user interaction is less than the time threshold, the display device operates at the first refresh rate.

11. The method of claim 7, further comprising, after controlling the display device to operate at the second refresh rate: Determine that the update frequency of the video frames is not lower than the second refresh rate; and In response to determining that the update frequency of the video frame is not lower than the second refresh rate, the display device is controlled to operate at the first refresh rate.

12. The method of claim 7, wherein, The adaptive refresh logic is implemented in the operating system of the computing device.

13. A computing device for reducing refresh rate, comprising: One or more processors; as well as A memory storing a plurality of instructions, which, when executed by the one or more processors, cause the computing device to perform the method as described in any one of claims 7 to 12.

14. At least one machine-readable medium having data stored thereon, the data, if used by at least one machine, causing the at least one machine to perform the method as described in any one of claims 7 to 12.

15. An electronic device comprising means for performing the method as described in any one of claims 7 to 12.

16. An article comprising a non-transitory machine-readable storage medium storing instructions for reducing a refresh rate, the instructions causing a hardware processor, when executed, to: Presenting multiple video frames on a display device; The display device is controlled to operate at a first refresh rate, wherein the hardware processor is external to the display device; Determine whether the time period since the last user interaction with the input device exceeds a time threshold; Determine whether the update region size of the video frame is lower than the size threshold; Determine whether the update frequency of the video frame is lower than the first refresh rate; as well as The display device is controlled to operate at a second refresh rate in response to one of the following: Determine that the time period since the last user interaction exceeds the time threshold and determine that the update region size of the video frame is lower than the size threshold; and It is determined that the time period since the last user interaction exceeds the time threshold and that the video frame update frequency is lower than the first refresh rate. The control of the display device to operate at the first refresh rate or the second refresh rate includes: adjusting the period of the vertical blanking interval interruption so that the display device operates at the first refresh rate or the second refresh rate.

17. The article of claim 16, wherein the instructions are executable to: In response to determining that the time period since user interaction is less than the time threshold, the display device is controlled to operate at a first refresh rate.

18. The article as claimed in claim 16, wherein, The size threshold is a specific percentage of the full frame size.

Citation Information

Patent Citations

  • Screen refreshing control method and terminal

    CN106506856A

  • Apparatus and method for self-refresh in a display device

    US20080001934A1