Patent Description:
Computing systems include multiple tiers of memory. These different tiers of memory generally include smaller memory (e.g., Dynamic Random Access Memory (DRAM)) as well as larger memory (such as storage media). The smaller memory is faster than the larger memory and data that is to be immediately consumed by a processor is generally stored in the faster/smaller memory before it is transferred to the larger/slower memory. <CIT> shows technologies for error recovery in compressed data streams. The subject-matter provided by the present invention is defined in independent claims, while preferred embodiments of the present invention are defined in dependent claims.

To increase storage capacity, data that is to be stored in the smaller/faster memory can be compressed. However, compression (and subsequent decompression) of data can negatively impact the overall system performance and latency.

The detailed description is provided with reference to the accompanying figures.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. However, various embodiments may be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the particular embodiments. Further, various aspects of embodiments may be performed using various means, such as integrated semiconductor circuits ("hardware"), computer-readable instructions organized into one or more programs ("software"), or some combination of hardware and software. For the purposes of this disclosure reference to "logic" shall mean either hardware (such as logic circuitry or more generally circuitry or circuit), software, firmware, or some combination thereof.

As mentioned above, data stored in a smaller/faster memory (such as DRAM or more generally Random Access Memory (RAM)) may be first compressed to increase the effective storage capacity. The compression/decompression operations may be performed at a memory page level. Use of compression at the page level to create memory hierarchy or tiers is becoming very important, e.g., to allow for storage of larger amounts of data in faster memory. The basic idea is that rather than paging memory pages out to disk or other non-volatile memory, one would instead compress the data and store it in faster memory. The goal is to increase the effective memory capacity but with much better performance than swapping to a slower tier such as storage media. The ideal performance goal is to maximize the memory savings (via page compression) with nearly zero performance impact to applications, compared to running on a system with a much larger DRAM capacity (and no compression). Hence, reducing compression latency and decompression latency would tremendously aid in this goal.

To this end, some embodiments provide one or more techniques for verifying a compressed stream fused with copy or transform operation(s). In an embodiment, a hardware compression or decompression accelerator logic (such as "IAX™" or "Intel Analytics Accelerator" provided by Intel® Corporation of Santa Clara, California) is used to reduce compression/decompression latency, while maximizing the compression ratio achieved (e.g., and thereby providing dynamic memory (e.g., RAM/DRAM/etc.) usage savings).

By contrast, some current methods of compression consists of multiple steps. When a memory page is to be compressed, its compressed size cannot be known a priori. To find a destination buffer in the compressed DRAM tier, one needs to know the compressed size (which needs to be provided as input to the allocate call). This chicken-and-egg problem is traditionally solved by compressing once to determine the size (but suppressing or discarding the output), allocating the memory using the size, and then issuing the real/actual compression operation with the destination buffer that was allocated.

Since compression is an expensive operation, another approach is to compress to a temporary buffer, allocate the destination buffer using the determined size, and then copy data to the new destination buffer. In addition to these steps, for ultra-reliable systems, Content Service Providers (CSPs) aim to minimize any Silent Data Corruption (SDC) errors that can be introduced during transformation operations such as compress or encrypt, and to this end they issue another operation to decompress and verify that the compressed data was correct before committing the page swap operation. Thus, in this scenario, three operations need to be performed during the compression of a memory page; hence, three tasks need to be performed by a compression/decompression accelerator.

To address these issues, an embodiment eliminates at least one of these three tasks by fusing two or more operations, thereby improving performance of the accelerator proportionally. As a result, some embodiments can improve the compression performance for the deflate compression algorithm with minimal area cost and design complexity.

Moreover, an embodiment creates a new mode of operation for a compression/decompression accelerator logic (such as in IAX) for fusing an extra copy operation to the decompress-verify operation. The decompress-verify operation is similar to a regular decompression, but suppresses or otherwise does not use the output from the decompressor logic. The output is only used internally to calculate a checksum or Cyclic Redundancy Code (CRC) that is compared against the one that was generated on the input to the compressor. When these match, it indicates the compressed bitstream does not have any errors and can regenerate the input; the input can therefore be discarded and the compressed data can be committed.

