Packed Error Correcting Code (ECC) for compressed data protection

Abstract

Packed error correction codes (ECC) for compressed data protection are disclosed. Packed error correction code (ECC) technology embeds ECC check bits into compressed data at the right time. When compressed, the data is encoded with fewer bits and is therefore fragmented when stored or transmitted compared to uncompressed data. The ECC check bits can be packed with the compressed data at the "source" point. The check bits are transmitted with the compressed data, and at any "intermediate" point between the source and the "destination", the check bits can be used to detect and correct errors in the compressed data. Compared to conventional systems, packed ECC enables end-to-end coverage of fully compressed data both inside and outside the processor. While storage circuits are typically protected by architecture-specific ECC, protection also benefits the data as it is transmitted between processing and / or storage units.

Description

Background Art

[0001] Architecture-specific error correction codes (ECC) are provided for detecting and correcting errors within memory devices, but ECC is not available externally. The wide range of interfaces in modern memory devices precludes the use of a dedicated ECC chip between the memory device and the processor. Therefore, processors provide ECC support using address mapping to carve out dedicated portions of memory to store ECC codes—referred to as "embedded" or "inline" ECC. A disadvantage of conventional inline ECC is that many data accesses also require a separate ECC access, which increases memory bandwidth usage and power consumption compared to data-only accesses. There is a need to address these and / or other problems associated with the prior art. Summary of the Invention

[0002] Embodiments of the present disclosure relate to packed error correction codes for compressed data protection. Systems and methods disclose packing ECC check bits at the "source" point in time with the compressed data. The check bits are transmitted along with the compressed data, and at any "intermediate" point between the source and the "destination", the check bits can be used to detect and correct errors in the compressed data. Compared to conventional systems as described above, packed ECC enables end-to-end coverage of fully compressed data both inside and outside the processor. While storage circuits are typically protected by architecture-specific ECC, protection also benefits data as it is transmitted between processing and / or storage units. In particular, it is desirable to provide protection for crossbar switch architectures.

[0003] A method, computer-readable medium, and system for providing a packaged error-correcting code for compressed data protection are disclosed. In one embodiment, compressed data is processed within a processor to calculate error-correcting code check bits and determine the number of fixed-size memory cells required to store the combination of the compressed data and the check bits. In one embodiment, the number of fixed-size memory cells is the minimum number that can accommodate all of the compressed data and the check bits. In one embodiment, the compressed data and the check bits are combined into a quantity for transmission within the processor or to an attached device external to the processor. In one embodiment, the combination is transmitted to a storage resource within the processor, and based on the check bits, a determination is made as to whether the compressed data is corrupted. The combination is stored in the storage resource, and, if the compressed data is corrupted, the compressed data is corrected using the check bits before or after the combination is stored. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present system and method for protecting compressed data using packed ECC is described in detail below with reference to the accompanying drawings, in which:

[0005] Figure 1A A block diagram of example ECC and compressed data packing logic suitable for implementing some embodiments of the present disclosure is shown.

[0006] Figure 1B A format of packed ECC check bits and compressed data suitable for implementing some embodiments of the present disclosure is shown.

[0007] Figure 1C An interleaved format of packed ECC check bits and compressed data suitable for implementing some embodiments of the present disclosure is shown.

[0008] Figure 1D A diagram illustrating a packing success rate when three packing compression states are supported according to some embodiments of the present disclosure is shown.

[0009] Figure 1E A flow chart of a method for packing ECC check bits for compressed data protection suitable for implementing some embodiments of the present disclosure is shown.

[0010] Figure 2A Shown are graphs of failure rates for various packaging formats suitable for implementing some embodiments of the present disclosure.

[0011] Figure 2B A block diagram of example ECC and compressed data correction logic suitable for implementing some embodiments of the present disclosure is shown.

[0012] Figure 2C A block diagram of an example system for implementing some embodiments of the present disclosure is shown.

[0013] Figure 2D Another flow chart of a method for packing ECC check bits for compressed data protection suitable for implementing some embodiments of the present disclosure is shown.

[0014] Figure 3 An example parallel processing unit suitable for implementing some embodiments of the present disclosure is shown.

[0015] Figure 4A Some embodiments suitable for implementing the present disclosure are shown. Figure 3 An example general-purpose processing cluster within a parallel processing unit.

[0016] Figure 4B Some embodiments suitable for implementing the present disclosure are shown. Figure 3 An example memory partitioning unit of a parallel processing unit.

[0017] Figure 4C Some embodiments suitable for implementing the present disclosure are shown. Figure 4A An example of a streaming multiprocessor.

[0018] Figure 5A is a conceptual diagram of a processing system implemented using the PPU of FIG. 4 , suitable for implementing some embodiments of the present disclosure.

[0019] Figure 5B Illustrated are exemplary systems in which the various architecture and / or functionality of various previous embodiments may be implemented.

[0020] Figure 5C Components of an exemplary system that can be used to train and utilize machine learning in at least one embodiment are shown.

[0021] Figure 6 An exemplary streaming system suitable for implementing some embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0022] Disclosed are systems and methods for packed ECC for compressed data protection. ECC check bits can be calculated for the compressed data and combined with the compressed data into a packed format using an equal or fewer number of bits than for the uncompressed data. The packed ECC compressed data can be transmitted within a processor or externally. The embedded check bits can be used to detect and correct errors in the compressed data at any point within the processor or by an external device receiving the packed ECC compressed data. Thus, in addition to providing protection within the processor, packed ECC can also be used to protect compressed data transmitted externally. Conversely, a processor can receive the packed ECC data and detect and correct any errors in the compressed received data.

[0023] Representing data in a compressed format may reduce power, particularly when accessing memory storing the compressed data. Compressing data can also improve performance when performance is limited by bandwidth by enabling multiple data to be transferred for each transaction. Combining ECC check bits with compressed data provides protection with minimal or no modification to existing caches and storage in processors, interfaces, and external memory devices. For example, packed ECC check bits do not require dedicated storage and routing circuits because the check bits are embedded in compressed data occupied bits that would otherwise be unused due to compression. The protection provided by ECC increases resilience and may be required for security certification and / or to meet reliability requirements.

[0024] Traditionally, data in main memory and large storage arrays is protected by structure-specific ECC. By providing a fixed amount of memory capacity for ECC check bits, inline error detection or correction using ECC is provided for main memory. The fixed amount cannot be used to store other data, which effectively reduces the main memory capacity. In addition, reading and writing ECC check bits consumes additional memory bandwidth and power. There is also the management overhead of mapping the ECC check bit address space and generating additional transactions (e.g., memory accesses) to access the ECC check bits. In addition, in processors such as graphics processing units (GPUs), ECC check bits are typically not transferred from one structure to the next, leaving coverage holes between the ECC decoder of one structure in the memory hierarchy and the ECC encoder of the next structure in the memory hierarchy.

[0025] Compared to conventional solutions, packed ECC compressed data only requires dedicated ECC storage when the check bits cannot be combined with the compressed data due to insufficient compression. As a result, when the check bits are successfully combined with the compressed data, memory bandwidth and power consumption for memory access are reduced compared to inline ECC implementations. Specifically, the combination of compressed data and check bits can be stored in a memory location that is accessed by a single address and read or written using a single access request. Furthermore, the ECC coverage can be extended through the memory hierarchy and across multiple structures, reducing or eliminating coverage holes and providing the potential for end-to-end protection.

[0026] Figure 1A A block diagram of an example ECC and compressed data packing logic 100 suitable for implementing some embodiments of the present disclosure is shown. It should be understood that this and other arrangements described herein are merely set forth as examples. In addition to or in place of those shown, other arrangements and elements (such as machines, interfaces, functions, sequences, functional groups, etc.) can also be used, and some elements can be omitted completely. In addition, many of the elements described herein are functional entities that can be implemented as discrete or distributed components or in combination with other components and in any appropriate combination and position. The various functions described herein as being performed by an entity can be implemented by hardware, firmware, and / or software. For example, the various functions can be implemented by executing instructions stored in a memory by a processor. In addition, those of ordinary skill in the art will appreciate that any system that performs the operation of ECC and compressed data packing logic 100 is within the scope and spirit of the embodiments of the present disclosure.

[0027] like Figure 1AAs shown, data compression unit 110 compresses data, and ECC calculation unit 115 calculates ECC check bits for the compressed data. The compression operation performed by data compression unit 110 is decoupled from the ECC check bit calculation and packing operations. Data compression unit 110 can be in a separate processing or execution unit, with one or more storage and / or transmission circuits between data compression unit 110 and ECC calculation unit 115. However, to best protect the compressed data, check bits should be calculated at the output of data compression unit 110 to ensure that the compressed data has not been corrupted before the check bits are calculated.

[0028] Packing unit 120 packs the check bits and compressed data into the smallest possible number of fixed-size storage units, such as atoms. In one embodiment, each atom is 32 bytes, and the uncompressed data is four atoms. Depending on the compressibility of the data, the compressed data can fit into one, two, three, or four atoms. In one embodiment, the check bits calculated for each atom of data are 2 bytes, so an 8-byte check bit is calculated for each of the four atoms of compressed data. In one embodiment, the number of atoms required to store the combination of compressed data and check bits is determined. In one embodiment, the number of atoms is the minimum number of atoms that can fit into the entire combination. The second number of atoms required to store the compressed data without the check bits may be less than the number of atoms required to store the combination of compressed data and check bits. Packing unit 120 outputs the combination and a compression status. The compression status can be stored in a memory mapping unit, in a reserved metadata memory area (possibly with a separate cache hierarchy), and / or transmitted with the combination. In one embodiment, the compression status indicates whether the check bits were successfully packed into the combination with the compressed data and the number of atoms occupied by the combination. In one embodiment, the compression status also indicates the compression format used to compress the data and decompress the compressed data.

[0029] In one embodiment, the compression state is augmented with states that support packed and unpacked variants of each compression size. For example, a single bit of the compression state can indicate whether a check bit is packed with the compressed data, and whether the compression format is encoded in the remaining bits of the compression state. Thus, the compressed data is encoded in the same bits regardless of whether the check bit is packed with the compressed data. In one embodiment, when the compression state indicates that packing was unsuccessful, the separately stored check bits can be prefetched as a block to reduce the number of check bit read accesses, thereby benefiting from packing failure locality.

[0030] When packing is successful, the compression state is a packed compression state indicating the number of atoms that accommodate the combination, and the possible packed compression states may depend on the mode setting. In one embodiment, the maximum number of atoms is four, and four possible packed compression states are supported, one, two, three and four atoms. The maximum number and the packed compression state are controlled by the packing mode input to the packing unit 120. The packing mode can be fixed, programmed or configured according to the setting or context. In another embodiment, the maximum number of atoms is four, and only two possible packed compression states are supported, two and four atoms. In one embodiment, packing is unsuccessful when the number of atoms required to store the combination is greater than the maximum number of atoms. When packing fails, the combination of check digits and compressed data is not packed, and the compression state is "unpacked".

[0031] When the compression state is not packed, the check digits and the compressed data are stored and transmitted separately. In another embodiment, when the compression state is not packed, the check digits are removed from the combination and discarded, so that the check digits cannot be used for error detection and correction. In one embodiment, the maximum number of atoms is large enough to be able to store uncompressed data packed with check digits. When the maximum number is large enough to be able to store uncompressed data packed with check digits, the maximum number is also large enough to be able to store all combinations of compressed data and check digits, regardless of the compression rate or compressibility of the data. Therefore, the unpacked compression state implicitly indicates that the compressed data occupies the maximum number of atoms.