This new mode fuses an additional operation such as copy the input stream to the output stream. So, the decompressor works on the input and generates an internal uncompressed stream to calculate the checksum/CRC, while a parallel hardware logic block copies the input stream to the output (with other optional transform operations if needed). This allows the memory page decompression flow to complete with two accelerator tasks instead of three.

<FIG> illustrates a block diagram of various components of a system for compression-decompression which may be used in some embodiments. As shown, input from DRAM <NUM> may be received at various components and, after processing, stored in a cache <NUM> (e.g., Last Level Cache (LLC)). While some embodiments shown/discussed indicate input data is obtained from DRAM and output stored in a cache, embodiments are not limited to this and input data may be stored in any memory device (such as those discussed with reference to <FIG>, including a RAM, cache, non-volatile memory, etc.) and the output data may be stored in any memory device (such as those discussed with reference to <FIG>, including a RAM, cache, non-volatile memory, etc.). As a result, the data could be transferred from DRAM and end up in LLC (such as shown in <FIG>) or it could alternatively be transferred from an LLC to an LLC, DRAM to DRAM, etc. Further, the memory device used to store the input data is assumed to be faster than the memory device that stores the output data in most implementations.

For compression, data is read from the DRAM <NUM>, compressed by compression logic <NUM>, and stored in the cache <NUM>. As shown in <FIG>, the CRC is computed on the input to the compression logic <NUM> and later compared with a CRC from the output of the decompression logic <NUM> (as will be further discussed with reference to <FIG>, for example). For uncompressed copying, memory copy logic <NUM> simply copies data from the DRAM <NUM> to the cache <NUM>. For decompression, data input from DRAM <NUM> is first decrypted (if necessary) by decryption logic <NUM>. The decrypted data is then decompressed by decompression logic <NUM>. As shown in <FIG>, a checksum/CRC check may be optionally performed by decompression logic <NUM>. The decompressed data generated by the decompression logic <NUM> may then be passed either directly or through filter logic <NUM> to the cache <NUM>. In an embodiment, the filter logic <NUM> performs operations on the data that might typically be used for columnar databases, such as scan, extract, etc..

As shown in <FIG>, another logic <NUM> may perform other tasks such as checking checksums/CRCs, perform sparsity operations for Artificial Intelligence (AI) tasks, etc. Moreover, these other operations by logic <NUM> may primarily include CRC and zero compression/decompression. These last ones may be a non-standard "lightweight" compression scheme that just removes <NUM>'s (more particularly zero bytes, zero words, or zero DWORDS) from the uncompressed data. One application for this is compression of spare matrices (or matrices that contain a lot of zero elements, e.g., for AI applications, labeled as "sparsity" in <FIG>), but it is not limited to that.

<FIG> illustrates a block diagram of a compression-decompression logic, according to an embodiment. While some components of <FIG> may be the same or similar to the components of <FIG> (as indicated by use of the same reference numerals), <FIG> illustrates how a copy/transform logic <NUM> may perform a copy/transform operation (e.g., in parallel or substantially simultaneously with the decryption/decompression/filtering operations) in accordance with one embodiment.

In at least one embodiment, the compression/decompression accelerator logic discussed is capable to operate on virtual addresses. Hence, the compression/decompression accelerator logic may include a Translation Lookaside Buffer (TLB) or other logic to translate virtual addresses into physical addresses and vice versa.

<FIG> illustrates a decompression descriptor <NUM> for verifying a compressed stream fused with copy or transform operation(s), according to an embodiment. The decompression descriptor <NUM> may be used by the decompression logic <NUM> of <FIG> to determine specific information/operation(s) to be used/performed during decompression. While some embodiments are discussed with reference to specific bits in the descriptor <NUM>, embodiments are not limited to these specific bits and any bit value in any storage device (such as a register, a cache, DRAM, NVM, etc.) may be used for the specific purposed listed.