[0032] Now, more illustrative information is provided regarding various optional architectures and features that can be used to implement the aforementioned framework as desired by the user. It should be strongly noted that the following information is provided for illustrative purposes and should not be construed as limiting in any way. Optionally, any of the following features may be combined with or without excluding the other features described.

[0033] Figure 1BA format for encoding a combination of packed ECC check bits 125 and compressed data 130 suitable for implementing some embodiments of the present disclosure is shown. The format includes an integer number of N atoms, where 1≤N≤maximum. When the compressed data 130 occupies less than an integer number of atoms, the compressed data 130 is "fragmented" and the check bits 125 can fill the unoccupied bits. When the unoccupied bits are less than the number of bits in the check bits 125, additional atoms can be included to package the check bits 125 with the compressed data 130. In one embodiment, the check bits 125 are located in the same position within the format, regardless of the number of atoms used to encode the compressed data 130. For example, the check bits 125 may always be in the most significant bit. In one embodiment, the unused bits are set to a constant value or an arbitrary value. In one embodiment, the unused bits remain unchanged compared to the compressed data input to the ECC calculation unit 115. In one embodiment, the unused bits are set to a value that minimizes switching (e.g., signal switching) of the bus transmitting the combination.

[0034] Figure 1C An interleaved format for encoding a combination of packed ECC check bits 126 and compressed data 121 suitable for implementing some embodiments of the present disclosure is shown. The format includes up to four atoms, wherein the compressed data 121 is interleaved with check bits 128. Check bits 126-A are calculated for compressed data 121-A, and in one embodiment, compressed data 121-A is generated from one atom of compressed data. If the combination of compressed data 121-A and check bits 126-A exceeds one atom, then packing fails. Similarly, compressed data 121-B, 121-C, and 121-D are interleaved with their respective check bits 126-B, 126-C, and 126-D.

[0035] The advantage of the interleaved format is that when fewer than four atoms are accessed, the compressed data 121 for each atom being read can be verified and, if necessary, independently corrected using the corresponding check bits 128. Similarly, if four atoms are transmitted serially, the compressed data 121 for each atom can be verified and, if necessary, corrected upon receipt.

[0036] In one embodiment, the compression state includes two or more unpacked compression states and corresponding packed compression states. For example, the packed compression states are 4:1 and 4:2, respectively, which indicate that data occupying four atoms is compressed and, when combined with the check bit, occupies 1 and 2 atoms, respectively. In this example, when the combination of the compressed data and the check bit requires more than two atoms, the packing fails. In another example, the packed compression state includes 4:3, which indicates that data occupying four atoms is compressed and, when combined with the check bit, occupies three atoms. Similarly, when the packed compression state includes 4:4, data occupying four atoms is compressed and, when combined with the check bit, occupies four atoms.

[0037] In one embodiment, the number of atoms is a compressed size determined based solely on the compressed data, and packing fails when the combination of the compressed data and the check bits cannot fit within that number. In one embodiment, the number of atoms is the minimum number of atoms in which the compressed data can fit. In one embodiment, when packing fails, the check bits are removed from the combination and transmitted and / or stored separately from the compressed data. When packing fails or ECC packing is not enabled, the unpacked compression states of 4:4, 4:2, 4:3, and 4:4 indicate that data occupying four atoms is compressed into 1, 2, 3, and 4 atoms, respectively.

[0038] Figure 1D A graph of the packing success rate when three packed compression states are supported according to some embodiments of the present disclosure is shown. The horizontal axis represents the number of bytes in the compressed data. The vertical axis represents the occurrence count of various compressed data in the processing workload. The compressed data 130 occupies more than 30 bytes of the 32-byte atom. Assuming that the check bit for each 32-byte data requires 2 bytes, the packing of the compressed data 130 fails. For compressed data that occupies less than 32 bytes (to the left along the horizontal axis), packing is successful in the 4:1 packed compression state. When the compression size can increase the additional atoms, the number of atoms of the compressed data 130 is increased from one to two, and packing is successful in the 4:2 compression state.

[0039] Compressed data 135 occupies more than 60 bytes for two atoms and fails to pack. Similarly, when the compression size can be increased, the number of atoms of compressed data 135 is increased from two to three, and packing is successful in the 4:3 compression state. Compressed data 140 occupies more than 90 bytes for three atoms, so compressed data 140 fails to pack. When the compression size cannot be increased, so that compressed data 130, 135, and 140 are in an unpacked compression state, the packing success rate is 83%.

[0040] Figure 1EA flow chart of a method 150 for packing ECC check bits for compressed data protection suitable for implementing some embodiments of the present disclosure is shown. Each block of the method 150 described herein includes a computational process that can be performed using any combination of hardware, firmware, and / or software. For example, various functions can be implemented by a processor executing instructions stored in a memory. The method can also be implemented as computer-usable instructions stored on a computer storage medium. The method can be provided by, to name a few, a stand-alone application, a service, or a hosted service (stand-alone or in combination with another hosted service), or a plug-in to another product. In addition, the method 150 is provided by way of example with respect to Figure 1A However, in addition or alternatively, the method may be performed by any system, or any combination of systems, including but not limited to those described herein. Furthermore, one of ordinary skill in the art will understand that any system that performs method 150 is within the scope and spirit of the disclosed embodiments.

[0041] At step 155, the compressed data is processed within the processor to calculate ECC check bits. In one embodiment, the ECC quality is fixed so that no additional state information is tracked or stored. In other words, in one embodiment, errors in the compressed data can be detected using only the compression state, the compressed data, and the check bits. In one embodiment, the compressed data is received from an additional device external to the processor. In one embodiment, the compressed data is generated within the processor.

[0042] At step 160, the number of fixed-size storage cells (e.g., atoms) required to store the combination of compressed data and check bits is determined. In one embodiment, the determined number of fixed-size storage cells is the minimum number of fixed-size storage cells within which the entire combination can be accommodated. In one embodiment, the second number of fixed-size storage cells required to store the compressed data without the check bits is less than the number required to store the combination. In one embodiment, an ECC check bit is calculated for a portion of the compressed data in each fixed-size storage cell and combined with the portion of the compressed data in the fixed-size storage cell.

[0043] At step 165, the compressed data and the check digits are combined to the number to produce a combination. At step 170, the combination is transmitted within the processor or to an attached device external to the processor. In one embodiment, the check digits are discarded at the interface with the attached device, and only the compressed data is transmitted from the processor to the attached device. In one embodiment, the combination is stored in a memory device. In one embodiment, the combination is transmitted from the processor to the attached device via an interconnect. In one embodiment, the combination is transmitted via a crossbar interconnect within the processor.

[0044] In one embodiment, a maximum number of fixed-size cells is defined, and when the number is greater than the maximum number, a check bit is removed from the combination. When the check bit is removed, the check bit can be transmitted within the processor or transmitted separately from the compressed data to an attached device. In one embodiment, the compressed data is stored in a first portion of the memory device, and the check bit is stored in a second portion of the memory device separate from the first portion.

[0045] Figure 2A Graphs of failure rates for various packing formats suitable for implementing some embodiments of the present disclosure are shown. Each group of four bars corresponds to a packing failure rate during the execution of one program. The leftmost bar in each group is for the compression states of packing (4:1 and 4:2), and the resulting packing failure rates are less than 50% on average. When packing fails, the check bits are stored separately from the compressed data (e.g., inline ECC). Therefore, the additional access to the separately stored check bits will save more than half the time compared to conventional inline ECC. Adding a 4:3 compression state results in an average packing failure rate of nearly 20%, saving 4 / 5 of the ECC accesses compared to conventional inline ECC.

[0046] The two rightmost bars in each group include the compression state for specialized 4:4 packing. This specialized, just-enough 4:4 packing compression maximizes the packing success rate for marginally compressible data, particularly floating-point data. Marginally compressible data is compressed enough to pack the check bits into the maximum number of atoms, but not enough for bandwidth compression.

[0047] In one embodiment, the dedicated compressor operates with a small 32-byte compression block size to maintain random access to the edge compressible data in a 4:4 packed compressed state comprising four 32-byte blocks. Operating at a smaller block size avoids potential performance degradation in the form of over-fetches during random access at the 32-byte granularity of the edge compressible workload. In one embodiment, the dedicated compressor is included in the data compression unit 110 or in the ECC calculation unit 115. Figure 2A As shown in the figure, 4:4 packing compression state reduces the average packing failure rate to 10% or less. When all four packing compression states are available, as shown in the rightmost bar of each group, the lowest packing failure rate is achieved.

[0048] Figure 2BShown is a block diagram of an example ECC and compressed data correction logic 200 suitable for implementing some embodiments of the present disclosure. It should be understood that this and other arrangements described herein are merely set forth as examples. In addition to or in place of those shown, other arrangements and elements (such as machines, interfaces, functions, sequences, functional groups, etc.) can be used, and some elements can be omitted completely. In addition, many elements in the elements described herein are functional entities that can be implemented as discrete or distributed components or in combination with other components and in any appropriate combination and position. The various functions described herein as being performed by an entity can be implemented by hardware, firmware and / or software. For example, the various functions can be implemented by a processor executing instructions stored in a memory. In addition, it will be understood by those of ordinary skill in the art that any system performing the operation of ECC and compressed data correction logic 200 is within the scope and spirit of the embodiments of the present disclosure.

[0049] like Figure 2B As shown, the ECC calculation unit 215 calculates the ECC check bits for the compressed data portion of the packed data, and the correction unit 205 compares the calculated check bits with the check bit portion of the packed data to detect whether the compressed data is correct or corrupted. The ECC calculation unit 215 and the correction unit 205 each use the compression state of the packed data to separate the compressed data and the check bits as needed. If the correction unit 205 determines that the compressed data is corrupted, the correction unit 205 corrects the compressed data. The correction unit 205 outputs the compressed data to the data decompression unit 210 and the packing unit 220. The correction unit 205 also outputs the check bit portion of the packed data to the packing unit 220.

[0050] Packing unit 220 performs the same operations as packing unit 120, outputting a combined and compressed state. In one embodiment, the packing mode can be changed compared to the packing mode used by packing unit 120. When the packing mode remains unchanged and no corruption is detected by correction unit 205, the packed data received by ECC calculation unit 215 can be selected for output by ECC and compressed data correction logic 200. In one embodiment, data decompression unit 210 is located at the destination point, and the packed data is not transmitted within the processor or to an external attached device, and packing unit 220 is omitted.

[0051] The compression operations performed by the data decompression unit 210 are decoupled from the ECC check bit calculation, correction, and packing operations. The data decompression unit 210 can be in a separate processing unit, with one or more storage and / or transmission circuits between the data compression unit 110 and the correction unit 205. However, to best protect the compressed data, the compressed data should be inspected and corrected as needed at the input of the data decompression unit 210 to ensure that the compressed data is not corrupted between the correction unit and the data decompression unit 210.

[0052] Figure 2C A block diagram of an example system 225 for implementing some embodiments of the present disclosure is shown. The system 225 includes a processor 230 and a memory 235 external to the processor 230, and may include multiple memory devices. The processor 230 includes an interface 254 for at least one additional device 227 external to the processor 230 and an interface 256 for interconnecting with an NVLink 258.