Moreover, an embodiment adds a memory-page copy functionality to the decompress-verify task discussed above. As discussed further below, an instruction may cause addition of the copy functionality to the decompress-verify task when an opcode "decompress" is present in the instruction. Two flag bits of interest are decompression flags <NUM> bit <NUM> (indicating disablement of the normal output) and decompress-<NUM> flags <NUM> bit <NUM> (indicating enablement of verify-copy operation). In one embodiment, the "copy-verify feature could only be used if a "suppress output" flag has been also enabled (the output here refers to the data generated by the decompression logic <NUM>). There may also be a descriptor checker logic included (not shown) that when this mode is enabled, max-dest-size (maximum destination size) field <NUM> has to be at least as big as the source <NUM> size <NUM>.

When verify-copy is enabled, the decompression logic copies the input to the output as part of (or substantially simultaneously) performing the decompress-verify operation. The data copied would be the data from the source <NUM> address <NUM> to the destination address <NUM>. And similarly, if the decryption logic <NUM> is enabled, the compression/decompression logic copies the input to decrypt rather than the input to decompress in an embodiment. In <FIG>, "PASID" <NUM> or Physical Address Space ID (Identifier) is inserted automatically by an enqueue command, and it informs the accelerator which address translation tables should be used to map from virtual to physical addresses. Further, "Source <NUM> Address" <NUM> may be used as an address pointing to additional data for one or more of the following purposes: (<NUM>) to supply a second data stream to some of the filter operations; (<NUM>) to supply parameters that do not fit into the descriptor <NUM> (e.g. cryptographic keys); (<NUM>) to save and restore state when one logical operation is broken into multiple physical operations (e.g., decompressing a <NUM> MB file by processing 64KB at a time).

Conceptually, the data that has been written to the output was the data that came into the processor core (i.e., into the cryptographic or decompress input accumulator). This is opposed to, for example, the data going out of the input accumulators. Thus, any initial data in the input accumulators, when the state structure for the compression/decompression logic is read, would not be written, just data being consumed from source <NUM> address <NUM>.

Furthermore, if there is a decompress error, the results of the copy are undefined (i.e., one cannot assume any data was copied). If the output buffer is smaller than source <NUM> buffer, an overflow output is generated.

<FIG> illustrates a flow diagram of a method <NUM> to verify a compressed stream fused with copy or transform operation(s), according to an embodiment. One or more of the operations of method <NUM> may be performed by one or more components of <FIG>, such as discussed herein, including logic <NUM> and/or logic <NUM>, for example.

In one embodiment, an Operating System (OS) will cause performance of data compression using a compression/decompression accelerator logic with an improved flow for decompression. Moreover, for memory tiering, the use of this feature is generally in the page-swap logic which would be in the kernel and, hence, rely on the OS to cause performance of the compression using an accelerator with an improved flow for decompression; however, embodiments are not limited to use of OS and an application that is running in the user space and compressing/decompressing data may also trigger the performance of compression using an accelerator with improved flow for decompression. Referring to <FIG>, operation <NUM> determines whether a fused copy/transform feature is enabled such as discussed with reference to the flag of <FIG>. In an embodiment, an instruction may include a field that when decoded causes the determination of whether the fused copy/transform feature is enabled at operation <NUM>. In one embodiment, an (e.g., enqueue) instruction takes (e.g., <NUM> bytes of) data from a memory buffer, updates the PASID <NUM>, and sends the data to the accelerator. Hence, the instruction may not be aware of the details of the accelerator. For example, there may not be any flags in the instruction. Thereafter, the data sent to the accelerator (not the address in at least one embodiment) and the accelerator may be unaware of the adder for the descriptor. In an alternative embodiment, the instruction may include the field to either directly indicate the enablement of this feature or the field may point to (e.g., via an address) a storage location such as a decompression descriptor with a corresponding indication (e.g., as discussed with reference to <FIG>). The same instruction or a separate instruction may further cause enqueuing of a request for the fused copy/transform operation(s) with or without the actual data, e.g., in a queue of the decompression logic <NUM> and/or copy/transform logic <NUM>, in some embodiments. In an embodiment, the enqueue request may originate from a user space, e.g., bypassing a kernel or OS.