[0053] In addition to units such as interfaces 254 and 256, processor 230 also includes one or more units including storage, such as L2 cache 232 and L1 cache 252, a crossbar 255 interconnect, and / or a processing core or execution core 250. Each unit may include an ECC packing unit 120 and / or may be capable of compressing data and calculating ECC check bits. Each unit may include an ECC packing unit 220 and / or may be capable of detecting and correcting errors in compressed data based on check bits. Each unit may also be configured to decompress the compressed data. Generally speaking, for a particular transaction, any one unit may be a source point that generates packed data, an intermediate point that simply transmits packed data with or without error detection and correction, or a destination point that detects and corrects errors in compressed data (including check bits included in the packed data). The destination point may also decompress the compressed data. Similarly, the source point may also compress the data packed with check bits. The packed data may be stored in memory 235 with or without error detection and correction. For some transactions, the source or destination is external to processor 230 and arrives via NVLink 258. The source and destination points define protected areas for compressed data. Intermediate points for detecting and correcting errors can be used to improve reliability.

[0054] Packed ECC enables timely end-to-end protection within the protection zone. For example, the L2 cache 232 can store packed data and can optionally detect and correct errors. The crossbar switch 255 can transfer packed data between one or more of the L2 cache 232, the L1 cache 252, and the interface 256. The L2 cache 232 can store packed data and optionally detect and correct errors, while also decompressing the compressed data for output to one or more execution cores 250. The L2 cache 232 can also compress and pack data received from one or more execution cores 250. Providing error detection and correction in the L2 cache 232 and the L1 cache 252 fills potential reliability coverage holes within the processor 230 and increases the range of the protection zone across the crossbar switch 255.

[0055] Storing packed data in memory 235 and detecting and correcting errors in L2 cache 232 provides protection for data transferred between memory 235 and processor 230. Detecting and correcting errors at interface 254 provides protection for data transferred between processor 230 and attached devices 227. Similarly, detecting and correcting errors at interface 256 provides protection for data transferred between processor 230 and devices coupled to NVlink 258.

[0056] Figure 2D Another flow chart of a method 260 for packing ECC check bits for compressed data protection suitable for implementing some embodiments of the present disclosure is shown. Each block of the method 260 described herein includes a computational process that can be performed using any combination of hardware, firmware, and / or software. For example, various functions can be implemented by a processor executing instructions stored in a memory. The method can also be embodied as computer-usable instructions stored on a computer storage medium. The method can be provided by, to name a few, a stand-alone application, a service, or a hosted service (stand-alone or in combination with another hosted service), or a plug-in for another product. In addition, the method 260 is provided by way of example with respect to Figure 1A 、 Figure 2B and Figure 2C However, in addition or alternatively, the method may be performed by any system, or any combination of systems, including but not limited to those described herein. Furthermore, one of ordinary skill in the art will appreciate that any system that performs method 260 is within the scope and spirit of the disclosed embodiments.

[0057] Steps 155 and 160 are performed according to the combined method 150 described above. At step 265, the combination of compressed data and check bits is transferred to a storage resource within the processor. In one embodiment, the storage resource within the processor includes a register file and / or memory, such as the L2 cache 232 and L1 cache 252 within processor 230. In one embodiment, the combination is transferred to the storage resource via a crossbar interconnect within the processor. In one embodiment, the storage resource is a source, intermediate, and / or destination point within the processor.

[0058] At step 270, logic at the intermediate or destination point to which the combination is transmitted determines whether the compressed data is corrupted. In one embodiment, this logic includes the ECC calculation unit 215 and the correction unit 205. If the compressed data is corrupted at step 270, then at step 275, the compressed data is corrected using the check bits before proceeding to step 280. At step 280, the combination is stored in the storage resource. In another embodiment, only the compressed data is stored at step 280, and the check bits are discarded. In one embodiment, step 280 is performed before step 270, and any corrupted compressed data stored in the storage resource is overwritten after being corrected. In another embodiment, step 280 is performed before step 270, and any corrupted compressed data stored in the storage resource is corrected when the compressed data is read from the storage resource. In one embodiment, an execution core within a processor receives the combination from the storage resource, determines based on the check bits that the compressed data is corrupted, and corrects the compressed data using the check bits before processing the compressed data.

[0059] In one embodiment, the combination is read from the storage resource and transferred from the processor to an attached device external to the processor. In one embodiment, the attached device determines that the compressed data is corrupted and corrects the compressed data using a check bit before processing and / or storing the combination. In one embodiment, the check bit is discarded at the interface with the attached device, and only the compressed data is transferred from the processor to the attached device. In one embodiment, the combination is transferred from the processor and stored in a memory device external to the processor. In one embodiment, the check bit is discarded at the interface with the memory device, and only the compressed data is transferred from the processor to the memory device.

[0060] Compared to inline ECC implementations, packing the check bits with the compressed data avoids or significantly reduces dedicated check bit storage in external memory and dedicated write and read requests for the check bits. By transmitting a combination of compressed data and check bits between different processing units, storage resources, and devices, protection can be extended within the processor and between independent devices. As a result, reliability holes are filled even in the interconnect structure within the processor and between devices. For data that cannot be fully compressed, inline ECC protection can be used while still benefiting from the efficiency of packing other data that can be fully compressed. In summary, packed ECC reduces memory bandwidth consumption and power while improving reliability and performance.

[0061] Parallel processing architecture

[0062] Figure 3 FIG2 shows a parallel processing unit (PPU) 300 according to one embodiment. The PPU 300 may include one or more ECC and compressed data packing logic 100 or ECC and compressed data correction logic 200. The PPU 300 may include one or more data compression unit 110, ECC compression units 115 and 215, packing units 120 and 220, correction unit 205, or data decompression unit 210. The PPU 300 may be configured to implement Figure 1E and Figure 2D Method 150 or 260 shown.

[0063] In one embodiment, a processor such as PPU 300 may be configured to implement a neural network model. The neural network model may be implemented as software instructions executed by the processor, or in other embodiments, the processor may include a matrix of hardware elements configured to process a set of inputs (e.g., electrical signals representing values) to generate a set of outputs, which may represent activations of the neural network model. In other embodiments, the neural network model may be implemented as a combination of processing performed by the matrix of hardware elements and software instructions. Implementing the neural network model may include determining a set of parameters for the neural network model through, for example, supervised or unsupervised training of the neural network model, and, alternatively, performing inference using the parameter set to process a new set of inputs.

[0064] In one embodiment, the PPU 300 is a multi-threaded processor implemented on one or more integrated circuit devices. The PPU 300 is a latency-hiding architecture designed to process many threads in parallel. A thread (e.g., an execution thread) is an instantiation of an instruction set configured to be executed by the PPU 300. In one embodiment, the PPU 300 is a graphics processing unit (GPU) configured to implement a graphics rendering pipeline for processing three-dimensional (3D) graphics data to generate two-dimensional (2D) image data for display on a display device such as a liquid crystal display (LCD). In other embodiments, the PPU 300 can be used to perform general-purpose computations. Although an exemplary parallel processor is provided herein for illustrative purposes, it should be specifically noted that such a processor is described for illustrative purposes only and that any processor may be used in addition to and / or in place of the processor.

[0065] One or more PPUs 300 can be configured to accelerate thousands of high-performance computing (HPC), data center, cloud computing, and machine learning applications. A PPU 300 can be configured to accelerate numerous deep learning systems and applications for autonomous vehicles, simulations, computational graphics such as ray or path tracing, deep learning, high-precision speech, image, and text recognition systems, intelligent video analysis, molecular simulations, drug discovery, disease diagnosis, weather forecasting, big data analysis, astronomy, molecular dynamics simulations, financial modeling, robotics, factory automation, real-time language translation, online search optimization, and personalized user recommendations, among others.

[0066] like Figure 3 As shown, the PPU 300 includes an input / output (I / O) unit 305, a front-end unit 315, a scheduler unit 320, a work distribution unit 325, a hub 330, a crossbar switch (Xbar) 370, one or more general processing clusters (GPCs) 350, and one or more memory partitioning units 380. The PPU 300 can be connected to a host processor or other PPUs 300 via one or more high-speed NVLink 310 interconnects. The PPU 300 can be connected to a host processor or other peripheral devices via interconnect 302. The PPU 300 can also be connected to a local memory 304 including multiple memory devices. In one embodiment, the local memory can include multiple dynamic random access memory (DRAM) devices. The DRAM devices can be configured as a high-bandwidth memory (HBM) subsystem, in which multiple DRAM dies are stacked within each device.

[0067] The NVLink 310 interconnect enables the system to scale and include one or more PPUs 300 in conjunction with one or more CPUs, supporting cache coherency between the PPU 300 and the CPU, and CPU mastering. Data and / or commands can be sent by the NVLink 310 through the hub 330 to or from other units of the PPU 300, such as one or more copy engines, video encoders, video decoders, power management units, etc. (not explicitly shown). Figure 5A NVLink 310 is described in more detail.

[0068] I / O unit 305 is configured to send and receive communications (e.g., commands, data, etc.) from a host processor (not shown) via interconnect 302. I / O unit 305 can communicate with the host processor directly via interconnect 302, or through one or more intermediary devices such as a memory bridge. In one embodiment, I / O unit 305 can communicate with one or more other processors, such as one or more PPUs 300, via interconnect 302. In one embodiment, I / O unit 305 implements a Peripheral Component Interconnect Express (PCIe) interface for communicating over a PCIe bus, and interconnect 302 is a PCIe bus. In alternative embodiments, I / O unit 305 can implement other types of known interfaces for communicating with external devices.

[0069] I / O unit 305 decodes data packets received via interconnect 302. In one embodiment, the data packets represent commands configured to cause PPU 300 to perform various operations. I / O unit 305 transmits the decoded commands to various other units of PPU 300 as directed by the commands. For example, some commands may be transmitted to front end unit 315. Other commands may be transmitted to hub 330 or other units of PPU 300, such as one or more copy engines, video encoders, video decoders, power management units, etc. (not explicitly shown). In other words, I / O unit 305 is configured to route communications between and among the various logical units of PPU 300.

[0070] In one embodiment, a program executed by a host processor encodes a command stream in a buffer that provides a workload to PPU 300 for processing. The workload may include several instructions and the data to be processed by those instructions. A buffer is an area of ​​memory that is accessible (e.g., read / write) by both the host processor and PPU 300. For example, I / O unit 305 may be configured to access a buffer in system memory connected to interconnect 302 via a memory request transmitted over interconnect 302. In one embodiment, the host processor writes a command stream into a buffer and then transmits a pointer to the start of the command stream to PPU 300. Front end unit 315 receives pointers to one or more command streams. Front end unit 315 manages the one or more streams, reading commands from these streams and forwarding the commands to the various units of PPU 300.

[0071] The front-end unit 315 is coupled to a scheduler unit 320, which configures the various GPCs 350 to process the tasks defined by the one or more streams. The scheduler unit 320 is configured to track status information related to the various tasks managed by the scheduler unit 320. The status may indicate which GPC 350 the task is assigned to, whether the task is active or inactive, the priority associated with the task, etc. The scheduler unit 320 manages the execution of multiple tasks on the one or more GPCs 350.

[0072] Scheduler unit 320 is coupled to work distribution unit 325, which is configured to dispatch tasks for execution on GPCs 350. Work distribution unit 325 can track a number of scheduled tasks received from scheduler unit 320. In one embodiment, work distribution unit 325 manages a pending task pool and an active task pool for each GPC 350. The pending task pool may include a number of slots (e.g., 32 slots) that contain tasks assigned to be processed by a particular GPC 350. The active task pool may include a number of slots for tasks actively being processed by GPC 350. When a GPC 350 completes execution of a task, the task is evicted from the active task pool of GPC 350, and one of the other tasks from the pending task pool is selected and scheduled for execution on GPC 350. If an active task on GPC 350 has become idle, such as while waiting for a data dependency to be resolved, the active task may be evicted from GPC 350 and returned to the pending task pool, while another task in the pending task pool is selected and scheduled for execution on GPC 350 .

[0073] Work distribution unit 325 communicates with one or more GPCs 350 via XBar (crossbar) 370. XBar 370 is an interconnect network that couples many units of PPU 300 to other units of PPU 300. For example, XBar 370 can be configured to couple work distribution unit 325 to a specific GPC 350. Although not explicitly shown, one or more other units of PPU 300 can also be connected to XBar 370 via hub 330.

[0074] Tasks are managed by the scheduler unit 320 and dispatched to the GPCs 350 by the work distribution unit 325. The GPCs 350 are configured to process tasks and generate results. The results can be consumed by other tasks within the GPC 350, routed to a different GPC 350 via the XBar 370, or stored in the memory 304. The results can be written to the memory 304 via the memory partition unit 380, which implements a memory interface for reading data from and writing data to the memory 304. The results can be transferred to another PPU 300 or CPU via NVLink 310. In one embodiment, the PPU 300 includes a number U of memory partition units 380, which is equal to the number of independent and distinct memory devices coupled to the memory 304 of the PPU 300. Figure 4B The memory partition unit 380 is described in more detail.

[0075] In one embodiment, the host processor executes a driver kernel that implements an application programming interface (API) that enables one or more applications to be executed on the host processor to schedule operations for execution on the PPU 300. In one embodiment, multiple computing applications are executed simultaneously by the PPU 300, and the PPU 300 provides isolation, quality of service (QoS), and independent address spaces for the multiple computing applications. The application can generate instructions (e.g., API calls) that cause the driver kernel to generate one or more tasks to be executed by the PPU 300. The driver kernel outputs the tasks to one or more streams being processed by the PPU 300. Each task can include one or more related groups of threads, referred to herein as warps. In one embodiment, a warp includes 32 related threads that can execute in parallel. Collaborating threads can refer to multiple threads that include instructions to perform tasks and that can exchange data through shared memory. In combination Figure 4C Describes threads and cooperative threads in more detail.

[0076] Figure 4A According to one embodiment, Figure 3 PPU 300 GPC 350. Figure 4A As shown, each GPC 350 includes multiple hardware units for processing tasks. In one embodiment, each GPC 350 includes a pipeline manager 410, a pre-raster operation unit (PROP) 415, a raster engine 425, a work distribution crossbar (WDX) 480, a memory management unit (MMU) 490, and one or more data processing clusters (DPCs) 420. It should be understood that Figure 4A The GPC 350 may include instead Figure 4A Other hardware units or other than the units shown in Figure 4A Other hardware units besides those shown in .

[0077] In one embodiment, the operation of GPC 350 is controlled by pipeline manager 410. Pipeline manager 410 manages the configuration of one or more DPCs 420 for processing tasks assigned to GPC 350. In one embodiment, pipeline manager 410 can configure at least one of one or more DPCs 420 to implement at least a portion of a graphics rendering pipeline. For example, DPC 420 can be configured to execute vertex shading programs on programmable streaming multiprocessors (SMs) 440. Pipeline manager 410 can also be configured to route packets received from work distribution unit 325 to appropriate logic units within GPC 350. For example, some packets can be routed to fixed-function hardware units within PROP 415 and / or raster engine 425, while other packets can be routed to DPC 420 for processing by primitive engine 435 or SM 440. In one embodiment, pipeline manager 410 can configure at least one of one or more DPCs 420 to implement a neural network model and / or a compute pipeline.

[0078] PROP unit 415 is configured to route data generated by raster engine 425 and DPC 420 to the raster operations (ROP) unit, in conjunction with Figure 4B The PROP unit 415 may also be configured to perform optimizations for color blending, organize pixel data, perform address translation, and the like.

[0079] The raster engine 425 includes several fixed-function hardware units configured to perform various raster operations. In one embodiment, the raster engine 425 includes a setup engine, a coarse raster engine, a culling engine, a clipping engine, a fine raster engine, and a tile aggregation engine. The setup engine receives the transformed vertices and generates plane equations associated with the geometric primitives defined by the vertices. The plane equations are sent to the coarse raster engine to generate coverage information for the primitives (e.g., the x, y coverage mask of the tile). The output of the coarse raster engine is sent to the culling engine, where fragments associated with primitives that fail the z-test are culled, and to the clipping engine, where fragments outside the viewing frustum are clipped. Those fragments remaining after clipping and culling can be passed to the fine raster engine to generate attributes for the pixel fragments based on the plane equations generated by the setup engine. The output of the raster engine 425 includes, for example, fragments to be processed by the fragment shader implemented in the DPC 420.

[0080] Each DPC 420 included in the GPC 350 includes an M pipeline controller (MPC) 430, a primitive engine 435, and one or more SMs 440. The MPC 430 controls the operation of the DPC 420 and routes packets received from the pipeline manager 410 to appropriate units in the DPC 420. For example, packets associated with vertices may be routed to the primitive engine 435, which is configured to fetch vertex attributes associated with the vertices from the memory 304. Conversely, packets associated with shading programs may be sent to the SM 440.

[0081] SM 440 includes a programmable streaming processor configured to process tasks represented by multiple threads. Each SM 440 is multi-threaded and configured to simultaneously execute multiple threads (e.g., 32 threads) from a particular thread group. In one embodiment, SM 440 implements a SIMD (single instruction, multiple data) architecture, in which each thread in a thread group (e.g., a warp) is configured to process a different data set based on the same instruction set. All threads in a thread group execute the same instructions. In another embodiment, SM 440 implements a SIMT (single instruction, multiple thread) architecture, in which each thread in a thread group is configured to process a different data set based on the same instruction set, but in which individual threads in a thread group are allowed to diverge during execution. In one embodiment, a program counter, call stack, and execution state are maintained for each warp, enabling concurrency between warps and serial execution within warps when threads within the warp diverge. In another embodiment, a program counter, call stack, and execution state are maintained for each individual thread, thereby achieving equal concurrency between all threads within and between warps. When execution state is maintained for each individual thread, threads executing the same instruction can be converged and executed in parallel for maximum efficiency. Figure 4C Describe SM440 in more detail.

[0082] MMU 490 provides an interface between GPC 350 and memory partition unit 380. MMU 490 can provide virtual to physical address translation, memory protection, and arbitration of memory requests. In one embodiment, MMU 490 provides one or more translation lookaside buffers (TLBs) for performing translations from virtual addresses to physical addresses in memory 304.

[0083] Figure 4B According to one embodiment, Figure 3 The memory partition unit 380 of the PPU 300. Figure 4B As shown, the memory partition unit 380 includes a raster operations (ROP) unit 450, a level 2 (L2) cache 460, and a memory interface 470. The memory interface 470 is coupled to the memory 304. The memory interface 470 can implement a 32-, 64-, 128-, or 1024-bit data bus for high-speed data transfer. In one embodiment, the PPU 300 incorporates U memory interfaces 470, one for each pair of memory partition units 380, where each pair of memory partition units 380 is connected to a corresponding memory device of the memory 304. For example, the PPU 300 can be connected to up to Y memory devices, such as a high-bandwidth memory stack or graphics double data rate version 5 synchronous dynamic random access memory or other types of persistent memory.

[0084] In one embodiment, memory interface 470 implements an HBM2 memory interface, and Y is equal to half of U. In one embodiment, the HBM2 memory stack is located on the same physical package as PPU 300, providing significant power and area savings compared to conventional GDDR5 SDRAM systems. In one embodiment, each HBM2 stack includes four memory dies and Y is equal to 4, where the HBM2 stack includes two 128-bit channels per die, for a total of 8 channels and a data bus width of 1024 bits.

[0085] In one embodiment, memory 304 supports single-error correction, double-error detection (SECDED) ECC to protect data. ECC provides increased reliability for computing applications that are sensitive to data corruption. Reliability is particularly important in large cluster computing environments where PPU 300 processes very large data sets and / or long-running applications.

[0086] In one embodiment, the PPU 300 implements a multi-level memory hierarchy. In one embodiment, the memory partitioning unit 380 supports unified memory to provide a single, unified virtual address space for the CPU and PPU 300 memory, enabling data sharing between virtual memory systems. In one embodiment, the frequency of PPU 300 accesses to memory located on other processors is tracked to ensure that memory pages are moved to the physical memory of the PPU 300 where the pages are accessed more frequently. In one embodiment, NVLink 310 supports address translation services that allow the PPU 300 to directly access the CPU's page tables and provide full access to the CPU's memory by the PPU 300.

[0087] In one embodiment, the copy engine transfers data between multiple PPUs 300 or between a PPU 300 and a CPU. The copy engine can generate a page fault for an address that is not mapped to a page table. The memory partition unit 380 can then service the page fault, map the address into a page table, and then the copy engine can perform the transfer. In conventional systems, multiple copy engines operate on fixed memory (e.g., non-pageable) between multiple processors, which significantly reduces the available memory. Due to hardware page faults, addresses can be passed to the copy engine without worrying about whether the memory page is resident, and the copy process is transparent.

[0088] Data from memory 304 or other system memory can be retrieved by memory partition unit 380 and stored in L2 cache 460, which is located on-chip and shared between various GPCs 350. As shown, each memory partition unit 380 includes a portion of L2 cache 460 associated with the corresponding memory 304. Lower-level caches can then be implemented in multiple units within a GPC 350. For example, each SM 440 can implement a level 1 (L1) cache. The L1 cache is a dedicated memory dedicated to a particular SM 440. Data from the L2 cache 460 can be retrieved and stored in each L1 cache for processing in the functional units of the SM 440. The L2 cache 460 is coupled to the memory interface 470 and the XBar 370.

[0089] The ROP unit 450 performs graphics raster operations related to pixel color such as color compression, pixel blending, etc. The ROP unit 450 also implements depth testing in conjunction with the raster engine 425, receiving the depth of the sample position associated with the pixel fragment from the culling engine of the raster engine 425. The depth of the sample position associated with the fragment is tested against the corresponding depth in the depth buffer. If the fragment passes the depth test for the sample position, the ROP unit 450 updates the depth buffer and sends the result of the depth test to the raster engine 425. It will be understood that the number of memory partition units 380 can be different than the number of GPCs 350, and therefore each ROP unit 450 can be coupled to each GPC 350. The ROP unit 450 tracks packets received from different GPCs 350 and determines to which GPC 350 the results generated by the ROP unit 450 are routed via the Xbar 370. Although in Figure 4B In the embodiment shown, ROP unit 450 is included within memory partition unit 380, but in other embodiments, ROP unit 450 may be external to memory partition unit 380. For example, ROP unit 450 may reside in GPC 350 or another unit.

[0090] Figure 4C According to one embodiment, Figure 4A Streaming multiprocessor 440. Figure 4C As shown, the SM 440 includes an instruction cache 405, one or more (K) scheduler units 445, a register file 455, one or more processing cores 442, one or more special function units (SFUs) 452, one or more load / store units (LSUs) 454, an interconnect network 458, and a shared memory / L1 cache 465.

[0091] As described above, the work distribution unit 325 schedules tasks for execution on the GPCs 350 of the PPU 300. Tasks are assigned to specific DPCs 420 within the GPC 350 and, if the task is associated with a shader program, may be assigned to an SM 440. The scheduler unit 445 receives tasks from the work distribution unit 325 and manages the scheduling of instructions for one or more thread blocks assigned to the SM 440. The scheduler unit 445 schedules thread blocks for execution as warps of parallel threads, where each thread block is assigned at least one warp. In one embodiment, each warp executes 32 threads. The scheduler unit 445 can manage multiple different thread blocks, assign warps to different thread blocks, and then dispatch instructions from multiple different cooperative groups to various functional units (i.e., cores 442, SFUs 452, and LSUs 454) during each clock cycle.