At operation <NUM> (e.g., performed by a compression/decompression accelerator), if the fused copy/transform feature is not enabled, the compression/decompression tasks are performed without a fused copy/transform operation. If the fused copy/transform feature is enabled, operation <NUM> (e.g., using logic <NUM> or a compression/decompression accelerator) compresses the input data (e.g., at memory page granularity) and stores the compressed data in a temporary buffer. When compressing the data at operation <NUM>, the size of the compressed data is unknown until the end of the compression operation, which may then be determined based on how much space the compressed data consumes in the temporary buffer.

At an operation <NUM>, memory allocation logic allocates a buffer having a size that matches the compressed data, e.g., as determined at operation <NUM>. In some embodiments, managing of buffers is handled in software, e.g., by OS kernel code. Hence, software can be responsible for managing buffers, setting up the descriptor, invoking the accelerator, etc. In turn, hardware logic circuitry (such as a cache or memory controller/circuitry, including for example those discussed with reference to <FIG> et seq. ) performs what the software instructs it to do. In one embodiment, the allocated size is greater or equal to the size of the compressed data at operation <NUM>. At operation <NUM> (e.g., performed by a compression/decompression accelerator or logic <NUM>), a decompress-verify with copy operation is performed to copy the decompressed data from the temporary buffer of operation <NUM> to a destination buffer determined at operation <NUM>, with the data size determined after operation <NUM>. In various embodiments, the temporary buffer and/or the destination buffer may be stored in any memory device discussed herein (e.g., with reference to <FIG> et seq. ), including a DRAM, RAM, or cache.

At operation <NUM> (e.g., performed by a compression/decompression accelerator such as discussed with reference to <FIG>), it is determined whether the checksum/CRC value from operation <NUM> (input to compression) matches the checksum/CRC value from operation <NUM> (output of decompression). Once the checksum/CRC match is verified, the OS will commit the compressed data/page(s) into the compressed tier, discards the original page, deallocates the temporary/destination buffers, and/or returns to the user application at operation <NUM>. Later on when this compressed data/page(s) are accessed, a page fault will be triggered causing the OS to call on the compression/decompression logic to decompress the data/page(s) from this location and restore/map it to the corresponding user space. Otherwise, at operation <NUM>, if the checksum/CRC match fails, the OS causes deallocation of the temporary and destination buffers and the uncompressed data remains available.

<FIG> illustrates a block diagram of decompressor pipeline <NUM>, according to an embodiment. In various embodiments, components <NUM>, <NUM>, <NUM>, and <NUM> may be similar to or the same as those discussed with reference to <FIG>. In one embodiment, if the mode of operation discussed with reference to <FIG> is expanded, other useful functions may be created to work in parallel in addition to the copy/transform operation(s). One such operation is encryption. For example, a compression/decompression logic may also perform encryption operation(s) without additional hardware added to the compression pipeline. More particularly, the cipher block in the decompression pipeline may be reused to encrypt the compressed stream enroute to the destination buffer. This is illustrated in <FIG> by the input being fed to the encryption logic <NUM> and copy/transform logic <NUM>, without passing the encrypted data to the decompression logic <NUM>.

Additionally, some embodiments may be applied in computing systems that include one or more processors (e.g., where the one or more processors may include one or more processor cores), such as those discussed with reference to <FIG> et seq. , including for example a desktop computer, a work station, a computer server, a server blade, or a mobile computing device. The mobile computing device may include a smartphone, tablet, UMPC (Ultra-Mobile Personal Computer), laptop computer, Ultrabook™ computing device, wearable devices (such as a smart watch, smart ring, smart bracelet, or smart glasses), etc..

Processor cores may be implemented in different ways, for different purposes, and in different processors. For instance, implementations of such cores may include: <NUM>) a general purpose in-order core intended for general-purpose computing; <NUM>) a high performance general purpose out-of-order core intended for general-purpose computing; <NUM>) a special purpose core intended primarily for graphics and/or scientific (throughput) computing. Implementations of different processors may include: <NUM>) a CPU (Central Processing Unit) including one or more general purpose in-order cores intended for general-purpose computing and/or one or more general purpose out-of-order cores intended for general-purpose computing; and <NUM>) a coprocessor including one or more special purpose cores intended primarily for graphics and/or scientific (throughput). Such different processors lead to different computer system architectures, which may include: <NUM>) the coprocessor on a separate chip from the CPU; <NUM>) the coprocessor on a separate die in the same package as a CPU; <NUM>) the coprocessor on the same die as a CPU (in which case, such a coprocessor is sometimes referred to as special purpose logic, such as integrated graphics and/or scientific (throughput) logic, or as special purpose cores); and <NUM>) a system on a chip that may include on the same die the described CPU (sometimes referred to as the application core(s) or application processor(s)), the above described coprocessor, and additional functionality. Exemplary core architectures are described next, followed by descriptions of exemplary processors and computer architectures.

<FIG> is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue/execution pipeline according to embodiments. <FIG> is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue/execution architecture core to be included in a processor according to embodiments. The solid lined boxes in <FIG> illustrate the in-order pipeline and in-order core, while the optional addition of the dashed lined boxes illustrates the register renaming, out-of-order issue/execution pipeline and core. Given that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

The execution engine unit <NUM> includes the rename/allocator unit <NUM> coupled to a retirement unit <NUM> and a set of one or more scheduler unit(s) <NUM>. The scheduler unit(s) <NUM> represents any number of different schedulers, including reservations stations, central instruction window, etc. The scheduler unit(s) <NUM> is coupled to the physical register file(s) unit(s) <NUM>. Each of the physical register file(s) units <NUM> represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point,, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc. In one embodiment, the physical register file(s) unit <NUM> comprises a vector registers unit, a writemask registers unit, and a scalar registers unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers. The physical register file(s) unit(s) <NUM> is overlapped by the retirement unit <NUM> to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and a retirement register file(s); using a future file(s), a history buffer(s), and a retirement register file(s); using a register maps and a pool of registers; etc.). The retirement unit <NUM> and the physical register file(s) unit(s) <NUM> are coupled to the execution cluster(s) <NUM>. The execution cluster(s) <NUM> includes a set of one or more execution units <NUM> and a set of one or more memory access units <NUM>. The execution units <NUM> may perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. The scheduler unit(s) <NUM>, physical register file(s) unit(s) <NUM>, and execution cluster(s) <NUM> are shown as being possibly plural because certain embodiments create separate pipelines for certain types of data/operations (e.g., a scalar integer pipeline, a scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipeline, and/or a memory access pipeline that each have their own scheduler unit, physical register file(s) unit, and/or execution cluster - and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of this pipeline has the memory access unit(s) <NUM>). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the rest in-order.

<FIG> illustrates a block diagram of an SOC package in accordance with an embodiment. As illustrated in <FIG>, SOC <NUM> includes one or more Central Processing Unit (CPU) cores <NUM>, one or more Graphics Processor Unit (GPU) cores <NUM>, an Input/Output (I/O) interface <NUM>, and a memory controller <NUM>. Various components of the SOC package <NUM> may be coupled to an interconnect or bus such as discussed herein with reference to the other figures. Also, the SOC package <NUM> may include more or less components, such as those discussed herein with reference to the other figures. Further, each component of the SOC package <NUM> may include one or more other components, e.g., as discussed with reference to the other figures herein. In one embodiment, SOC package <NUM> (and its components) is provided on one or more Integrated Circuit (IC) die, e.g., which are packaged into a single semiconductor device.

As illustrated in <FIG>, SOC package <NUM> is coupled to a memory <NUM> via the memory controller <NUM>. In an embodiment, the memory <NUM> (or a portion of it) can be integrated on the SOC package <NUM>.

The I/O interface <NUM> may be coupled to one or more I/O devices <NUM>, e.g., via an interconnect and/or bus such as discussed herein with reference to other figures. I/O device(s) <NUM> may include one or more of a keyboard, a mouse, a touchpad, a display, an image/video capture device (such as a camera or camcorder/video recorder), a touch screen, a speaker, or the like.