[0092] Cooperative Groups is a programming model for organizing groups of communicating threads that allows developers to express the granularity at which threads are communicating, enabling the expression of richer and more efficient decompositions of parallelism. The cooperative launch API supports synchronization between thread blocks to execute parallel algorithms. Conventional programming models provide a single, simple construct for synchronizing cooperating threads: a barrier across all threads of a thread block (e.g., the syncthreads() function). However, programmers often want to define thread groups at a granularity smaller than the thread block granularity and synchronize within the defined group, enabling higher performance, design flexibility, and software reuse in the form of a collective group-wide function interface.

[0093] Cooperative Groups enable programmers to explicitly define thread groups at sub-block (e.g., as small as a single thread) and multi-block granularity and perform collective operations, such as synchronization, on threads in a cooperative group. The programming model supports clean composition across software boundaries so that libraries and utility functions can safely synchronize in their local environment without making assumptions about convergence. Cooperative Group primitives enable new patterns of cooperative parallelism, including producer-consumer parallelism, opportunistic parallelism, and global synchronization across the entire grid of thread blocks.

[0094] The dispatch unit 448 is configured to deliver instructions to one or more functional units. In this embodiment, the scheduler unit 445 includes two dispatch units 448, which enable scheduling two different instructions from the same warp during each clock cycle. In alternative embodiments, each scheduler unit 445 may include a single dispatch unit 448 or additional dispatch units 448.

[0095] Each SM 440 includes a register file 455 that provides a set of registers for the functional units of SM 440. In one embodiment, register file 455 is divided between each functional unit so that each functional unit is allocated a dedicated portion of register file 455. In another embodiment, register file 455 is divided between the different warps executed by SM 440. Register file 455 provides temporary storage for operands connected to the data paths of the functional units.

[0096] Each SM 440 includes L processing cores 442. In one embodiment, SM 440 includes a large number (e.g., 128, etc.) of different processing cores 442. Each core 442 may include a fully pipelined, single-precision, double-precision, and / or mixed-precision processing unit, including a floating-point arithmetic logic unit (FLU) and an integer arithmetic logic unit (ALU). In one embodiment, the FLU implements the IEEE 754-2008 standard for floating-point operations. In one embodiment, cores 442 include 64 single-precision (32-bit) floating-point cores, 64 integer cores, 32 double-precision (64-bit) floating-point cores, and 8 tensor cores.

[0097] Tensor cores are configured to perform matrix operations, and in one embodiment, one or more tensor cores are included in core 442. Specifically, the tensor cores are configured to perform deep learning matrix operations, such as convolution operations for neural network training and inference. In one embodiment, each tensor core operates on a 4×4 matrix and performs a matrix multiplication and accumulation operation D=A×B+C, where A, B, C, and D are 4×4 matrices.

[0098] In one embodiment, the matrix multiplication inputs A and B are 16-bit floating point matrices, while the accumulation matrices C and D can be 16-bit floating point or 32-bit floating point matrices. The tensor cores operate on 16-bit floating point input data as well as 32-bit floating point accumulations. The 16-bit floating point multiplication requires 64 operations to produce a full-precision product, which is then accumulated using 32-bit floating point additions with other intermediate products of the 4×4×4 matrix multiplication. In practice, tensor cores are used to perform larger two-dimensional or higher-dimensional matrix operations built from these smaller elements. APIs (such as the CUDA9 C++ API) expose specialized matrix load, matrix multiplication and accumulation, and matrix store operations to efficiently use tensor cores from CUDA-C++ programs. At the CUDA level, the warp-level interface assumes that the 16×16 size matrix spans all 32 threads of the warp.

[0099] Each SM 440 also includes M SFUs 452 that perform special functions (e.g., attribute evaluation, reciprocal square root, etc.). In one embodiment, the SFUs 452 may include a tree traversal unit configured to traverse a hierarchical tree data structure. In one embodiment, the SFUs 452 may include a texture unit configured to perform texture map filtering operations. In one embodiment, the texture unit is configured to load a texture map (e.g., a 2D array of texels) from memory 304 and sample the texture map to generate sampled texture values ​​for use in shader programs executed by the SM 440. In one embodiment, the texture map is stored in shared memory / L1 cache 465. The texture unit implements texture operations, such as filtering operations using mip maps (i.e., texture maps at different levels of detail). In one embodiment, each SM 440 includes two texture units.

[0100] Each SM 440 also includes N LSUs 454, which implement load and store operations between the shared memory / L1 cache 465 and the register file 455. Each SM 440 includes an interconnect network 458 that connects each functional unit to the register file 455 and the shared memory / L1 cache 465. In one embodiment, the interconnect network 458 is a crossbar switch that can be configured to connect any functional unit to any register in the register file 455 and a memory location in the shared memory / L1 cache 465.

[0101] Shared memory / L1 cache 465 is an on-chip memory array that allows data storage and communication between SM 440 and primitive engine 435, as well as between threads in SM 440. In one embodiment, shared memory / L1 cache 465 includes 128KB of storage capacity and is in the path from SM 440 to memory partition unit 380. Shared memory / L1 cache 465 can be used to cache reads and writes. One or more of shared memory / L1 cache 465, L2 cache 460, and memory 304 are backing stores.

[0102] Combining data cache and shared memory functionality into a single memory block provides the best overall performance for both types of memory access. This capacity can be used by programs as a cache that does not utilize the shared memory. For example, if the shared memory is configured to use half of its capacity, texture and load / store operations can use the remaining capacity. Integration within shared memory / L1 cache 465 enables shared memory / L1 cache 465 to function as a high-throughput pipeline for streaming data, while providing high-bandwidth and low-latency access to frequently reused data.

[0103] When configured for general parallel computing, a simpler configuration can be used compared to graphics processing. Specifically, Figure 3 The fixed-function graphics processing unit is shown bypassed, creating a simpler programming model. In a general-purpose parallel computing configuration, work distribution unit 325 assigns and distributes thread blocks directly to DPC 420. The threads in the block execute the same program, using unique thread IDs in computations to ensure each thread produces unique results, using SM 440 to execute the program and perform computations, using shared memory / L1 cache 465 to communicate between threads, and using LSU 454 to read and write global memory through shared memory / L1 cache 465 and memory partition unit 380. When configured for general-purpose parallel computing, SM 440 can also write commands that scheduler unit 320 can use to start new work on DPC 420.

[0104] The PPU 300 may be included in a desktop computer, a laptop computer, a tablet computer, a server, a supercomputer, a smartphone (e.g., wireless, handheld device), a personal digital assistant (PDA), a digital camera, a vehicle, a head-mounted display, a handheld electronic device, etc. In one embodiment, the PPU 300 is included on a single semiconductor substrate. In another embodiment, the PPU 300 is included on a system-on-chip (SoC) along with one or more other devices (such as an additional PPU 300, a memory 304, a reduced instruction set computer (RISC) CPU, a memory management unit (MMU), a digital-to-analog converter (DAC), etc.).

[0105] In one embodiment, PPU 300 may be included on a graphics card that includes one or more memory devices. The graphics card may be configured to interface with a PCIe slot on a desktop computer's motherboard. In another embodiment, PPU 300 may be an integrated graphics processing unit (iGPU) or parallel processor included in a chipset on the motherboard.

[0106] Exemplary Computing System

[0107] Systems with multiple GPUs and CPUs are being used across various industries as developers expose and exploit greater parallelism in applications such as artificial intelligence computing. High-performance GPU-accelerated systems with tens to thousands of computing nodes are deployed in data centers, research institutions, and supercomputers to solve larger problems. As the number of processing devices within high-performance systems increases, communication and data transmission mechanisms need to scale to support this increased bandwidth.

[0108] Figure 5A According to one embodiment, the Figure 3Conceptual diagram of a processing system 500 implemented by a PPU 300. Exemplary systems 565 may be configured to implement Figure 1E and Figure 2D The processing system 500 includes a CPU 530, a switch 510, and a plurality of PPUs 300 and corresponding memories 304.

[0109] Each PPU 300 may include, and / or be configured to perform the functions of one or more processing cores and / or components thereof, such as a tensor core (TC), a tensor processing unit (TPU), a pixel vision core (PVC), a vision processing unit (VPU), a graphics processing cluster (GPC), a texture processing cluster (TPC), a streaming multiprocessor (SM), a tree traversal unit (TTU), an artificial intelligence accelerator (AIA), a deep learning accelerator (DLA), an arithmetic logic unit (ALU), an application-specific integrated circuit (ASIC), a floating point unit (FPU), an input / output (I / O) element, a peripheral component interconnect (PCI) or a peripheral component interconnect express (PCIe) element, and the like.

[0110] NVLink 310 provides a high-speed communication link between each PPU 300. Figure 5A A specific number of NVLink 310 and interconnect 302 connections are shown, but the number of connections connected to each PPU 300 and CPU 530 can vary. Switch 510 interfaces between interconnect 302 and CPU 530. PPU 300, memory 304, and NVLink 310 can be located on a single semiconductor platform to form a parallel processing module 525 (also referred to as parallel processing system 525). In one embodiment, switch 510 supports two or more protocols that interface between various different connections and / or links.

[0111] In another embodiment (not shown), NVLink 310 provides one or more high-speed communication links between each PPU 300 and the CPU 530, and the switch 510 interfaces between the interconnect 302 and each PPU 300. The PPUs 300, memory 304, and interconnect 302 may be located on a single semiconductor platform to form a parallel processing module 525. In yet another embodiment (not shown), the interconnect 302 provides one or more communication links between each PPU 300 and the CPU 530, and the switch 510 interfaces between each PPU 300 using NVLink 310 to provide one or more high-speed communication links between the PPUs 300. In another embodiment (not shown), NVLink 310 provides one or more high-speed communication links between the PPUs 300 and the CPU 530 through the switch 510. In yet another embodiment (not shown), the interconnect 302 provides one or more communication links directly between each PPU 300. One or more NVLink 310 high-speed communication links may be implemented as a physical NVLink interconnect or as an on-chip or on-die interconnect using the same protocol as NVLink 310 .

[0112] In the context of this specification, a single semiconductor platform may refer to a unique, single semiconductor-based integrated circuit fabricated on a die or chip. It should be noted that the term single semiconductor platform may also refer to a multi-chip module with increased connectivity that emulates on-chip operation and is substantially improved by utilizing conventional bus implementations. Of course, various circuits or devices may also be placed separately or in various combinations of semiconductor platforms, depending on the needs of the user. Alternatively, the parallel processing module 525 may be implemented as a circuit board substrate, and each of the PPU 300 and / or memory 304 may be a packaged device. In one embodiment, the CPU 530, switch 510, and parallel processing module 525 are located on a single semiconductor platform.