<FIG> is a block diagram of a processing system <NUM>, according to an embodiment. In various embodiments the system <NUM> includes one or more processors <NUM> and one or more graphics processors <NUM>, and may be a single processor desktop system, a multiprocessor workstation system, or a server system having a large number of processors <NUM> or processor cores <NUM>. In on embodiment, the system <NUM> is a processing platform incorporated within a system-on-a-chip (SoC or SOC) integrated circuit for use in mobile, handheld, or embedded devices.

An embodiment of system <NUM> can include, or be incorporated within a server-based gaming platform, a game console, including a game and media console, a mobile gaming console, a handheld game console, or an online game console. In some embodiments system <NUM> is a mobile phone, smart phone, tablet computing device or mobile Internet device. Data processing system <NUM> can also include, couple with, or be integrated within a wearable device, such as a smart watch wearable device, smart eyewear device, augmented reality device, or virtual reality device. In some embodiments, data processing system <NUM> is a television or set top box device having one or more processors <NUM> and a graphical interface generated by one or more graphics processors <NUM>.

In some embodiments, processor <NUM> is coupled to a processor bus <NUM> to transmit communication signals such as address, data, or control signals between processor <NUM> and other components in system <NUM>. In one embodiment the system <NUM> uses an exemplary 'hub' system architecture, including a memory controller hub <NUM> and an Input Output (I/O) controller hub <NUM>. A memory controller hub <NUM> facilitates communication between a memory device and other components of system <NUM>, while an I/O Controller Hub (ICH) <NUM> provides connections to I/O devices via a local I/O bus. In one embodiment, the logic of the memory controller hub <NUM> is integrated within the processor.

Memory device <NUM> can be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory device, phase-change memory device, or some other memory device having suitable performance to serve as process memory. In one embodiment the memory device <NUM> can operate as system memory for the system <NUM>, to store data <NUM> and instructions <NUM> for use when the one or more processors <NUM> executes an application or process. Memory controller hub <NUM> also couples with an optional external graphics processor <NUM>, which may communicate with the one or more graphics processors <NUM> in processors <NUM> to perform graphics and media operations.

In some embodiments, ICH <NUM> enables peripherals to connect to memory device <NUM> and processor <NUM> via a high-speed I/O bus. The I/O peripherals include, but are not limited to, an audio controller <NUM>, a firmware interface <NUM>, a wireless transceiver <NUM> (e.g., Wi-Fi, Bluetooth), a data storage device <NUM> (e.g., hard disk drive, flash memory, etc.), and a legacy I/O controller <NUM> for coupling legacy (e.g., Personal System <NUM> (PS/<NUM>)) devices to the system. One or more Universal Serial Bus (USB) controllers <NUM> connect input devices, such as keyboard and mouse <NUM> combinations. A network controller <NUM> may also couple to ICH <NUM>. In some embodiments, a high-performance network controller (not shown) couples to processor bus <NUM>. It will be appreciated that the system <NUM> shown is exemplary and not limiting, as other types of data processing systems that are differently configured may also be used. For example, the I/O controller hub <NUM> may be integrated within the one or more processor <NUM>, or the memory controller hub <NUM> and I/O controller hub <NUM> may be integrated into a discreet external graphics processor, such as the external graphics processor <NUM>.

<FIG> is a block diagram of an embodiment of a processor <NUM> having one or more processor cores 902A to 902N, an integrated memory controller <NUM>, and an integrated graphics processor <NUM>. Those elements of <FIG> having the same reference numbers (or names) as the elements of any other figure herein can operate or function in any manner similar to that described elsewhere herein, but are not limited to such. Processor <NUM> can include additional cores up to and including additional core 902N represented by the dashed lined boxes. Each of processor cores 902A to 902N includes one or more internal cache units 904A to 904N. In some embodiments each processor core also has access to one or more shared cached units <NUM>.

The internal cache units 904A to 904N and shared cache units <NUM> represent a cache memory hierarchy within the processor <NUM>. The cache memory hierarchy may include at least one level of instruction and data cache within each processor core and one or more levels of shared mid-level cache, such as a Level <NUM> (L2), Level <NUM> (L3), Level <NUM> (L4), or other levels of cache, where the highest level of cache before external memory is classified as the LLC. In some embodiments, cache coherency logic maintains coherency between the various cache units <NUM> and 904A to 904N.