[0113] In one embodiment, the signaling rate of each NVLink 310 is 20 to 25 Gbit / s, and each PPU 300 includes six NVLink 310 interfaces (e.g., Figure 5A As shown, each PPU 300 includes five NVLink 310 interfaces. Each NVLink 310 provides a data transfer rate of 25 Gbit / s in each direction, with six links providing 300 Gbit / s. When the CPU 530 also includes one or more NVLink 310 interfaces, the NVLink 310 can be used exclusively for Figure 5A PPU to PPU communication shown, or some combination of PPU to PPU and PPU to CPU.

[0114] In one embodiment, NVLink 310 allows direct load / store / atomic access from the CPU 530 to the memory 304 of each PPU 300. In one embodiment, NVLink 310 supports coherency operations, allowing data read from memory 304 to be stored in the cache hierarchy of the CPU 530, reducing cache access latency for the CPU 530. In one embodiment, NVLink 310 includes support for Address Translation Services (ATS), allowing the PPU 300 to directly access page tables within the CPU 530. One or more NVLinks 310 can also be configured to operate in a low-power mode.

[0115] Figure 5B An exemplary system 565 is shown in which various architectures and / or functionalities of various previous embodiments may be implemented. The exemplary system 565 may be configured to implement Figure 1E and Figure 2D Method 150 or 260 shown in .

[0116] As shown, a system 565 is provided that includes at least one central processing unit 530 connected to a communication bus 575. The communication bus 575 can directly or indirectly couple one or more of the following devices: main memory 540, network interface 535, CPU 530, display device 545, input device 560, switch 510, and parallel processing system 525. The communication bus 575 can be implemented using any suitable protocol and can represent one or more links or buses, such as an address bus, a data bus, a control bus, or a combination thereof. The communication bus 575 can include one or more bus or link types, such as an Industry Standard Architecture (ISA) bus, an Extended Industry Standard Architecture (EISA) bus, a Video Electronics Standards Association (VESA) bus, a Peripheral Component Interconnect (PCI) bus, a Peripheral Component Interconnect Express (PCIe) bus, HyperTransport, and / or another type of bus or link. In some embodiments, there are direct connections between components. As an example, the CPU 530 can be directly connected to the main memory 540. Additionally, the CPU 530 can be directly connected to the parallel processing system 525. Where there is a direct or point-to-point connection between components, communication bus 575 may include a PCIe link to implement the connection. In these examples, a PCI bus need not be included in system 565.

[0117] Although the lines Figure 5BThe different blocks of 525 are shown as being connected via a communication bus 575, but this is not intended to be limiting and is provided for clarity. For example, in some embodiments, presentation components such as display device 545 may be considered I / O components, such as input device 560 (e.g., if the display is a touch screen). As another example, CPU 530 and / or parallel processing system 525 may include memory (e.g., main memory 540 may represent a storage device in addition to parallel processing system 525, CPU 530, and / or other components). In other words, Figure 5B The term computing device is illustrative only. No distinction is made between categories such as "workstation," "server," "laptop," "desktop," "tablet," "client device," "mobile device," "handheld device," "game console," "electronic control unit (ECU)," "virtual reality system," and / or other device or system types, as all are expected to be in the Figure 5B within the range of computing devices.

[0118] The system 565 also includes a main memory 540. Control logic (software) and data are stored in the main memory 540, which can take the form of a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the system 565. Computer-readable media can include volatile and non-volatile media and removable and non-removable media. By way of example and not limitation, computer-readable media can include computer storage media and communication media.

[0119] Computer storage media may include volatile and nonvolatile media and / or removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, and / or other data types. For example, main memory 540 may store computer-readable instructions (e.g., representing programs and / or program elements) such as an operating system. Computer storage media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by system 565. As used herein, computer storage media does not include the signals themselves.

[0120] Computer storage media may embody computer-readable instructions, data structures, program modules, or other data types in a modulated data signal such as a carrier wave or other transport mechanism, and include any information delivery media. The term "modulated data signal" may refer to a signal that has one or more of its characteristics set or changed in such a manner as to encode information into the signal. By way of example and not limitation, computer storage media may include wired media such as a wired network or a direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0121] When executed, the computer program enables the system 565 to perform various functions. The CPU 530 can be configured to execute at least some of the computer-readable instructions to control one or more components of the system 565 to perform one or more of the methods and / or processes described herein. Each of the CPUs 530 can include one or more cores (e.g., one, two, four, eight, twenty-eight, seventy-two, etc.) capable of processing numerous software threads simultaneously. Depending on the type of system 565 implemented, the CPU 530 can include any type of processor, and can include different types of processors (e.g., a processor with fewer cores for mobile devices, and a processor with more cores for servers). For example, depending on the type of system 565, the processor can be an Advanced RISC Machine (ARM) processor implemented using Reduced Instruction Set Computing (RISC) or an x86 processor implemented using Complex Instruction Set Computing (CISC). In addition to one or more microprocessors or supplementary coprocessors such as mathematical coprocessors, the system 565 can include one or more CPUs 530.

[0122] In addition to or in lieu of the CPU 530, the parallel processing module 525 can be configured to execute at least some of the computer-readable instructions to control one or more components of the system 565 to perform one or more of the methods and / or processes described herein. The parallel processing module 525 can be used by the system 565 to render graphics (e.g., 3D graphics) or perform general-purpose computations. For example, the parallel processing module 525 can be used for general-purpose computations on a GPU (GPGPU). In embodiments, the CPU 530 and / or the parallel processing module 525 can perform any combination of the methods, processes, and / or portions thereof, either separately or in conjunction.

[0123] System 565 also includes input device 560, parallel processing system 525, and display device 545. Display device 545 may include a display (e.g., a monitor, a touch screen, a television screen, a head-up display (HUD), other display types, or a combination thereof), speakers, and / or other presentation components. Display device 545 may receive data from other components (e.g., parallel processing system 525, CPU 530, etc.) and output the data (e.g., images, video, sound, etc.).

[0124] The network interface 535 can enable the system 565 to be logically coupled to other devices, including input devices 560, display devices 545, and / or other components, some of which can be embedded in (e.g., integrated into) the system 565. Illustrative input devices 560 include microphones, mice, keyboards, joysticks, game pads, game controllers, satellite dishes, scanners, printers, wireless devices, and the like. The input devices 560 can provide a natural user interface (NUI) that processes user-generated mid-air gestures, voice, or other physiological input. In some instances, the input can be transmitted to an appropriate network element for further processing. The NUI can implement voice recognition, stylus recognition, facial recognition, biometric recognition, gesture recognition on and adjacent to the screen, mid-air gestures, head and eye tracking, and touch recognition associated with the display of the system 565 (as described in more detail below). The system 565 can include a depth camera for gesture detection and recognition, such as a stereo camera system, an infrared camera system, an RGB camera system, touch screen technology, and combinations thereof. Additionally, system 565 may include an accelerometer or gyroscope (e.g., as part of an inertial measurement unit (IMU)) to enable motion detection. In some examples, the output of the accelerometer or gyroscope may be used by system 565 to render immersive augmented or virtual reality.

[0125] In addition, the system 565 can be coupled to a network (e.g., a telecommunications network, a local area network (LAN), a wireless network, a wide area network (WAN) such as the Internet, a peer-to-peer network, a cable network, etc.) for communication purposes through the network interface 535. The system 565 can be included in a distributed network and / or cloud computing environment.

[0126] The network interface 535 may include one or more receivers, transmitters, and / or transceivers that enable the system 565 to communicate with other computing devices via an electronic communication network including wired and / or wireless communications. The network interface 535 may include components and functionality that enable communication over any of a number of different networks, such as wireless networks (e.g., Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), wired networks (e.g., communication over Ethernet or InfiniBand), low-power wide-area networks (e.g., LoRaWAN, SigFox, etc.), and / or the Internet.

[0127] The system 565 may also include an auxiliary storage device (not shown). The auxiliary storage device 610 includes, for example, a hard disk drive and / or a removable storage drive representing a floppy disk drive, a magnetic tape drive, a compact disk drive, a digital versatile disk (DVD) drive, a recording device, or a universal serial bus (USB) flash memory. The removable storage drive reads from and / or writes to the removable storage unit in a well-known manner. The system 565 may also include a hardwired power supply, a battery power supply, or a combination thereof (not shown). The power supply can provide power to the system 565 to enable the components of the system 565 to operate.

[0128] Each of the aforementioned modules and / or devices can even be located on a single semiconductor platform to form system 565. Alternatively, the various modules can be placed individually or in various combinations of semiconductor platforms as desired by the user. Although various embodiments have been described above, it should be understood that they are presented by way of example only and not limitation. Therefore, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

[0129] Sample network environment

[0130] A network environment suitable for implementing embodiments of the present disclosure may include one or more client devices, servers, network attached storage (NAS), other backend devices, and / or other device types. The client devices, servers, and / or other device types (e.g., each device) may be configured to: Figure 5A The processing system 500 and / or Figure 5B 565 , for example, each device may include similar components, features, and / or functionality of the processing system 500 and / or the exemplary system 565 .

[0131] The components of a network environment can communicate with each other via a network, which can be wired, wireless, or a combination thereof. A network can include multiple networks or networks of networks. For example, a network can include one or more wide area networks (WANs), one or more local area networks (LANs), one or more public networks, such as the Internet, and / or a public switched telephone network (PSTN), and / or one or more private networks. Where the network includes a wireless telecommunications network, components such as base stations, communication towers, or even access points (among other components) can provide wireless connectivity.

[0132] Compatible network environments may include one or more peer-to-peer network environments, in which case the server may not be included in the network environment, and one or more client-server network environments, in which case one or more servers may be included in the network environment. In a peer-to-peer network environment, the functionality described herein with respect to the server may be implemented on any number of client devices.

[0133] In at least one embodiment, the network environment may include one or more cloud-based network environments, distributed computing environments, combinations thereof, and the like. The cloud-based network environment may include a framework layer, a job scheduler, a resource manager, and a distributed file system implemented on one or more servers, which may include one or more core network servers and / or edge servers. The framework layer may include software supporting the software layer and / or a framework for one or more applications in the application layer. The software or application may include web-based service software or applications, respectively. In an embodiment, one or more of the client devices may use web-based service software or applications (e.g., by accessing the service software and / or application via one or more application programming interfaces (APIs)). The framework layer may be, but is not limited to, a free, open source software web application framework type that can, for example, use a distributed file system for large-scale data processing (e.g., "big data").

[0134] A cloud-based network environment can provide cloud computing and / or cloud storage that implements the computing and / or data storage functionality (or one or more portions thereof) described herein. Any of these different functions can be distributed across multiple locations from a central or core server (e.g., a central or core server in one or more data centers, which can be distributed across states, regions, countries, the world, etc.). If the connection to the user (e.g., a client device) is relatively close to an edge server, the core server can assign at least a portion of the functionality to the edge server. A cloud-based network environment can be private (e.g., limited to a single organization), public (e.g., available to many organizations), and / or a combination thereof (e.g., a hybrid cloud environment).

[0135] Client devices may include Figure 5A The example processing system 500 and / or Figure 5B At least some of the components, features, and functionality of the exemplary system 565 of FIG. By way of example and not limitation, the client device may be embodied as a personal computer (PC), a laptop, a mobile device, a smartphone, a tablet, a smartwatch, a wearable computer, a personal digital assistant (PDA), an MP3 player, a virtual reality headset, a global positioning system (GPS) or device, a video player, a video camera, a surveillance device or system, a vehicle, a boat, a spacecraft, a virtual machine, a drone, a robot, a handheld communication device, a hospital device, a gaming device or system, an entertainment system, a vehicle computer system, an embedded system controller, a remote control, an appliance, a consumer electronic device, a workstation, an edge device, any combination of these delineated devices, or any other suitable device.

[0136] Machine Learning

[0137] Deep neural networks (DNNs) developed on processors like the PPU 300 are already being used in a wide variety of use cases, from self-driving cars to faster drug discovery, from automatic image captioning from online image databases to intelligent real-time language translation in video chat applications. Deep learning is a technique that models the neural learning processes of the human brain, continuously learning, getting smarter, and delivering more accurate results faster over time. A child is initially taught by an adult to correctly identify and classify a variety of different shapes, and eventually is able to identify shapes without any guidance. Similarly, a deep learning or neural learning system needs to be trained in object recognition and classification so that it becomes smarter and more efficient at identifying basic objects, occluded objects, and so on, while also attributing context to objects.

[0138] At the simplest level, neurons in the human brain view various inputs, assign a level of importance to each of these inputs, and pass outputs to other neurons to react. Artificial neurons, or perceptrons, are the most basic model of a neural network. In one example, a perceptron can receive one or more inputs representing various features of the object it is being trained to recognize and classify, and each of these features is assigned a weight based on its importance in defining the object's shape.

[0139] Deep neural network (DNN) models include multiple layers of many connected nodes (such as perceptrons, Boltzmann machines, radial basis functions, convolutional layers, etc.), which can be trained with huge amounts of input data to quickly solve complex problems with high accuracy. In one example, the first layer of a DNN model breaks down an input image of a car into different segments and looks for basic patterns such as lines and angles. The second layer assembles these lines to find higher-level patterns such as wheels, windshields, and mirrors. The next layer identifies the type of vehicle, and the final layers generate tags for the input image, identifying the model of a specific car brand.

[0140] Once trained, a DNN can be deployed and used to identify and classify objects or patterns in a process called inference. Examples of inference (the process by which a DNN extracts useful information from a given input) include identifying handwritten digits on a check deposited at an ATM, identifying images of friends in photos, delivering movie recommendations to over 50 million users, identifying and classifying different types of cars, pedestrians, and road hazards in self-driving cars, or translating human language in real time.

[0141] During training, data flows through the DNN in a forward propagation phase until a prediction is produced indicating a label that corresponds to the input. If the neural network does not label the input correctly, the error between the correct label and the predicted label is analyzed, and the weights are adjusted for each feature during a backpropagation phase until the DNN correctly labels the input, as well as other inputs in the training dataset. Training complex neural networks requires a large amount of parallel computing performance, including floating-point multiplications and additions supported by the PPU300. Inference, which is less computationally intensive than training, is a latency-sensitive process in which the trained neural network is applied to new inputs it has not seen before in order to classify images, detect emotions, identify recommendations, recognize and translate languages, and generally reason about new information.

[0142] Neural networks rely heavily on matrix math operations, and complex, multi-layer networks require massive floating-point performance and bandwidth for both efficiency and speed. Leveraging thousands of processing cores optimized for matrix math operations and delivering tens to hundreds of TFLOPS of performance, the PPU 300 is a computing platform capable of delivering the performance required for deep neural network-based artificial intelligence and machine learning applications.

[0143] In addition, images generated using one or more of the techniques disclosed herein can be used to train, test, or certify DNNs for recognizing objects and environments in the real world. Such images can include scenes of roadways, factories, buildings, urban environments, rural environments, humans, animals, and any other physical objects or real-world environments. Such images can be used to train, test, or certify DNNs employed in machines or robots to manipulate, process, or modify physical objects in the real world. In addition, such images can be used to train, test, or certify DNNs employed in autonomous vehicles to navigate and move the vehicle in the real world. In addition, images generated using one or more of the techniques disclosed herein can be used to communicate information to users of such machines, robots, and vehicles.

[0144] Figure 5C Components of an example system 555 that can be used to train and utilize machine learning according to at least one embodiment are shown. The example system 555 may include one or more of the ECC and compressed data packing logic 100 or the ECC and compressed data correction logic 200. The example system 555 may include one or more of the data compression unit 110, the ECC calculation units 115 and 215, the packing units 120 and 220, the correction unit 205, or the data decompression unit 210. The example system 555 may be configured to implement Figure 1E and Figure 2D Method 150 or 260 shown.

[0145] As will be discussed, various components may be provided by a single computing system or various combinations of computing devices and resources, which may be under the control of a single entity or multiple entities. Furthermore, various aspects may be triggered, initiated, or requested by different entities. In at least one embodiment, the training of the neural network may be directed by a vendor associated with the vendor environment 506, while in at least one embodiment, training may be requested by a customer or other user who has access to the vendor environment via a client device 502 or other such resource. In at least one embodiment, the training data (or data to be analyzed by the trained neural network) may be provided by the vendor, the user, or a third-party content provider 524. In at least one embodiment, the client device 502 may be, for example, a vehicle or object to be navigated on behalf of a user, who may submit requests and / or receive instructions to facilitate navigation of the device.

[0146] In at least one embodiment, the request can be submitted via at least one network 504 for receipt by the provider environment 506. In at least one embodiment, the client device can be any suitable electronic and / or computing device that enables a user to generate and send such a request, such as, but not limited to, a desktop computer, a laptop computer, a computer server, a smartphone, a tablet computer, a game console (portable or otherwise), a computer processor, computing logic, and a set-top box. The one or more networks 504 may include any suitable network for transmitting the request or other such data, and may include, for example, the Internet, an intranet, an Ethernet network, a cellular network, a local area network (LAN), a wide area network (WAN), a personal area network (PAN), an ad hoc network with direct wireless connections between peers, and the like.

[0147] In at least one embodiment, a request may be received at interface layer 508, which in this example may forward the data to training and inference manager 532. Training and inference manager 532 may be a system or service comprising hardware and software for managing services and requests corresponding to data or content. In at least one embodiment, training and inference manager 532 may receive a request to train a neural network and may provide the data for the request to training module 512. In at least one embodiment, if the request is unspecified, training module 512 may select an appropriate model or neural network to use and may use the associated training data to train the model. In at least one embodiment, the training data may be a batch of data stored in training data repository 514, received from client device 502, or obtained from third-party content provider 524. In at least one embodiment, training module 512 may be responsible for the training data. The neural network may be any suitable network, such as a recurrent neural network (RNN) or a convolutional neural network (CNN). Once the neural network is trained and successfully evaluated, the trained neural network may be stored, for example, in model repository 516, which may store different models or networks for users, applications, services, and the like. In at least one embodiment, there may be multiple models for a single application or entity, which may be utilized based on a number of different factors.

[0148] In at least one embodiment, at a later point in time, a request for content (e.g., a path determination) or data determined or influenced at least in part by a trained neural network may be received from client device 502 (or another such device). The request may include, for example, input data to be processed using the neural network to obtain one or more inferences or other output values, classifications, or predictions, or for at least one embodiment, the input data may be received by interface layer 508 and directed to inference module 518, although a different system or service may also be used. In at least one embodiment, if not already locally stored to inference module 518, inference module 518 may obtain a suitable trained network from model repository 516, such as a trained deep neural network (DNN) as discussed herein. Inference module 518 may provide data as input to the trained network, which may then generate one or more inferences as output. For example, this may include a classification of the input data instance. In at least one embodiment, the inferences may then be transmitted to client device 502 for display or other communication to the user. In at least one embodiment, user context data may also be stored in a user context data repository 522, which may include data about the user that can be used as network input for generating inferences or determining data to be returned to the user after obtaining an instance. In at least one embodiment, related data, including at least some of the input or inference data, may also be stored in a local database 534 for use in processing future requests. In at least one embodiment, a user may use account information or other information to access resources or functionality in the provider environment. In at least one embodiment, if permitted and available, user data may also be collected and used to further train a model to provide more accurate inferences for future requests. In at least one embodiment, requests for a machine learning application 526 executing on a client device 502 may be received through a user interface, and results may be displayed through the same interface. The client device may include resources such as a processor 528 and memory 562 for generating requests and processing results or responses, as well as at least one data storage element 552 for storing data for the machine learning application 526.

[0149] In at least one embodiment, processor 528 (or the processor of training module 512 or inference module 518) will be a central processing unit (CPU). However, as described above, resources in such environments may utilize GPUs to process data for at least certain types of requests. GPUs, such as PPU 300, have thousands of cores and are designed to handle massively parallel workloads, making them popular in deep learning for training neural networks and generating predictions. While using GPUs for offline building allows for faster training of larger and more complex models, generating predictions offline means that request-time input features cannot be used, or predictions must be generated for all feature permutations and stored in lookup tables to service real-time requests. If the deep learning framework supports CPU mode, and the model is small and simple enough that feedforward execution on the CPU can be performed with reasonable latency, a service on a CPU instance can host the model. In this case, training can be performed offline on the GPU, and inference can be performed in real time on the CPU. If a CPU approach is not feasible, the service can run on a GPU instance. However, because GPUs have different performance and cost characteristics than CPUs, running a service that offloads runtime algorithms to a GPU may require a different design than a CPU-based service.

[0150] In at least one embodiment, video data may be provided from the client device 502 for enhancement in the vendor environment 506. In at least one embodiment, the video data may be processed for enhancement on the client device 502. In at least one embodiment, the video data may be streamed from a third-party content provider 524 and enhanced by the third-party content provider 524, the vendor environment 506, or the client device 502. In at least one embodiment, video data may be provided from the client device 502 for use as training data in the vendor environment 506.

[0151] In at least one embodiment, supervised and / or unsupervised training can be performed by the client device 502 and / or the vendor environment 506. In at least one embodiment, a set of training data 514 (e.g., classified or labeled data) is provided as input for use as training data. In at least one embodiment, the training data can include instances of at least one type of object for which the neural network is to be trained, as well as information identifying the type of object. In at least one embodiment, the training data can include a set of images, each image including a representation of a type of object, wherein each image also includes or is associated with labels, metadata, classifications, or other information identifying the type of object represented in the corresponding image. Various other types of data can also be used as training data, including text data, audio data, video data, and the like. In at least one embodiment, the training data 514 is provided as training input to the training module 512. In at least one embodiment, the training module 512 can be a system or service comprising hardware and software, such as one or more computing devices executing a training application for training the neural network (or other model or algorithm, etc.). In at least one embodiment, the training module 512 receives an instruction or request indicating the type of model to be used for training. In at least one embodiment, the model can be any suitable statistical model, network, or algorithm useful for such a purpose, which can include artificial neural networks, deep learning algorithms, learning classifiers, Bayesian networks, etc. In at least one embodiment, the training module 512 can select an initial model or other untrained model from an appropriate repository and train the model using the training data 514 to generate a trained model (e.g., a trained deep neural network) that can be used to classify similar types of data or generate other such inferences. In at least one embodiment in which training data is not used, an initial model can still be selected to train the input data of each training module 512.

[0152] In at least one embodiment, the model can be trained in several different ways, which can depend in part on the type of model selected. In at least one embodiment, a training data set can be provided to a machine learning algorithm, where the model is a model artifact created by the training process. In at least one embodiment, each instance of the training data contains a correct answer (e.g., a classification) that can be called a target or target attribute. In at least one embodiment, the learning algorithm finds patterns in the training data that map the input data attributes to the target - the answer to be predicted, and the machine learning model is the output that captures these patterns. In at least one embodiment, the machine learning model can then be used to obtain predictions for new data for which the target is not specified.

[0153] In at least one embodiment, the training and inference manager 532 can select from a set of machine learning models including binary classification, multi-class classification, generative, and regression models. In at least one embodiment, the type of model to use can depend at least in part on the type of target to be predicted.

[0154] Graphics processing pipeline

[0155] In one embodiment, the PPU 300 comprises a graphics processing unit (GPU). The PPU 300 is configured to receive commands specifying a shader program for processing graphics data. Graphics data can be defined as a set of primitives such as points, lines, triangles, quadrilaterals, triangle strips, and the like. Typically, a primitive includes data specifying the number of vertices for the primitive (e.g., in a model-space coordinate system) and attributes associated with each vertex of the primitive. The PPU 300 can be configured to process the graphics primitives to generate a frame buffer (e.g., pixel data for each of the pixels of a display).