In some embodiments, processor <NUM> may also include a set of one or more bus controller units <NUM> and a system agent core <NUM>. The one or more bus controller units <NUM> manage a set of peripheral buses, such as one or more Peripheral Component Interconnect buses (e.g., PCI, PCI Express). System agent core <NUM> provides management functionality for the various processor components. In some embodiments, system agent core <NUM> includes one or more integrated memory controllers <NUM> to manage access to various external memory devices (not shown).

In some embodiments, one or more of the processor cores 902A to 902N include support for simultaneous multi-threading. In such embodiment, the system agent core <NUM> includes components for coordinating and operating cores 902A to 902N during multi-threaded processing. System agent core <NUM> may additionally include a power control unit (PCU), which includes logic and components to regulate the power state of processor cores 902A to 902N and graphics processor <NUM>.

In some embodiments, processor <NUM> additionally includes graphics processor <NUM> to execute graphics processing operations. In some embodiments, the graphics processor <NUM> couples with the set of shared cache units <NUM>, and the system agent core <NUM>, including the one or more integrated memory controllers <NUM>. In some embodiments, a display controller <NUM> is coupled with the graphics processor <NUM> to drive graphics processor output to one or more coupled displays. In some embodiments, display controller <NUM> may be a separate module coupled with the graphics processor via at least one interconnect, or may be integrated within the graphics processor <NUM> or system agent core <NUM>.

In some embodiments, a ring based interconnect unit <NUM> is used to couple the internal components of the processor <NUM>. However, an alternative interconnect unit may be used, such as a point-to-point interconnect, a switched interconnect, or other techniques, including techniques well known in the art. In some embodiments, graphics processor <NUM> couples with the ring interconnect <NUM> via an I/O link <NUM>.

The exemplary I/O link <NUM> represents at least one of multiple varieties of I/O interconnects, including an on package I/O interconnect which facilitates communication between various processor components and a high-performance embedded memory module <NUM>, such as an eDRAM (or embedded DRAM) module. In some embodiments, each of the processor cores <NUM> to 902N and graphics processor <NUM> use embedded memory modules <NUM> as a shared Last Level Cache.

In some embodiments, processor cores 902A to 902N are homogenous cores executing the same instruction set architecture. In another embodiment, processor cores 902A to 902N are heterogeneous in terms of instruction set architecture (ISA), where one or more of processor cores 902A to 902N execute a first instruction set, while at least one of the other cores executes a subset of the first instruction set or a different instruction set. In one embodiment processor cores 902A to 902N are heterogeneous in terms of microarchitecture, where one or more cores having a relatively higher power consumption couple with one or more power cores having a lower power consumption. Additionally, processor <NUM> can be implemented on one or more chips or as an SoC integrated circuit having the illustrated components, in addition to other components.

<FIG> is a block diagram of a graphics processor <NUM>, which may be a discrete graphics processing unit, or may be a graphics processor integrated with a plurality of processing cores. In some embodiments, the graphics processor communicates via a memory mapped I/O interface to registers on the graphics processor and with commands placed into the processor memory. In some embodiments, graphics processor <NUM> includes a memory interface <NUM> to access memory. Memory interface <NUM> can be an interface to local memory, one or more internal caches, one or more shared external caches, and/or to system memory.

In some embodiments, graphics processor <NUM> also includes a display controller <NUM> to drive display output data to a display device <NUM>. Display controller <NUM> includes hardware for one or more overlay planes for the display and composition of multiple layers of video or user interface elements. In some embodiments, graphics processor <NUM> includes a video codec engine <NUM> to encode, decode, or transcode media to, from, or between one or more media encoding formats, including, but not limited to Moving Picture Experts Group (MPEG) formats such as MPEG-<NUM>, Advanced Video Coding (AVC) formats such as H. <NUM>/MPEG-<NUM> AVC, as well as the Society of Motion Picture & Television Engineers (SMPTE) <NUM>/VC-<NUM>, and Joint Photographic Experts Group (JPEG) formats such as JPEG, and Motion JPEG (MJPEG) formats.