[0156] The application writes model data (e.g., attributes and vertex sets) for the scene to a memory such as system memory or memory 304. The model data defines each of the objects that may be visible on the display. The application then makes an API call to the driver kernel, which requests that the model data be rendered and displayed. The driver kernel reads the model data and writes commands to the one or more streams to perform operations to process the model data. These commands can reference different shader programs to be implemented on the SMs 440 within the PPU 300, including one or more of a vertex shader, a hull shader, a domain shader, a geometry shader, and a pixel shader. For example, one or more of the SMs 440 can be configured to execute a vertex shader program that processes several vertices defined by the model data. In one embodiment, these different SMs 440 can be configured to execute different shader programs concurrently. For example, a first subset of the SMs 440 can be configured to execute a vertex shader program, while a second subset of the SMs 440 can be configured to execute a pixel shader program. A first subset of SMs 440 processes vertex data to generate processed vertex data and writes the processed vertex data to L2 cache 360 ​​and / or memory 304. After the processed vertex data is rasterized (e.g., transformed from three-dimensional data to two-dimensional data in screen space) to generate fragment data, a second subset of SMs 440 executes pixel shaders to generate processed fragment data, which is then blended with other processed fragment data and written to a frame buffer in memory 304. The vertex shader program and the pixel shader program can be executed concurrently, processing different data from the same scene in a pipelined manner until all model data for the scene is rendered to the frame buffer. The contents of the frame buffer are then transmitted to a display controller for display on a display device.

[0157] The images generated by applying one or more of the techniques disclosed herein can be displayed on a monitor or other display device. In some embodiments, the display device can be directly coupled to the system or processor that generates or renders the image. In other embodiments, the display device can be indirectly coupled to the system or processor, for example, via a network. Examples of such networks include the Internet, mobile telecommunications networks, WIFI networks, and any other wired and / or wireless networking systems. When the display device is indirectly coupled, the image generated by the system or processor can be streamed to the display device via the network. Such streaming allows, for example, a video game or other application that renders an image to be executed on a server, a data center, or in a cloud-based computing environment, and the rendered image is transmitted and displayed on one or more user devices (e.g., computers, video game consoles, smart phones, other mobile devices, etc.) that are physically separated from the server or data center. Therefore, the techniques disclosed herein can be applied to enhance the images being streamed, and enhance services that stream images, such as NVIDIA GeForce Now (GFN), Google Stadia, etc.

[0158] Example streaming system

[0159] Figure 6 6 is an example system diagram of a streaming system 605 according to some embodiments of the present disclosure. The streaming system 605 may include one or more of the ECC and compressed data packing logic 100 or the ECC and compressed data correction logic 200. The streaming system 605 may include one or more of the data compression unit 110, the ECC calculation units 115 and 215, the packing units 120 and 220, the correction unit 205, or the data decompression unit 210. The streaming system 605 may be configured to implement Figure 1E and Figure 2D Method 150 or 260 shown.

[0160] Figure 6 Including server 603 (which may include Figure 5A The example processing system 500 and / or Figure 5B ), client device 604 (which may include components, features, and / or functionality similar to the exemplary system 565 of Figure 5A The example processing system 500 and / or Figure 5B In some embodiments of the present disclosure, system 605 may be implemented with components, features, and / or functionality similar to the exemplary system 565 of EMBODIMENTS (e.g., FIG. 5 ) and network 606 (which may be similar to the network described herein).

[0161] In one embodiment, streaming system 605 is a game streaming system, and server 603 is a game server. In system 605, for a game session, client device 604 can simply receive input data in response to input from input device 626, send the input data to server 603, receive encoded display data from server 603, and display the display data on display 624. In this way, more computationally intensive calculations and processing are offloaded to server 603 (e.g., rendering of the game session's graphical output, particularly ray or path tracing, is performed by GPU 615 of server 603). In other words, the game session is streamed from server 603 to client device 604, thereby reducing the graphics processing and rendering requirements on client device 604.

[0162] For example, with respect to instantiation of a game session, client device 604 may be displaying a frame of the game session on display 624 based on display data received from server 603. Client device 604 may receive input from one of input devices 626 and, in response, generate input data. Client device 604 may send the input data to server 603 via communication interface 621 and over network 606 (e.g., the Internet), and server 603 may receive the input data via communication interface 618. CPU 608 may receive the input data, process the input data, and send the data to GPU 615, which causes GPU 615 to generate a rendering of the game session. For example, the input data may represent the movement of a user character in the game, firing a weapon, reloading, passing a ball, steering a vehicle, and so on. Rendering component 612 may render the game session (e.g., representing the results of the input data), and rendering capture component 614 may capture the rendering of the game session as display data (e.g., as image data capturing a rendered frame of the game session). The rendering of the game session may include ray or path traced lighting and / or shading effects calculated using one or more parallel processing units (e.g., GPUs, which may further employ the use of one or more specialized hardware accelerators or processing cores to perform ray or path tracing techniques) of the server 603. The encoder 616 may then encode the display data to generate encoded display data, and the encoded display data may be sent to the client device 604 via the communication interface 618 over the network 606. The client device 604 may receive the encoded display data via the communication interface 621, and the decoder 622 may decode the encoded display data to generate display data. The client device 604 may then display the display data via the display 624.

[0163] It should be noted that the techniques described herein may be included in executable instructions stored in a computer-readable medium, which are used by or in conjunction with a processor-based instruction execution machine, system, device, or apparatus. Those skilled in the art will appreciate that for some embodiments, various different types of computer-readable media may be included for storing data. As used herein, "computer-readable medium" includes one or more of any suitable media for storing executable instructions of a computer program, such that an instruction execution machine, system, apparatus, or device can read (or retrieve) instructions from the computer-readable medium and execute these instructions to implement the described embodiments. Suitable storage formats include one or more of electronic, magnetic, optical, and electromagnetic formats. A non-exhaustive list of conventional exemplary computer-readable media includes: portable computer disks; random access memory (RAM); read-only memory (ROM); erasable programmable read-only memory (EPROM); flash memory devices; and optical storage devices, including portable compact disks (CDs), portable digital video disks (DVDs), and the like.

[0164] It should be understood that the arrangement of the components shown in the drawings is for illustrative purposes, and other arrangements are possible. For example, one or more of the elements described herein can be implemented as electronic hardware components in whole or in part. Other elements can be implemented in software, hardware, or a combination of software and hardware. Moreover, some or all of these other elements can be combined, some can be omitted completely, and additional components can be added while still realizing the functions described herein. Therefore, the subject matter described herein can be implemented in many different variations, and all such variations are expected to be within the scope of the claims.

[0165] For the ease of understanding theme described herein, many aspects are described according to action sequence.Those skilled in the art will recognize that various actions can be performed by dedicated circuit or circuit system, by the program instruction of one or more processors or by the combination of the two.This paper does not expect to mean that the particular order that is described for carrying out this sequence must be followed for the description of any action sequence.All methods described herein can be performed in any appropriate order, unless this paper indicates otherwise or otherwise obviously contradicts with context.

[0166] The use of the terms "a," "an," "the," and similar designations in the context of describing the subject matter (especially in the context of the claims below) should be interpreted to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by the context. The use of the term "at least one" (e.g., at least one of A and B) followed by a list of one or more items should be interpreted to mean one item (A or B) selected from the listed items, or any combination of two or more of the listed items (A and B), unless otherwise indicated herein or clearly contradicted by the context. In addition, the foregoing description is for illustrative purposes only and not for limiting purposes, as the scope of protection sought is defined by the claims set forth hereafter along with their equivalents. The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended solely to better illustrate the subject matter and does not constitute a limitation on the scope of the subject matter, unless otherwise stated. The use of "based on" and other similar phrases in both the claims and the written specification to indicate a condition that brings about a result is not intended to exclude any other condition that brings about that result. The language in the specification should not be interpreted as indicating that any unclaimed element is essential to the implementation of the claimed invention.

Claims

1. A computer-implemented method comprising: processing the compressed data within the processor to calculate error correction code check bits; determining a number of fixed-size storage cells required to store the combination of the compressed data and the check digits; combining the compressed data and the check digit into the number of fixed-size storage cells to generate a combination; as well as The combination is transmitted within the processor or to an additional device external to the processor.

2. The computer-implemented method of claim 1 , further comprising: determining a maximum number of storage units for which the number exceeds the fixed size; removing the check digit from the combination; as well as The check bits are transmitted separately within the processor or separately to the additional device.

3. The computer-implemented method of claim 1 , further comprising: The check bits are discarded at the interface with the attached device, and only the compressed data is transmitted from the processor to the attached device.

4. The computer-implemented method of claim 1 , further comprising: The combination is stored in a memory device at a location accessed by an address that is read or written using a single access request.

5. The computer-implemented method of claim 1 , further comprising: The compressed data is stored in a first portion of a memory device, and the check bits are stored in a second portion of the memory device separate from the first portion.

6. The computer-implemented method of claim 1, wherein the combination is transmitted from the processor to the additional device via an interconnect.

7. The computer-implemented method of claim 1, wherein the combination is transmitted within the processor via a crossbar interconnect.

8. The computer-implemented method of claim 1 , wherein a second number of the fixed-size storage units is required to store the compressed data without the check bit, and the second number is less than the number of the fixed-size storage units required to store the combination.

9. The computer-implemented method of claim 1 , wherein the error correction code check bits are calculated separately for a portion of the compressed data in each fixed-size storage unit and the error correction code check bits are combined with the portion of the compressed data in the fixed-size storage units.

10. The computer-implemented method of claim 1 , wherein the combination is transferred to a storage resource within the processor, and the computer-implemented method further comprises: determining whether the compressed data is damaged based on the check bit; as well as The combination is stored in the storage resource, wherein, in response to determining that the compressed data is corrupted, the compressed data is corrected using the check bits before storing the combination.

11. The computer-implemented method of claim 10, wherein the combination is transmitted to the memory resource via a crossbar interconnect within the processor.

12. The computer-implemented method of claim 10 , further comprising: receiving, by an execution core within the processor, the combination from the memory resource; determining, by the execution core based on the check bit, that the compressed data is damaged; as well as The compressed data is corrected using the check bits before being processed by the execution core.

13. The computer-implemented method of claim 1 , further comprising: determining, by the additional device, that the compressed data is damaged; as well as The compressed data is corrected using the check bits before processing the combination within the attached device.

14. The computer-implemented method of claim 1, wherein at least one of the processing step, the determining step, and the combining step is performed on a server or in a data center to generate the image, and the image is streamed to the user device.

15. The computer-implemented method of claim 1, wherein at least one of the processing step, the determining step, and the combining step is performed in a cloud computing environment.

16. The computer-implemented method of claim 1, wherein at least one of the processing step, the determining step, and the combining step is performed for training, testing, or proving a neural network for use in a machine, robot, or autonomous vehicle.

17. The computer-implemented method of claim 1, wherein at least one of the processing step, the determining step, and the combining step is performed on a virtual machine that includes a portion of a graphics processing unit.

18. A system comprising: a processor comprising an interface; and an additional device external to the processor and connected to the interface, wherein the processor is configured to protect compressed data by: processing the compressed data to calculate error correction code check bits; determining a number of fixed-size storage cells required to store the combination of the compressed data and the check digits; as well as The compressed data and the check bits are combined into the number of fixed-size storage units for transmission within the processor or to the attached device external to the processor.

19. The system of claim 18, further comprising transmitting the combination via a crossbar interconnect within the processor.

20. A non-transitory computer readable medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the following steps: Processing compressed data to calculate error correction code check bits; determining a number of fixed-size storage cells required to store the combination of the compressed data and the check digits; The compressed data and the check bits are combined into the number of fixed-size storage cells for transmission within a first processor of the one or more processors or to an additional device external to the first processor.

Images