In some embodiments, graphics processor <NUM> includes a block image transfer (BLIT) engine <NUM> to perform two-dimensional (2D) rasterizer operations including, for example, bit-boundary block transfers. However, in one embodiment, 3D graphics operations are performed using one or more components of graphics processing engine (GPE) <NUM>. In some embodiments, graphics processing engine <NUM> is a compute engine for performing graphics operations, including three-dimensional (3D) graphics operations and media operations.

In some embodiments, GPE <NUM> includes a 3D pipeline <NUM> for performing 3D operations, such as rendering three-dimensional images and scenes using processing functions that act upon 3D primitive shapes (e.g., rectangle, triangle, etc.). The 3D pipeline <NUM> includes programmable and fixed function elements that perform various tasks within the element and/or spawn execution threads to a 3D/Media sub-system <NUM>. While 3D pipeline <NUM> can be used to perform media operations, an embodiment of GPE <NUM> also includes a media pipeline <NUM> that is specifically used to perform media operations, such as video post-processing and image enhancement.

In some embodiments, media pipeline <NUM> includes fixed function or programmable logic units to perform one or more specialized media operations, such as video decode acceleration, video de-interlacing, and video encode acceleration in place of, or on behalf of video codec engine <NUM>. In some embodiments, media pipeline <NUM> additionally includes a thread spawning unit to spawn threads for execution on 3D/Media sub-system <NUM>. The spawned threads perform computations for the media operations on one or more graphics execution units included in 3D/Media sub-system <NUM>.

In some embodiments, 3D/Media subsystem <NUM> includes logic for executing threads spawned by 3D pipeline <NUM> and media pipeline <NUM>. In one embodiment, the pipelines send thread execution requests to 3D/Media subsystem <NUM>, which includes thread dispatch logic for arbitrating and dispatching the various requests to available thread execution resources. The execution resources include an array of graphics execution units to process the 3D and media threads. In some embodiments, 3D/Media subsystem <NUM> includes one or more internal caches for thread instructions and data. In some embodiments, the subsystem also includes shared memory, including registers and addressable memory, to share data between threads and to store output data.

In the following description, numerous specific details are set forth to provide a more thorough understanding. However, it will be apparent to one of skill in the art that the embodiments described herein may be practiced without one or more of these specific details. In other instances, well-known features have not been described to avoid obscuring the details of the present embodiments.

In various embodiments, one or more operations discussed with reference to <FIG> et seq. may be performed by one or more components (interchangeably referred to herein as "logic") discussed with reference to any of the figures.

In various embodiments, the operations discussed herein, e.g., with reference to <FIG> et seq. , may be implemented as hardware (e.g., logic circuitry), software, firmware, or combinations thereof, which may be provided as a computer program product, e.g., including one or more tangible (e.g., non-transitory) machine-readable or computer-readable media having stored thereon instructions (or software procedures) used to program a computer to perform a process discussed herein. The machine-readable medium may include a storage device such as those discussed with respect to the figures.

Additionally, such computer-readable media may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals provided in a carrier wave or other propagation medium via a communication link (e.g., a bus, a modem, or a network connection).

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, and/or characteristic described in connection with the embodiment may be included in at least an implementation. The appearances of the phrase "in one embodiment" in various places in the specification may or may not be all referring to the same embodiment.

Also, in the description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. In some embodiments, "connected" may be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements may not be in direct contact with each other, but may still cooperate or interact with each other.

Claim 1:
An apparatus comprising:
compression logic circuitry (<NUM>) to compress input data and to store the compressed data in a temporary buffer, wherein the compression logic circuitry (<NUM>) is to determine a first checksum value corresponding to the compressed data stored in the temporary buffer; and
decompression logic circuitry (<NUM>) to perform a decompress-verify operation and a parallel copy operation,
wherein the decompress-verify operation is to decompress the compressed data stored in the temporary buffer to determine a second checksum value corresponding to the decompressed data from the temporary buffer, while the parallel copy operation is to transfer the compressed data from the temporary buffer to a destination buffer, wherein the apparatus further comprises means to determine whether the first checksum value and the second checksum value match, and when the first checksum value and the second checksum value match, commit the compressed data in the destination buffer.