TW201729111A - GPU-CPU two-path memory copy - Google Patents

Abstract

Methods and apparatus relating to GPU-CPU (Graphics Processing Unit-Central Processing Unit) two-path memory copy are described. In an embodiment, a Graphics Processing Unit (GPU) copies at least a first portion of a data block from a source to a buffer. The GPU also copies a second portion of the data block from the source to a destination. A Central Processing Unit (CPU) copies the first portion of the data block from the first buffer to one or more corresponding locations in the destination. Other embodiments are also disclosed and claimed.

Description

GPU-CPU dual path memory copy

The disclosure relates generally to the scope of electronic components. More specifically, embodiments relate to GPU-CPU (Graphics Processing Unit - Central Processing Unit) dual path memory copy.

Several processors include both CPU and GPU. When processing images and/or video data, this data usually needs to be copied repeatedly between the host memory and the video memory. These copy jobs are very expensive in terms of computation cycles and memory bandwidth usage.

100‧‧‧ computing system

102, 102-1 to 102-N, 702, 800, 1630‧‧‧ processors

104, 112‧‧‧ Interconnection

106, 106-1 to 106-M, 707, 802A-802N‧‧‧ processor core

108, 704‧‧‧ Cache memory

110‧‧‧ router

112‧‧‧ Busbars

114, 660‧‧‧ memory

116, 116-1, 1451‧‧‧L1 cache memory

140‧‧‧Graphical Logic

150‧‧‧Video Memory

202‧‧‧Storage device

400‧‧‧ method

402, 404, 406, 408, 410‧‧‧ homework

602‧‧‧ system chip

620‧‧‧Central Processing Unit (CPU) Core

630‧‧‧Graphic Processor Unit (GPU) Core

640‧‧‧Input/Output (I/O) interface

642, 814, 1865‧‧‧ memory controller

670‧‧‧I/O device

700‧‧‧Processing system

706‧‧‧Scratch file

708, 712, 808, 900, 1100, 1400, 1632, 1810‧‧‧ graphics Processor

709‧‧‧ instruction set

710‧‧‧Processor bus

716‧‧‧Memory Controller Hub

720‧‧‧ memory device

721‧‧‧ directive

722‧‧‧Information

724‧‧‧Data storage device

726‧‧‧Wireless transceiver

728‧‧‧ Body interface

730‧‧‧Input/Output (I/O) Controller Hub

734‧‧‧Network Controller

740‧‧‧I/O controller

742‧‧‧Common Serial Bus (USB) Controller

744‧‧‧Keyboard and mouse

746‧‧‧Audio Controller

804A-804N‧‧‧ cache memory unit

806‧‧‧Common cache memory unit

810‧‧‧System Agent Core

811, 902, 1443‧‧‧ display controller

812‧‧‧Circular interconnect unit

813‧‧‧I/O link

816‧‧‧ Busbar controller unit

818‧‧‧ embedded memory module

904‧‧‧ Block Image Transfer (BLIT) Engine

906‧‧‧Video Codec Engine

910, 1010‧‧‧ graphics processing engine

912, 1012, 1522‧‧3D pipeline

914‧‧‧ memory interface

915‧‧3D/media subsystem

916, 1016, 1430, 1524‧‧‧ media pipeline

920, 1845‧‧‧ display devices

1003, 1103, 1403‧‧‧ Command Streamer

1014‧‧‧Execution unit array

1030‧‧‧Sampling engine

1032‧‧‧To noise/deinterlacing module

1034‧‧‧Dynamic Estimation Module

1036‧‧‧Image scaling and filtering ring module

1044, 1214, 1456‧‧‧Information埠

1102, 1402‧‧‧Circular interconnection

1104‧‧‧ pipeline front end

1130‧‧·Video Quality Engine (VQF)

1133‧‧‧Multi-format encoding/decoding (MFX) engine

1134, 1434‧‧‧ video front end

1136‧‧‧Geometric pipeline

1137, 1437‧‧‧Media Engine

1150A-1150N, 1160A-1160N‧‧ ‧ subcore

1152A-1152N‧‧‧First group of execution units

1154A-1154N‧‧‧Media/Texture Sampler

1162A-1162N‧‧‧Second group of execution units

1164A-1164N, 1210‧‧‧ sampler

1170A-1170N‧‧‧Common Resources Group

1180A-1180N‧‧‧ graphics core

1200, 1450‧‧‧ thread execution logic

1202‧‧‧pixel shader

1204, 1431‧‧‧ thread scheduler

1206‧‧‧ instruction cache memory

1208A-1208N, 1452A, 1452B‧‧‧ execution units

1212‧‧‧Data cache memory

1300‧‧‧Graphic processor instruction format

1310‧‧‧128 bit format

1312‧‧‧ instruction opcode

1313‧‧‧Index bar

1314‧‧‧Command Control Bar

1316‧‧‧ size bar

1318‧‧‧ Destination

1320‧‧‧Source operator SRC0

1322‧‧‧Source Operator SRC1

1324‧‧‧Source operand SRC2

1326‧‧‧Access/address mode information

1330‧‧‧64-bit compact instruction format

1340‧‧‧Operation code decoding

1342‧‧‧Mobile and Logical Opcode Clusters

1344‧‧‧Process Control Command Cluster

1346‧‧‧ Miscellaneous Directive Cluster

1348‧‧‧ Parallel Mathematical Instruction Cluster

1350‧‧‧ Vector Mathematical Cluster

1405‧‧‧Vertex Receiver

1407‧‧‧Vertex Shader

1411‧‧‧Programmable Shell Shader

1413‧‧‧Inlay

1417‧‧‧ programmable field shader

1419‧‧‧Geometry shader

1420‧‧‧Graphic pipeline

1423‧‧‧Outflow unit

1429‧‧‧Chopper

1440‧‧‧Display Engine

1441‧‧‧2D engine

1454‧‧‧Texture and Media Sampler

1458‧‧‧Texture/sampler cache memory

1470‧‧‧presenting the output pipeline

1473‧‧‧Raster and depth test components

1475‧‧‧Shared L3 cache memory

1477‧‧‧Pixel working components

1478‧‧‧ Presenting cache memory

1479‧‧‧Deep cache memory

1500‧‧‧Graphic Processor Command Format

1502‧‧‧ Target customers

1504‧‧‧Command job code (opcode)

1505‧‧‧sub-operating code

1506‧‧‧Information Bar

1508‧‧‧Command size

1510‧‧‧Graphic Processor Command Sequence

1512‧‧‧Line Refresh Command

1513‧‧‧Pipeline selection order

1514‧‧‧Line Control Command

1516‧‧‧Return buffer status

1520‧‧‧ pipeline decision

1530‧‧‧3D pipeline status

1532‧‧3D primitive

1534‧‧‧Execution

1540‧‧‧Media pipeline status

1542‧‧‧Media Object Order

1544‧‧‧Execution of orders

1600‧‧‧Data Processing System

1610‧‧‧3D graphics application

1612‧‧‧ Shader Instructions

1614‧‧‧executable instructions

1616‧‧‧Graphic objects

1620‧‧‧Operating system

1622‧‧‧Graphic application programming interface

1624‧‧‧ Front End Shader Compiler

1626‧‧‧User mode graphics driver

1627‧‧‧Backend shader compiler

1628‧‧‧Operating system kernel mode function

1629‧‧‧ kernel mode graphics driver

1634‧‧‧General Processor Core

1650‧‧‧System Memory

1700‧‧‧IP Core Development System

1710‧‧‧Software simulation

1715‧‧‧Storage Transfer Level (RTL) Design

1720‧‧‧ hardware model

1730‧‧‧Design facilities

1740‧‧‧Non-volatile memory

1750‧‧‧Wired connection

1760‧‧‧Wireless connection

1765‧‧‧Manufactured facilities

1800‧‧‧System Wafer Integrated Circuit

1805‧‧‧Application Processor

1815‧‧‧Image Processor

1820‧‧‧Video Processor

1825‧‧‧USB controller

1830‧‧‧UART controller

1835‧‧‧SPI/SDIO Controller

1840‧‧‧I2S/I2C controller

1850‧‧‧High-resolution multimedia interface (HDMI) controller

1855‧‧‧Mobile Industry Processor Interface (M1P1) Display Interface

1860‧‧‧Flash Memory Subsystem

1870‧‧‧ embedded security engine

A detailed description is provided with reference to the drawings. In the figure, the leftmost digit of the reference number identifies the figure in which the reference number first appears. The same reference numbers are used in the different figures to indicate similar or identical items.

1, 6-7, 16, and 18 depict block diagrams of embodiments of an arithmetic system that can be used to implement various embodiments discussed herein.

Figure 2 depicts, in contrast to a pure CPU copy, in accordance with an embodiment Mixed replication of the associated data stream.

3 depicts a block diagram of a dual path memory copy operation in accordance with an embodiment.

4 depicts a flow diagram of a method of implementing a dual path memory copy job, in accordance with an embodiment.

Figure 5 depicts a sample plot of dual path memory copying to achieve yield performance, in accordance with an embodiment.

8-12 and 14 depict various components of a processor in accordance with several embodiments.

Figure 13 depicts a graphics core instruction format in accordance with several embodiments.

15A and 15B depict graphics processor command formats and sequences, respectively, in accordance with several embodiments.

Figure 17 depicts an IP core development diagram in accordance with an embodiment.

SUMMARY OF THE INVENTION AND EMBODIMENT

In the following description, numerous specific details are set forth in the description However, various embodiments may be implemented without specific details. In other instances, well-known methods, procedures, components, and circuits are not described in detail so as not to obscure the specific embodiments. In addition, various embodiments may be used to implement various aspects of the embodiments, such as integrated semiconductor circuits ("hardware"), computer readable instructions ("software") organized into one or more programs, or hardware And several combinations of software. For the purposes of this disclosure, reference to "logic" shall mean hardware, software, corpus, or a combination thereof.

Typically, images and/or video frame data are copied from the system or host memory (which may also be referred to as CPU memory) to video memory (which may also be referred to as GPU memory) for GPU access. Once processing is complete, the data is copied back to the system/host memory for execution of the next processing job or for example on the screen. Copying (from memory associated with the CPU to memory associated with the GPU) and copying (from memory associated with the GPU to CPU-related) in terms of computation cycles and/or memory bandwidth usage The memory of the joint) is expensive. Moreover, sometimes the conversion of the frame layout is necessary for copying operations, such as paving to linear, linear to tile, and the like. The linear format is generally adapted to one of the system memory serial array access patterns, wherein each column of the operands is stored in the sequence increment memory location. The tile layout divides the enclosed area of the image/video frame into a smaller rectangular area array to improve the two-dimensional (2D) sub-area access performance of the video memory. Thus, the cost of memory copying or transfer is one of the most common performance bottlenecks in image and/or video processing applications.

Furthermore, there are generally three possible solutions for exchanging data between the GPU memory and the CPU host memory in the processor. The CPU and GPU are integrated on the same integrated circuit device. The solution is as follows: (1) Zero copy For the fastest solution, but with a relatively large number of restrictions; (2) pure GPU replication is slower than zero replication, but still the fastest solution with fewer restrictions; and (3) pure CPU replication (eg using SSE/AVX or Streaming SIMD (Single Instruction Multiple Data Extension/Advanced Vector Extension) is the slowest solution without restrictions.

To this end, several embodiments provide GPU and CPU memory complexes. A dual-path memory copying technique for manufacturing operations, and a check and balance device to transfer memory data. In the embodiment, most of the data is copied by the GPU, and the rest of the data is copied by the CPU. This hybrid approach removes the barrier of pure GPU replication while minimizing performance. Furthermore, the hybrid method of disclosure is faster than pure CPU copy jobs (eg, using SSE/AVX).

Moreover, several embodiments are applicable to an arithmetic system that includes one or more processors (e.g., having one or more processor cores), such as those discussed with reference to Figures 1-9, including, for example, a mobile computing device, such as smart phones, tablet PCs, UMPC (ultra mobile PC), laptop computer, ultra-notebook (Ultrabook ^TM) computing devices, watches wisdom, the wisdom of glasses. More specifically, FIG. 1 depicts a block diagram of computing system 100 in accordance with an embodiment. System 100 can include one or more processors 102-1 through 102-N (collectively referred to herein as "processor 102"). In various embodiments, processor 102 can include a general purpose CPU and/or GPU. The processor 102 can communicate via an interconnect or bus bar 104. Each processor can include a variety of components, discussed only with reference to processor 102-1 for clarity. Thus, each of the remaining processors 102-2 through 102-N may include the same or similar components discussed with reference to processor 102-1.

In an embodiment, processor 102-1 may include one or more processor cores 106-1 through 106-M (collectively referred to herein as "core 106"), cache memory 108, and/or router 110. Processor core 106 can be implemented on a single integrated circuit (IC) wafer. Furthermore, the wafer may include one or more public and/or private cache memories (such as cache memory 108), bus bars or interconnects (such as bus bars or interconnects). 112), graphics and/or memory controllers (such as those discussed with reference to Figures 6-9), or other components.

In an embodiment, router 110 can be used for communication between various components of processor 102-1 and/or system 100. Moreover, processor 102-1 can include more than one router 110. In addition, a number of routers 110 can communicate to enable routing of data between various components within or outside of processor 102-1.

The cache memory 108 can store data (eg, including instructions) for use by one or more components of the processor 102-1, such as the core 106. For example, for faster access by components of processor 102 (e.g., faster access by core 106), cache memory 108 can locally cache data stored in memory 114. As shown in FIG. 1, memory 114 can communicate with processor 102 via interconnect 104. In an embodiment, the cache memory 108 (which may be common) may be a medium cache memory (MLC), a last level cache (LLC), or the like. Moreover, each core 106 may include level 1 (L1) cache memory (116-1) (collectively referred to herein as "L1 cache memory 116") or other level cache memory, such as level 2 (L2) fast. Take the memory. Moreover, various components of processor 102-1 can communicate directly with cache memory 108 via busbars (e.g., busbars 112) and/or memory controllers or hubs.

As shown in FIG. 1, processor 102 can further include graphics logic 140 (eg, which can include one or more graphics processing unit (GPU) cores, such as those discussed with respect to Figures 6-9), while implementing various graphics And/or general purpose computing related tasks, such as those discussed in the text. logic 140 may access one or more storage devices (such as video (or image, graphics, etc.) memory 150, cache memory 108, L1 cache memory 116, memory 114, scratchpad discussed in the text. Or another memory in system 100, and store information about the operations of logic 140, such as information communicated with various components of system 100, as discussed herein. Moreover, although logic 140 and video memory 150 are shown internal to processor 102 (or to interconnect 104), in various embodiments, it can be located anywhere in system 100. For example, logic 140 can replace one of cores 106 and can be directly coupled to interconnect 112 or the like. Moreover, the video memory 150 can be directly coupled to the interconnect 112 or the like.

2 depicts a data flow associated with a pure CPU copy relative to a hybrid copy, in accordance with an embodiment. Referring to FIG. 1-2, for a pure CPU copy job (shown at the top of FIG. 2), the CPU locks the data (for example, avoids the problem of multiple accesses of the same data), and then copies the locked data from the video memory 150 to the system. Memory 114. In an embodiment, for a hybrid copy job (shown at the bottom of FIG. 2), GPU 140 copies at least a portion of the data from video memory 150 to a number of auxiliary/secondary buffer/storage devices 202. As will be discussed further with respect to FIG. 3, the CPU will copy data from storage device 202 to system memory 114.

Furthermore, as mentioned above, there are three possible solutions for transferring data from the GPU to the CPU as follows. Zero copying is the fastest method, but with a relatively large number of restrictions, such as: (a) memory needs to be placed in the system memory space and mapped to the video memory address space; (b) system memory storage device layout needs to be linear Layout (it is good for CPU storage Take, but not conducive to GPU access, generally for faster GPU access in video memory, using Y_layout 2D surface storage device format); and (c) mapping to GPU address space, system memory needs For page alignment (eg 4K bytes) (which can be a hard limit in many existing software products). In addition to the zero-copy solution, pure GPU replication is the fastest replication solution, but it still has several limitations (such as aligning data in some way) that can be avoided by many developers. CPU copy jobs are not limited, but they are the slowest replication solution, for example because of the interleaving of the lines in the Y_layout surface storage format. Since it is necessary to perform a four-cache memory column read operation from the video memory and a full-conversion 64-bit cache cache in the system memory, the memory read bandwidth efficiency is only 25%.

3 depicts a block diagram of an MDF implementation of a dual path memory copy job, in accordance with an embodiment. As discussed herein, MDF (Media Development Architecture) generally refers to a high-level programming architecture to expose GPU general arithmetic/processing capabilities, and it can significantly improve the performance of highly parallel or computationally intensive operations. Typically, MDF applications have two components: the kernel and the host program. The host program builds and starts the kernel. The kernel is then executed on the GPU hardware.

In the case of copying data from the video memory 150 to the system memory 114 in a dual path, the destination is not a 16-byte aligned system memory. Thus, the unaligned destination memory address, GPU 140 cannot directly copy the first and last bytes of system memory 114 to the destination. The reason is that the Oword (eight character) block write command is used to write data to the destination, but it requires at least 16 byte alignment. Memory and surface width. To address this limitation, an embodiment imports (e.g., pre-configured) the auxiliary buffer 202 as a temporary buffer that can provide a memory buffer for a user with page-aligned system memory. As discussed herein, the auxiliary buffer 202 can be a zero copy buffer, also known as a buffer UP.

Referring to Figures 1-3, the embodiment utilizes a solution having the following two steps. First (marked as circle 1 in Figure 3), GPU component: MDF replication kernel: (a) In the image, GPU 140 copies the full cache column (in one embodiment, the cache column width is 64 bytes), from The video memory 150 is (for example, 16 bytes) aligned to the system memory to the destination (system memory 114). The full cache columns with a width of 64 bytes represent the pixels in the image. For this GPU-replicated component, the embodiment uses a media block read and Oword block write command, and has a transpose to map the tile layout in the video memory to a linear layout in the system memory; and (b) The GPU 140 copies a portion of the cache start and end caches into the auxiliary memory 202 with media block read and Oword block write commands. The components of this GPU copy implement the same functionality as described in (a) above, since data transfer will be performed by sending the same read/write command. Secondly (labeled as circle 2 in Figure 3), the CPU components include: (a) after the GPU ends the above execution, the CPU accesses the data in the auxiliary buffer 202 because it is zero-copy; and (b) as shown in Figure 3. As shown, the CPU copies this material to the corresponding location (i.e., start and end) in the destination system memory 114.

Furthermore, the dual path solution shown in Figure 3 uses an auxiliary buffer 202 (e.g., a memory buffer provided by the user) to copy Alignment data provides higher performance than CPU copying directly from video memory to system memory as shown at the top of Figure 2. The reason is that dual-path replication jobs use the same fast GPU replication mechanism as pure GPU replication. Since the buffer 202 checks and balances zero copy, after the GPU is copied, the data is already in the system memory. The cost of copying these small data items (eg, at the beginning and end of the data block) to the system memory is relatively low. However, as discussed with respect to Figure 2, pure CPU replication requires surface locking operations to avoid resource conflicts, which is costly. Refer to the data transfer pipeline in Figure 1.

Referring to Figure 3, assuming that the address at the beginning of the destination is an aligned 40-bit tuple (not an aligned 16-bit tuple), the dual-path replication solution is used to handle the misalignment problem. In an embodiment, the kernel processes 8*128 bytes in each thread, as will be discussed further with respect to FIG.

More specifically, FIG. 4 depicts a flowchart of method 400 in accordance with an embodiment, implementing a dual path memory copy operation. In one embodiment, method 400 displays an operation performed by a software thread that utilizes both CPU and GPU to copy a data block from a source (eg, video memory 150) to a destination (eg, system memory 114). In an embodiment, various components discussed with reference to other figures may be used to implement one or more of the methods 400.

Referring to Figures 1-4, at job 402, the beginning of the data block (e.g., provided in a memory or cache column, such as bits 0 through 24 of video memory 150 shown in Figure 3), Copy from source (eg video memory 150) (eg by graphics logic / GPU 140) to auxiliary A buffer (such as buffer 202). The data block of job 402 can be calculated (eg, based on the aligned 64-bit offset) based on the starting address in the system memory (eg, 64-40 or 24, as shown in the example of FIG. 3). The beginning.

At job 404, the remainder of the data block (ie, after the beginning of job 402, which may be the remaining full cache columns (64 bytes)) is copied from the source (eg, by graphics logic / GPU 140) to (eg, Aligned system memory) destination (eg, system memory 114). The beginning of the system memory of the alignment of the job 404 (eg, based on aligned 64-bit normalization) may be calculated based on the initial address refinement (eg, 40 alignment, or 64, as shown in the example of FIG. 3). Address. Job 404 is repeated until the end of the data block is reached, as determined by job 406 (e.g., the last 40 bytes of the end of the match column, as shown in the example of Figure 3).

At job 408, the last portion of the data block (e.g., the last 40 bytes of the column, as shown in the example of FIG. 3) is copied from the source (e.g., by graphics logic/GPU 140) to the auxiliary buffer. At job 410, the data stored in the auxiliary buffer is copied (e.g., by the CPU or core 106 of Figure 1) to the correct place in the destination (e.g., the beginning and end as shown in Figure 3). Method 400 can then repeat another copy thread/job.

Figure 5 depicts a sample plot of dual path memory copying to achieve yield performance, in accordance with an embodiment. As shown, dual-path replication provides better performance than pure CPU replication (for example, using SSE4) and is only purer GPU The copy is less than 1 bit. Thus, several embodiments utilizing dual path memory replication achieve the desired functionality and good performance with a single flat surface and multiple flat surfaces. To implement a flat surface, the above conditions can be extended to cover the UV plane and the Y plane. Moreover, as shown in Figure 5, the dual path solution is approximately 1.68 times faster than pure CPU replication (using SSE4), which is based on plotting sample test results with no alignment restrictions. Furthermore, in the above test, the destination system memory address of the dual path copy is aligned to 1 byte, and the pure GPU copy requires the aligned 16-bit tuple of the destination system memory.

As discussed herein, YUV (also known as YCbCr) is one of the two main color spaces used to represent digital component video (the other is RGB). The difference between YCbCr and RGB is that YCbCr represents color by brightness and two color difference signals, while RGB represents color by red, green, and blue. In YCbCr, Y is brightness, Cb is blue minus brightness (B-Y), and Cr is red minus brightness (R-Y). One of the YUV formats is to place Y in a plane and to place the UV in another plane.

As discussed above, several embodiments utilize both CPU and GPU to implement a memory copy job. Most (eg, aligned) data is copied using the GPU copy kernel, and the rest (eg, unaligned) data is copied to the CPU copy job. More specifically, an embodiment is implemented in accordance with the MDF GPU programming architecture. However, embodiments are not limited to any runtime SDK (software development tool) that exposes an MDF architecture and exposes an API (application programming interface), which uses both CPU and GPU to implement memory data transfer, and can be used to implement various embodiments. .

Therefore, the GPU/CPU dual path replication discussed in this article The example checks and balances both CPU (for unlimited) and GPU (for high performance). This solution maintains the high performance of pure GPU replication (with minimal performance penalty) and removes the barriers associated with pure GPU replication jobs. As a result, it also removes barriers for the user and uses GPU copy jobs to speed up memory transfers in their software products.

In several embodiments, one or more of the components discussed herein may be embodied as a system on a chip (SOC) device. Figure 6 depicts a block diagram of a SOC package, in accordance with an embodiment. As depicted in FIG. 6, SOC 602 includes one or more central processing unit (CPU) cores 620 (which may be the same or similar to core 106 of FIG. 1), one or more graphics processing unit (GPU) cores. 630 (which may be the same as or similar to graphics logic 140 of FIG. 1), an input/output (I/O) interface 640, and a memory controller 642. The various components of SOC package 602 can be coupled to interconnects or bus bars, such as those discussed herein with reference to other figures. Moreover, SOC package 602 can include more or fewer components, such as those discussed herein with reference to other figures. Moreover, each component of SOC package 602 can include one or more other components, such as those discussed herein with reference to other figures. In one embodiment, SOC package 602 (and components thereof) are provided on one or more integrated circuit (IC) dies, for example, packaged in a single semiconductor device.

As depicted in FIG. 6, SOC package 602 is coupled to memory 660 via memory controller 642 (which may be similar or identical to those discussed herein with respect to other figures, such as system memory 114 of FIG. 1). In an embodiment, memory 660 (or a portion thereof) may be integrated on SOC package 602.

The I/O interface 640 can be coupled to one or more I/O devices 670, such as via interconnects and/or busbars such as those discussed herein with reference to other figures. I/O device 670 can include one or more of a keyboard, mouse, touch pad, display, image/video capture device (such as a camera or camera/recorder), a touch screen, a speaker, and the like. Moreover, in an embodiment, SOC package 602 can include/integrate logic 140 and/or video memory 150 (or a portion of video memory 150). Alternatively, logic 140 and/or video memory 150 (or a portion of video memory 150) may be provided external to SOC package 602 (ie, as individual logic).

FIG. 7 is a block diagram of processing system 700, in accordance with an embodiment. In various embodiments, system 700 includes one or more processors 702 and one or more graphics processors 708 (such as graphics logic 140 of FIG. 1), and can be a single processor desktop system, multiple A processor workstation system, or a server system having a number of processors 702 (such as processor 102 of FIG. 1) or processor core 707 (such as core 106 of FIG. 1). In one embodiment, system 700 is a processing platform incorporated into a system wafer (SoC) integrated circuit for use in a mobile, handheld, or embedded device.

Embodiments of system 700 may include or incorporate a server-based gaming platform, a gaming console, including a gaming and media console, a mobile gaming console, a handheld gaming console, or an online gaming console. In some embodiments, system 700 is a mobile phone, smart phone, tablet computing device, or mobile internet device. Data processing system 700 can also include, couple, or integrate wearable devices, such as smart watch wearable devices, smart eyewear devices, augmented reality devices, or virtual reality devices. In a few realities In the embodiment, data processing system 700 is a television or set-top box device having one or more processors 702 and a graphical interface generated by one or more graphics processors 708.

In several embodiments, one or more processors 702 each include one or more processor cores 707 that, when executed, process instructions to perform operations of the system and user software. In several embodiments, each of the one or more processor cores 707 is assembled to process a particular set of instructions 709. In several embodiments, the set of instructions 709 can facilitate complex instruction set operations (CISC), reduced instruction set operations (RISC), or operations via very long instruction words (VLIW). The multiprocessor core 707 can process different sets of instructions 709, respectively, which can include instructions to facilitate emulation of other sets of instructions. Processor core 707 may also include other processing devices, such as a digital signal processor (DSP).

In several embodiments, processor 702 includes cache memory 704. Depending on the architecture, processor 702 can have a single internal cache or multiple levels of internal cache. In some embodiments, the cache memory is shared between various components of the processor 702. In some embodiments, the processor 702 also uses an external cache (eg, level 3 (L3) cache or last level cache (LLC)) (not shown), which can be used with known fast The processor core 707 of the memory consistency technique is shared. The scratchpad file 706 is additionally included in the processor 702, which may include different types of registers for storing different types of data (eg, integer registers, floating point registers, status registers, and instruction indicators). Memory). Several registers can be general purpose registers, while other registers can be specific to the processor 702 design.

In several embodiments, processor 702 is coupled to processor bus 710 to communicate communication signals, such as address, data, or control signals, between processor 702 and other components in system 700. In one embodiment, system 700 uses an example "hub" system architecture, including a memory controller hub 716 and an input/output (I/O) controller hub 730. The memory controller hub 716 facilitates communication between the memory device and other components of the system 700 while the I/O controller hub (ICH) 730 provides connectivity to the I/O devices via the local I/O bus. In one embodiment, the logic of the memory controller hub 716 is integrated into the processor.

The memory device 720 can be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory device, a phase change memory device, or have appropriate performance as program memory. Several other memory devices. In one embodiment, memory device 720 is operative as system memory of system 700 for storing data 722 and instructions 721 for use by one or more processors 702 executing an application or program. The memory controller hub 716 is also coupled to an optional external graphics processor 712 that can communicate with one or more of the graphics processors 708 to implement graphics and media operations.

In several embodiments, the ICH 730 enabled peripheral device is coupled to the memory device 720 and the processor 702 via a high speed I/O bus. I/O peripherals include, but are not limited to, audio controller 746, media interface 728, wireless transceiver 726 (eg, Wi-Fi, Bluetooth), data storage A storage device 724 (e.g., a hard disk, a flash memory, etc.), and an old I/O controller 740 are used to couple legacy (e.g., Personal System 2 (PS/2)) devices to the system. One or more universal serial bus (USB) controllers 742 are coupled to input devices, such as a combination of a keyboard and a mouse 744. Network controller 734 can also be coupled to ICH 730. In several embodiments, a high performance network controller (not shown) is coupled to the processor bus 710. It will be understood that the system 700 shown is exemplary and not limiting, and other types of data processing systems may be used. For example, I/O controller hub 730 can be integrated into one or more processors 702, or memory controller hub 716 and I/O controller hub 730 can be integrated into an individual external graphics processor, such as external graphics. Processor 712.

8 is a block diagram of an embodiment of a processor 800 having one or more processor cores 802A-802N, an integrated memory controller 814, and an integrated graphics processor 808. Processor 800 can be similar or identical to processor 102 discussed with reference to FIG. The elements of Figure 8 have the same reference numbers (or names) as the elements of any other figures in the text, and may operate or behave in any manner similar to that described anywhere in the text, but are not limited thereto. Processor 800 can include the remaining cores and include the remaining cores 802N represented by dashed squares. Each processor core 802A-802N includes one or more internal cache memory units 804A-804N. In some embodiments, each processor core also accesses one or more public cache memory units 806.

Internal cache memory units 804A-804N and common cache memory unit 806 represent cache memory levels within processor 800. fast The memory hierarchy may include at least one level of instruction and data cache memory in each processor core, and one or more levels of common intermediate cache memory, such as level 2 (L2), level 3 (L3), 4 Level (L4), or other level of cache memory, where the highest-level cache memory before the external memory is classified as LLC. In several embodiments, the cache memory coherency logic maintains consistency between the various cache memory units 806 and 804A-804N.

In some embodiments, processor 800 can also be a set of one or more bus controller unit 816 and system agent core 810. One or more bus controller units 816 manage a set of peripheral busses, such as one or more peripheral device component interconnect busses (eg, PCI, PCI Express). System Agent Core 810 provides management functions for various processor components. In several embodiments, system agent core 810 includes one or more integrated memory controllers 814 to manage access (not shown) of various external memory devices.

In several embodiments, one or more processor cores 802A-802N include support for synchronous multi-threading. In this embodiment, system agent core 810 includes components for coordinating and working cores 802A-802N during multi-thread processing. System agent core 810 can additionally include a power control unit (PCU) that includes logic and components to regulate the power states of processor cores 802A-802N and graphics processor 808.

In several embodiments, processor 800 additionally includes graphics processor 808 to perform graphics processing operations. In several embodiments, graphics processor 808 is coupled to a combination of public cache memory unit 806 and system proxy core 810, including one or more integrated memory controllers. 814. In some embodiments, display controller 811 is coupled to graphics processor 808 to drive the graphics processor output to one or more coupled display devices. In some embodiments, display controller 811 can be an individual module coupled to the graphics processor via at least one interconnect, or can be integrated into graphics processor 808 or system agent core 810.

In some embodiments, the ring interconnect unit 812 is configured to couple internal components of the processor 800. However, alternative interconnect units may be utilized, such as point-to-point interconnects, switched interconnects, or other techniques, including those well known in the art. In several embodiments, graphics processor 808 is coupled to ring interconnect 812 via I/O link 813.

The example I/O link 813 represents at least one of a variety of I/O interconnects, including packaged I/O interconnects that facilitate communication between various processor components and high performance embedded memory modules 818, such as eDRAM (or Embedded DRAM) module. In some embodiments, each processor core 802A-802N and graphics processor 808 uses embedded memory module 818 as a common final cache.

In several embodiments, processor cores 802A-802N are homogeneous cores that implement the same instruction set architecture. In another embodiment, processor cores 802A-802N are heterogeneous in terms of an instruction set architecture (ISA), wherein one or more processor cores 802A-802N execute a first set of instructions while at least one other core executes A subset of an instruction set or a different instruction set. In an embodiment, processor cores 802A-802N are heterogeneous in terms of microarchitecture, wherein one or more cores having relatively high power losses are coupled to one or more power cores having lower power losses . this In addition, processor 800 can be implemented on one or more wafers, or as a SoC integrated circuit with the depicted components, among other components.

9 is a block diagram of a graphics processor 900, which may be an individual graphics processing unit, or may be a graphics processor integrated with a complex processing core. Graphics processor 900 can be similar or identical to graphics logic 140 discussed with respect to FIG. In some embodiments, the graphics processor communicates to the scratchpad on the graphics processor via the memory mapped I/O interface and has commands placed into the processor memory. In some embodiments, graphics processor 900 includes a memory interface 914 to access memory. The memory interface 914 can be an interface to local memory, one or more internal cache memories, one or more common external cache memories, and/or system memory.

In some embodiments, graphics processor 900 also includes display controller 902 to drive display output data to display device 920. Display controller 902 includes hardware for one or more coverage planes of the display device and a plurality of layers of video or user interface elements. In several embodiments, graphics processor 900 includes video codec engine 906, encoding, decoding, or transcoding media to, from, or between one or more media encoding formats, including but not limited to dynamic graphics Like Expert Group (MPEG) format, such as MPEG-2; Advanced Video Coding (AVC) format, such as H.264/MPEG-4 AVC; and Society for Motion Picture and Television Engineers (SMPTE) 421M/VC-1; Joint Image Expert Group (JPEG) format, such as JPEG; and Motion JPEG (MJPEG) format.

In several embodiments, graphics processor 900 includes a block image transfer (BLIT) engine 904 to implement a two-dimensional (2D) rasterizer. Industry, including, for example, bit boundary block transfer. However, in an embodiment, the 8D graphics job is implemented using one or more components of a graphics processing engine (GPE) 910. In some embodiments, graphics processing engine 910 is an arithmetic engine for implementing graphics jobs, including three-dimensional (3D) graphics jobs and media jobs.

In several embodiments, GPE 910 includes a 3D pipeline 912 for implementing 3D jobs, such as rendering three-dimensional images and scenes using processing functions that act on 3D original shapes (eg, rectangles, triangles, etc.). The 3D pipeline 912 includes programmable and fixed function components that perform various functions within the components and/or generate threads to the 3D/media subsystem 915. While 3D pipeline 912 can be used to implement media operations, embodiments of GPE 910 also include media pipeline 916, which is specifically used to implement media jobs, such as post-video processing and image enhancement.

In several embodiments, media pipeline 916 includes fixed or programmable logic units that implement one or more specific media jobs, such as video decoding acceleration, video deinterlacing, and video encoding acceleration, in place of or on behalf of video codec engine 906. . In several embodiments, media pipeline 916 additionally includes a thread generation unit to generate threads for execution on 3D/media subsystem 915. The generated thread implements a media job operation on one or more graphics execution units included in the 3D/media subsystem 915.

In several embodiments, 3D/media subsystem 915 includes logic for executing threads generated by 3D pipeline 912 and media pipeline 916. In an embodiment, the pipeline sends a thread execution request to the 3D/media The volume subsystem 915 includes thread scheduling logic for performing resource arbitration and scheduling various requests for available threads. Execution resources include an array of graphics execution units to handle 3D and media threads. In several embodiments, the 3D/media subsystem 915 includes one or more internal cache memories of thread instructions and data. In some embodiments, the subsystem also includes a common memory, including a scratchpad and addressable memory, sharing data between the threads and storing the output data.

10 is a block diagram of a graphics processing engine 1010 of a graphics processor, in accordance with several embodiments. In an embodiment, GPE 1010 is a version of GPE 910 shown in FIG. The elements of Figure 10 have the same reference numbers (or names) as the elements of any other figures in the text, and may operate or behave in any manner similar to that described elsewhere herein, but are not limited thereto.

In several embodiments, GPE 1010 is coupled to command streamer 1003, which provides command flow to GPE 3D and media pipelines 1012, 1016. In some embodiments, the command streamer 1003 is coupled to a memory, which can be system memory or one or more internal cache memories and a common cache memory. In several embodiments, command streamer 1003 receives commands from memory and sends commands to 3D pipeline 1012 and/or media pipeline 1016. The command is a guide taken from a ring buffer that stores commands for the 3D and media pipelines 1012, 1016. In an embodiment, the ring buffer may additionally include a batch command buffer to store multiple batches of commands. The 3D and media pipelines 1012, 1016 process the commands by performing operations via logic within the individual pipelines, or by scheduling one or more threads to execute the array of cells 1014. In several embodiments, the array of execution units 1014 is expandable Shrinking causes the array to include a variable number of execution units based on the target power and performance levels of the GPE 1010.

In some embodiments, the sampling engine 1030 is coupled to a memory (eg, a cache or system memory) and an array of execution units 1014. In several embodiments, the sampling engine 1030 provides a memory access mechanism that executes the cell array 1014, allowing the execution cell array 1014 to read graphics and media material from memory. In several embodiments, the sampling engine 1030 includes logic to implement a particular image sampling job for the media.

In some embodiments, the particular media sampling logic in the sampling engine 1030 includes a de-noising/de-interlacing module 1032, a dynamic estimation module 1034, and an image scaling and filtering ring module 1036. In some embodiments, the de-noising/de-interlacing module 1032 includes logic to implement one or more de-noising or de-interlacing algorithms on the decoded video material. The interleaving logic combines the interlaced fields of the interlaced video content into a single video frame. The noise logic reduces or removes data noise from video and image data. In some embodiments, the denoising logic and deinterleaving logic are adjusted as a function of motion and spatial or temporal filtering is used depending on the number of actions detected in the video material. In some embodiments, the de-noising/de-interlacing module 1032 includes dedicated motion detection logic (eg, within the motion estimation engine 1034).

In some embodiments, the motion estimation engine 1034 provides hardware acceleration of the videowork by implementing a video acceleration function, such as motion vector estimation and prediction of video data. The motion estimation engine determines an action vector that describes the conversion of image data between successive video frames. In some embodiments, the graphics processor media codec uses a video motion estimation engine At 1034, the operation is performed on the video of the macro block level, which may be implemented by a general purpose processor because the operation is too concentrated. In some embodiments, the motion estimation engine 1034 is generally operable with graphics processor components to assist in video decoding and processing functions that are sensitive or tuned to the direction and magnitude of motion within the video material.

In some embodiments, the image scaling and filtering ring module 1036 performs image processing operations to enhance the visual quality of the resulting image and video. In some embodiments, the scaling and filtering ring module 1036 processes the image and video material during the sampling operation prior to providing the data to the array of execution units 1014.

In several embodiments, GPE 1010 includes data 埠 1044 that provides additional mechanisms to the graphics subsystem to access memory. In some embodiments, the data volume 1044 facilitates memory access to the job, including rendering target writes, constant buffer reads, temporary memory space read/write, and media surface access. In some embodiments, the data volume 1044 includes a cache memory space of the cache memory access memory. The cache memory can be a single data cache or a multi-subsystem cache memory, which is accessed via data files (such as rendering buffer cache memory, constant buffer cache memory, etc.). Memory. In some embodiments, the threads are executed on the execution units in the execution unit array 1014, and the information is exchanged via the data distribution interconnects of each of the subsystems of the GPE 1010 to communicate with the data.

11 is a block diagram of another embodiment of a graphics processor 1100. The elements of Figure 11 have elements associated with any of the other figures in the text. The same reference number (or name) may be operated or actuated in any manner similar to that described anywhere in the text, but is not limited thereto.

In several embodiments, graphics processor 1100 includes a ring interconnect 1102, a pipeline front end 1104, a media engine 1137, and graphics cores 1180A-1180N. In several embodiments, the ring interconnect 1102 is coupled to a graphics processor to other processing units, including other graphics processors or one or more general purpose processor cores. In several embodiments, the graphics processor is one of many processors integrated into a multi-core processing system.

In several embodiments, graphics processor 1100 receives a number of batches of commands via ring interconnect 1102. The import command is interpreted by the command stream 1103 in the pipeline front end 1104. In several embodiments, graphics processor 1100 includes scalable execution logic to implement 3D geometry processing and media processing via graphics cores 1180A-1180N. For the 3D geometry processing command, the command streamer 1103 supplies commands to the geometry pipeline 1136. In terms of at least a number of media processing commands, the command streamer 1103 supplies commands to the video front end 1134 that are coupled to the media engine 1137. In some embodiments, media engine 1137 includes a video quality engine (VQF) 1130 for video and image post-processing and multi-format encoding/decoding (MFX) engine 1133 to provide hardware accelerated encoding and decoding of media data. In some embodiments, geometry pipeline 1136 and media engine 1137 each generate threads for at least one thread execution resource provided by graphics core 1180A.

In several embodiments, graphics processor 1100 includes scalable thread execution resource feature module cores 1180A-1180N (sometimes referred to as core slices), each having multiple sub-cores 1150A-1150N, 1160A- 1160N (sometimes called a core sub-slice). In several embodiments, graphics processor 1100 can have any number of graphics cores 1180A through 1180N. In several embodiments, graphics processor 1100 includes a graphics core 1180A having at least a first sub-core 1150A and a second core sub-core 1160A. In other embodiments, the graphics processor is a low power processor with a single sub-core (eg, 1150A). In several embodiments, graphics processor 1100 includes multiple graphics cores 1180A-1180N, each including a first sub-core set 1150A-1150N and a second sub-core set 1160A-1160N. Each of the first sub-core sets 1150A-1150N includes at least a first set of execution units 1152A-1152N and media/texture samplers 1154A-1154N. Each of the second sub-core sets 1160A-1160N includes at least a second set of execution units 1162A-1162N and samplers 1164A-1164N. In several embodiments, each sub-core 1150A-1150N, 1160A-1160N shares a common resource group 1170A-1170N. In several embodiments, the common resources include public cache memory and pixel job logic. Other common resources may also be included in various embodiments of the graphics processor.

Figure 12 depicts thread execution logic 1200 that includes an array of processing elements employed in several embodiments of the GPE. The elements of Figure 12 have the same reference numbers (or names) as the elements of any other figures in the text, and may operate or behave in any manner similar to that described anywhere in the text, but are not limited thereto.

In several embodiments, thread execution logic 1200 includes a pixel shader 1202, a thread scheduler 1204, an instruction cache memory 1206, and a scalable execution list including a plurality of execution units 1208A-1208N. The element array, the sampler 1210, the data cache memory 1212, and the data port 1214. In an embodiment, the components included are interconnected via an interconnect fabric that links each component. In several embodiments, thread execution logic 1200 includes one or more connections to a memory such as system memory or cache memory; to one or more of one or more instruction caches 1206 Connections; data 埠 1214; sampler 1210; and array of execution units 1208A-1208N. In several embodiments, each execution unit (e.g., 1208A) is an individual vector processor that can execute multiple synchronization threads and process multiple data elements in parallel for each thread. In several embodiments, the array of execution units 1208A-1208N includes any number of individual execution units.

In some embodiments, the execution unit arrays 1208A-1208N are primarily used to execute a "shader" program. In several embodiments, the execution units in arrays 1208A-1208N execute a set of instructions, including native support for a number of standard 3D graphics shader instructions, such that colorizer programs from graphics libraries (eg, direct 3D and OpenGL) are executed with minimal translation. Execution units support vertex and geometry processing (such as vertex programs, geometry programs, vertex shaders), pixel processing (such as pixel shaders, block shaders), and general processing (such as arithmetic and media shaders).

Each of the execution unit arrays 1208A-1208N operates on an array of data elements. The number of data elements is the "execution size" or the number of channels of the command. The execution channel is a logic unit that performs flow control of data element access, masking, and instructions. The number of channels can be independent of the number of physical arithmetic logic units (ALUs) or floating point units (FPUs) of a particular graphics processor. In several embodiments, execution unit 1208A- 1208N supports integer and floating point data types.

The execution unit instruction set includes a single instruction multiple data (SIMD) instruction. Various data components can be stored in the scratchpad in the package data type, and the execution unit will process various components according to the data size of the component. For example, when working on a 256-bit wide vector, the 256-bit vector is stored in the scratchpad, and the execution unit operates in a vector of 4 individual 64-bit packed data elements (quad-word (QW) size data elements). , 8 individual 32-bit package data components (double word (DW) size data components), 16 individual 16-bit package data components (word (W) size data components), or 32 individual 8-bit data components (bytes) (B) Size data component). However, different vector widths and scratchpad sizes are also possible.

One or more internal instruction caches (e.g., 1206) are included in thread execution logic 1200 to cache thread execution instructions. In some embodiments, one or more data caches (e.g., 1212) are included, and thread data is cached during thread execution. In several embodiments, a sampler 1210 is included to provide texture sampling of 3D jobs and media sampling of media jobs. In several embodiments, the sampler 1210 includes a particular texture or media sampling function, and the texture or media material is processed during the sampling process prior to providing the sampled data to the execution unit.

During execution, the graphics and media pipeline sends a thread initiation request to thread execution logic 1200 via thread generation and scheduling logic. In several embodiments, thread execution logic 1200 includes a native thread scheduler 1204 that arbitrates execution from graphics and media pipelines. The request is initiated and the requested thread is instantiated on one or more execution units 1208A-1208N. For example, a geometry pipeline (e.g., 1136 of Figure 11) schedules vertex processing, tiling, or geometry processing threads for thread execution logic 1200 (Fig. 12). In some embodiments, the thread scheduler 1204 can also process a runtime thread generation request from the execution shader program.

Once the geometry object group is processed and rasterized into pixel data, pixel shader 1202 is invoked to further manipulate the output information and cause the results to be written to the output surface (eg, color buffer, depth buffer, stencil buffer, etc.). In several embodiments, pixel shader 1202 calculates values for various vertex attributes that are interpolated across the tiling. In several embodiments, pixel shader 1202 then performs an application programming interface (API) that supplies the pixel shader program. To execute the pixel shader program, pixel shader 1202 dispatches threads to the execution unit (eg, 1208A) via thread scheduler 1204. In several embodiments, pixel shader 1202 uses texture sampling logic in sampler 1210 to access texture data stored in texture maps in memory. The arithmetic data on the texture data and the input geometry computes the pixel color data of each geometric data block, or discards one or more pixels from further processing.

In some embodiments, the data port 1214 provides a memory access mechanism for the thread execution logic 1200, and outputs the processed data to the memory for processing on the graphics processor output pipeline. In some embodiments, the data file 1214 includes or is coupled to one or more cache memories (eg, data cache memory 1212), and the data is cached via the data cache. Physical access data.

FIG. 13 is a block diagram depicting a graphics processor instruction format 1300 in accordance with several embodiments. In one or more embodiments, the graphics processor execution unit supports an instruction set having multiple format instructions. The solid line drawing depicts components that are typically included in the execution unit instructions, while the dashed lines include components that are optional or only included in the subset of instructions. In several embodiments, the described and depicted instruction format 1300 is a macro instruction in which a macro instruction is supplied to an instruction of an execution unit relative to a micro-operation derived from instruction decoding.

In several embodiments, the graphics processor execution unit natively supports instructions in the 128-bit format 1310. The 64-bit compact instruction format 1330 can be used for several instructions depending on the instruction selected, the instruction options, and the number of operands. The native 128-bit format 1310 provides access to all instruction options while several options and operations are limited to the 64-bit format 1330. Native instructions that may be used in 64-bit format 1330 vary from embodiment to embodiment. In several embodiments, the portion is indexed using a set of index values in index column 1313. The execution unit hardware references a set of compact tables based on the index values and reconstructs the native instructions of the 128-bit format 1310 using the compact table output.

For each format, the instruction opcode 1312 defines the job that the execution unit will perform. The execution unit executes each instruction side by side across multiple data elements per operand. For example, in response to the addition instruction, the execution unit performs a synchronous addition operation across each color channel representing the texture element or image element. By presetting, the execution unit implements each instruction across all data channels of the operand. In several embodiments, the instruction control bar 1314 enables control of certain execution options, such as channel selection (eg, prediction) and data channel order (eg, blending). For the 128-bit instruction 1310, the execution size column 1316 limits the number of data channels that will be executed side by side. In several embodiments, the execution size column 1316 cannot be used with the 64-bit compact instruction format 1330.

A number of execution unit instructions have up to three operands, including two source operands SRC0 1320, SRC1 1322, and a destination 1318. In several embodiments, the execution unit supports dual destination instructions, one of which is implicit. The data mediation instruction can have a third source operand (e.g., SRC2 1324), wherein the instruction opcode 1312 determines the number of source operands. The last source operand of the instruction may be an immediate (eg hard coded) value passed by the instruction.

In several embodiments, the 128-bit instruction format 1310 includes access/address mode information 1326 that specifies, for example, a direct register addressing mode or an indirect register addressing mode. When the direct register addressing mode is used, the bits in instruction 1310 directly provide one or more operand register addresses.

In several embodiments, the 128-bit instruction format 1310 includes an access/address mode field 1326 that specifies the address mode and/or access mode of the instruction. In one embodiment, the access mode defines the data access alignment of the instructions. Several embodiments support access modes, including a 16-bit aligned access mode and a 1-bit aligned access mode, where the byte alignment of the access mode determines the access alignment of the instruction operand. For example, when in the first mode, the instruction 1310 can use a pair of source and destination operands. Uniform addressing, when in the second mode, the instruction 1310 can use 16-bit alignment alignment of all source and destination operands.

In one embodiment, the address mode portion of the access/address mode field 1326 determines whether the instruction is to use direct or indirect addressing. When the direct register addressing mode is used, the bits in instruction 1310 directly provide one or more operand register addresses. When the indirect scratchpad addressing mode is used, the register address of one or more operands can be operated according to the address register value and the address immediate column in the instruction.

In several embodiments, the instructions are clustered according to the operation code 1312 bit field to simplify the opcode decoding 1340. For 8-bit opcodes, bits 10, 11, and 12 allow the execution unit to determine the opcode type. The exact opcode cluster shown is only an example. In several embodiments, the mobile and logical opcode cluster 1342 includes data movement and logic instructions (eg, move (mov), compare (cmp)). In several embodiments, the mobile and logical cluster 1342 shares the five most efficient bits (MSBs), with the move (mov) command in the form of 0000xxxxb and the logical command in the form of 0001xxxxb. The flow control instruction cluster 1344 (eg, call, jump (jmp)) includes instructions in the form of 0010xxxxb (eg, 0x20). Miscellaneous instruction cluster 1346 includes instruction mixes, including synchronization instructions (eg, wait, send) in the form of 0011xxxxb (eg, 0x30). The parallel math instruction cluster 1348 includes component-form arithmetic instructions (eg, addition, multiplication (mul)) in the form of 0100xxxxb (eg, 0x40). The parallel math cluster 1348 performs arithmetic operations side by side across the data channel. Vector math cluster 1350 includes arithmetic instructions in the form of 0101xxxxb (eg, 0x50) (eg dp4). Vector mathematics clusters perform arithmetic on vector arithmetic elements, such as point product calculations.

14 is a block diagram of another embodiment of a graphics processor 1400. The elements of Figure 14 have the same reference numbers (or names) as the elements of any other figures in the text, and may operate or behave in any manner similar to that described anywhere in the text, but are not limited thereto.

In several embodiments, graphics processor 1400 includes graphics pipeline 1420, media pipeline 1430, display engine 1440, thread execution logic 1450, and presentation output pipeline 1470. In several embodiments, graphics processor 1400 is a graphics processor within a multi-core processing system that includes one or more general purpose processing cores. The graphics processor is controlled by a scratchpad written to one or more control registers (not shown) or via a command issued by the ring interconnect 1402 to the graphics processor 1400. In several embodiments, the ring interconnect 1402 couples the graphics processor 1400 to other processing components, such as other graphics processors or general purpose processors. Commands from the ring interconnect 1402 are interpreted by the command streamer 1403, which supplies instructions to individual components of the graphics pipeline 1420 or media pipeline 1430.

In several embodiments, command streamer 1403 indicates the job of vertex recipient 1405, which reads vertex data from memory and executes vertex processing commands provided by command streamer 1403. In several embodiments, vertex recipient 1405 provides vertex data to vertex shader 1407 that implements coordinate space conversion and lighting operations to each vertex. In several embodiments, vertex recipient 1405 and vertex shader 1407 schedule threads to execution unit 1452A via thread scheduler 1431, 1452B, while executing vertex processing instructions.

In several embodiments, execution units 1452A, 1452B are arrays of vector processors having an instruction set that implements graphics and media jobs. In several embodiments, execution units 1452A, 1452B have an attached L1 cache memory 1451 that is specific to each array or common between arrays. The cache memory can be configured as a data cache memory, an instruction cache memory, or a single cache memory, and the partition includes data and instructions of different partitions.

In several embodiments, graphics pipeline 1420 includes a tile assembly to implement a hardware accelerated overlay of the 3D object. In several embodiments, the programmable shell shader 1411 is assembled with a tiling operation. The programmable field shader 1417 provides a measurment output backend evaluation. The tessellator 1413 operates in the direction of the hull shader 1411 and includes dedicated logic to produce a set of detailed geometric objects in accordance with a coarse geometric model provided as input to the graphics pipeline 1420. In several embodiments, the ply assemblies 1411, 1413, 1417 may be skipped if a close shop is not used.

In several embodiments, the complete geometry may be processed by one or more threads of scheduling to execution units 1452A, 1452B by geometry shader 1419, or may proceed directly to chopper 1429. In several embodiments, the geometry shader operates on the entire geometry object rather than the vertices or vertices in the previous stages of the graphics pipeline. If the tile is disabled, the geometry shader 1419 receives the input from the vertex shader 1407. In several embodiments, if the tiling unit is deactivated, the geometry shader 1419 can be programmed by the geometry shader program to implement geometric tiling.

The chopper 1429 processes the vertex data prior to rasterization. The chopper 1429 can be a fixed function chopper or a programmable chopper with chopping and geometry shader functions. In several embodiments, the rasterizer/depth 1473 in the output pipeline 1470 is scheduled to align pixel shaders, while the geometric objects are converted to their respective pixel representations. In several embodiments, pixel shader logic is included in thread execution logic 1450. In several embodiments, the application may bypass the rasterizer 1473 and access the unrasterized vertex material via the outflow unit 1423.

The graphics processor 1400 has an interconnect bus, an interconnect fabric, or several other interconnect mechanisms that allow data and information to pass between the main components of the processor. In some embodiments, execution units 1452A, 1452B and associated cache memory 1451, texture and media sampler 1454, and texture/sampler cache 1458 are interconnected via data port 1456 to implement memory access and Communicates with the presentation output pipeline component of the processor. In several embodiments, sampler 1454, cache memory 1451, 1458, and execution units 1452A, 1452B each have different memory access paths.

In several embodiments, the rendering output pipeline 1470 includes a rasterizer and depth testing component 1473 that converts vertice-based objects into related pixel-based representations. In several embodiments, the rasterizer logic includes a window/masker unit to implement fixed function triangles and line rasterization. In several embodiments, the associated presentation cache 1478 and deep cache 1479 are available. Pixel job component 1477 implements pixel-based jobs on the data, although in some cases, pixel work associated with 2D jobs (eg, mixed bit block image transfer) is implemented by 2D engine 1441 or replaced by display controller 1443 using overlay display planes when displayed. In several embodiments, the shared L3 cache memory 1475 can be used for all graphics components, allowing data sharing without using main system memory.

In some embodiments, graphics processor media pipeline 1430 includes media engine 1437 and video front end 1434. In several embodiments, video front end 1434 receives a pipeline command from command streamer 1403. In several embodiments, media pipeline 1430 includes different command streams. In some embodiments, video front end 1434 processes media commands prior to sending a command to media engine 1437. In several embodiments, media engine 1437 includes a thread generation function to generate threads that schedule thread execution logic 1450 via thread scheduler 1431.

In several embodiments, graphics processor 1400 includes display engine 1440. In several embodiments, display engine 1440 is external to processor 1400 and is coupled to the graphics processor via ring interconnect 1402 or a number of other interconnect busses or architectures. In several embodiments, display engine 1440 includes a 2D engine 1441 and a display controller 1443. In several embodiments, display engine 1440 includes dedicated logic that can operate independently of the 3D pipeline. In some embodiments, display controller 1443 is coupled to a display device (not shown), which can be a system integrated display device, such as in a laptop computer, or an external display device attached via a display device connector.

In some embodiments, graphics pipeline 1420 and media pipeline 1430 can be configured to perform operations in accordance with multiple graphics and media programming interfaces, and are not limited to any application programming interface (API). In several embodiments, the figure The driver software of the processor translates API calls of a particular graphics or media library into commands that can be processed by the graphics processor. In several embodiments, the support system provides Open Graphics Library (OpenGL) and Open Computing Language (OpenCL) for Khronos organizations, Microsoft's direct 3D library, or support for OpenGL and D3D. Support is also available for Open Source Edition (OpenCV). Future APIs with compatible 3D pipelines can also be supported if they can be mapped from the pipeline of the future API to the pipeline of the graphics processor.

Figure 15A is a block diagram depicting a graphics processor command format 1500 in accordance with several embodiments. Figure 15B is a block diagram depicting a graphics processor command sequence 1510, in accordance with an embodiment. The solid lined box in Figure 15A depicts the components typically included in the graphics commands, while the dashed lines include components that are optional or only included in a subset of the graphics commands. The example graphics processor command format 1500 of FIG. 15A includes a data field to identify a target client 1502, a command job code (opcode) 1504, and a related material 1506 for the command. Sub-opcode 1505 and command size 1508 are also included in several commands.

In several embodiments, client 1502 indicates a client unit of a graphics device that processes command material. In several embodiments, the graphics processor command parser checks the client bar of each command to determine further processing of the command and passes the command material to the appropriate client unit. In some embodiments, the graphics processor client unit includes a memory interface unit, a presentation unit, a 2D unit, a 3D unit, and a media unit. Each client unit has a corresponding processing pipeline that processes the commands. Once the client unit receives the command, the client unit reads the opcode 1504 and reads the sub-opcode 1505 (if In order to determine the implementation of the operation. The client unit uses the information in the data column 1506 to implement the command. For several commands, the command size 1508 is expected to be specified to specify the size of the command. In several embodiments, the command parser automatically determines the size of at least a number of commands based on the command opcode. In several embodiments, the commands are aligned via a plurality of double words.

The flowchart in Figure 15B shows an example graphics processor command sequence 1510. In some embodiments, the software or body of the data processing system is characterized in that the embodiment of the graphics processor establishes execution using the version of the command sequence shown, and terminates a set of graphics jobs. The sample command sequences shown and described are merely examples of embodiments and are not limited to the particular commands or sequences of such commands. Furthermore, the command can be issued as a batch of commands in the command sequence such that the graphics processor will process the command sequence at least partially simultaneously.

In several embodiments, the graphics processor command sequence 1510 can be expanded based on the pipeline refresh command 1512 to cause any active graphics pipeline to complete the pending command of the pipeline. In several embodiments, 3D pipeline 1522 and media pipeline 1524 are not operating simultaneously. A pipeline refresh is implemented to cause the active graphics pipeline to complete any pending commands. In response to the pipeline refresh, the graphics processor's command parser will suspend command processing until the active traction engine completes the pending job and the associated read cache memory is invalid. Optionally, any data in the presentation cache marked as "used" can be refreshed to the memory. In several embodiments, the pipeline refresh command 1512 can be used for pipeline synchronization before the graphics processor is placed in a low power state.

In several embodiments, the pipeline selection command 1513 is used when the command sequence requires the graphics processor to explicitly switch between pipelines. In several embodiments, the pipeline selection command 1513 only needs to execute the context before issuing the pipeline command, unless the context is a command to issue a pipeline. In several embodiments, a pipeline refresh command 1512 is required immediately prior to pipeline switching via pipeline select command 1513.

In several embodiments, the pipeline control command 1514 assembles a graphical pipeline of operations and is used to program the 3D pipeline 1522 and the media pipeline 1524. In several embodiments, the pipeline control command 1514 sets the pipeline status of the pipeline. In one embodiment, pipeline control command 1514 is used for pipeline synchronization and clears data from one or more cache memories in the active pipeline before processing a batch of commands.

In several embodiments, the return buffer status command 1516 is used to assemble a group of individual pipeline return buffers to write data. Several pipeline operations require configuration, selection, or configuration of one or more return buffers, where the job writes intermediate data during processing. In some embodiments, the graphics processor also uses one or more return buffers to store output data and implement cross-thread communication. In several embodiments, the return buffer state 1516 includes the selection size and the number of return buffers for the pipeline job set.

The remaining commands in the command sequence vary based on the active pipeline of the job. In accordance with pipeline decision 1520, the command sequence is dedicated to 3D pipeline 1522, starting from 3D pipeline state 1530, or from media pipeline 1524 of media pipeline state 1540.

The 3D pipeline state 1530 command includes a 3D state setting command for vertex buffer state, vertex component state, constant color shape State, depth buffer state, and other state variables that are assembled before the 3D primitive command is processed. The values of these commands are determined, at least in part, by the particular 3DAPI used. In some embodiments, the 3D pipeline state 1530 command may also selectively disable or skip certain pipeline components if the components are not to be used.

In several embodiments, the 3D primitive 1532 commands the submission of 3D primitives to be processed by the 3D pipeline. The commands and associated parameters passed to the graphics processor via the 3D primitive 1532 command are passed to the vertex extraction function in the graphics pipeline. The vertex extraction function uses 3D primitive 1532 command data to generate a vertex data structure. The vertex data structure is stored in one or more return registers. In several embodiments, the 3D primitive 1532 commands to implement a vertex job on the 3D primitive via the vertex shader. To process the vertex shader, the 3D pipeline 1522 dispatches the shader thread to the graphics processor execution unit.

In several embodiments, the 3D pipeline 1522 is triggered by executing a 1534 command or event. In several embodiments, the scratchpad write triggers command execution. In some embodiments, execution is triggered via a "forward" or "kick-out" command in the command sequence. In an embodiment, a pipeline synchronization command is used to trigger command execution to refresh the command sequence to the graphics pipeline. The 3D pipeline will implement the geometry processing of the 3D primitives. Once the job is complete, the final geometry is rasterized and the pixel engine colors the final pixels. Additional commands for controlling pixel masking and pixel back-end operations may also be included for such operations.

In several embodiments, the graphics processor command sequence 1510 follows the path of the media pipeline 1524 when the media job is implemented. Usually, the media The particular use and programming of the bodyline 1524 depends on the media or computing operation to be performed. A particular media decoding job can be offloaded to the media pipeline during media decoding. In some embodiments, the media pipeline may also be skipped and media decoding may be performed in whole or in part using resources provided by one or more general processing cores. In one embodiment, the media pipeline also includes components of a general purpose graphics processor unit (GPGPU) job, wherein the graphics processor is configured to implement SIMD vector operations using an operational shader program that is not explicitly related to the rendering of graphics primitives.

In several embodiments, media line 1524 is assembled in a manner similar to 3D pipeline 1522. A set of media pipeline status commands 1540 are scheduled or placed in the command queue prior to media object command 1542. In several embodiments, media pipeline status command 1540 includes data to assemble media pipeline elements that will be used to process media objects. This includes data and the video decoding and video encoding logic is grouped into a media pipeline, such as an encoding or decoding format. In some embodiments, the media pipeline status command 1540 also supports the use of one or more metrics of the "indirect" status element, which includes a batch of status settings.

In several embodiments, the media item command 1542 provides an indicator to the media item for processing by the media pipeline. The media object includes a memory buffer containing the video material to be processed. In several embodiments, all media pipeline states must be valid before the media object command 1542 is issued. Once the pipeline state is assembled with the media object command 1542, the media pipeline 1524 is triggered via execution of command 1544 or an equivalent execution event (eg, a scratchpad write). The output from media pipeline 1524 can then Job post processing provided by 3D pipeline 1522 or media pipeline 1524. In several embodiments, GPGPU jobs are assembled and executed in a manner similar to media jobs.

16 depicts an example graphics software architecture of data processing system 1600, in accordance with several embodiments. In some embodiments, the software architecture includes a 3D graphics application 1610, an operating system 1620, and at least one processor 1630. In several embodiments, processor 1630 includes a graphics processor 1632 and one or more general purpose processor cores 1634. Graphics application 1610 and operating system 1620 are each executed in system memory 1650 of the data processing system.

In several embodiments, the 3D graphics application 1610 includes one or more shader programs, including shader instructions 1612. The shader language instructions can be high order shader languages such as High Order Shader Language (HLSL) or OpenGL Shader Language (GLSL). The application also includes executable instructions 1614, which are machine languages suitable for execution by general purpose processor core 1634. The application also includes a graphical object 1616 defined by vertex data.

In several embodiments, operating system 1620 is a Microsoft Windows® operating system from Microsoft Corporation, a proprietary UNIX-based operating system, or an open source UNIX operating system that uses a Linux kernel variant. When using the direct SD API, the operating system 1620 uses the front end shader compiler 1624 to compile any shader instructions 1612 of the HLSL into a lower order shader language. Compilation can be implemented for just-in-time (JIT) compilation or application-implementable shader precompilation. In several embodiments Medium-level shaders are compiled into low-order shaders during 3D graphics application 1610 compilation.

In several embodiments, the user mode graphics driver 1626 includes a backend shader compiler 1627 that converts the shader instructions 1612 into hardware specific representations. When the OpenGL API is used, the GLSL high level language color shader instructions 1612 are passed to the user mode graphics driver 1626 for compilation. In several embodiments, the user mode graphics driver 1626 communicates with the kernel mode graphics driver 1629 using the operating system kernel mode function 1628. In several embodiments, kernel mode graphics driver 1629 communicates with graphics processor 1632 to schedule commands and instructions.

One or more aspects of at least one embodiment may be implemented by a representative code stored on a machine readable medium that represents and/or defines logic within an integrated circuit, such as a processor. For example, machine readable media can include instructions that represent various logic within the processor. When the machine reads, the instructions may cause the machine to make logic to implement the techniques described herein. These representatives are known as "IP cores", which are logical reusable units of integrated circuits that can be stored on a tangible medium of a physical machine as a hardware model to describe the structure of the integrated circuit. The hardware model can be supplied to various customers or manufacturers who load the hardware model on the manufacturing machine to manufacture the integrated circuit. The integrated circuit can be fabricated such that the circuit performs the operations described in connection with any of the embodiments described herein.

17 is a block diagram depicting an IP core development system 1700 that can be used to fabricate an integrated circuit to perform an operation, in accordance with an embodiment. The IP Core Development System 1700 can be used to create a modular reusable design that can Into a larger design or to build the entire integrated circuit (such as SOC integrated circuit). The design facility 1730 can generate a software simulation 1710 of an IP core design of a high-level programming language (eg, C/C++). Software Simulation 1710 can be used to design, test, and verify the behavior of IP cores. A scratchpad transfer stage (RTL) design can then be fabricated or synthesized from the simulation model 1700. The RTL design 1715 is an abstraction of the behavior of the integrated circuit, which is a model of the digital signal flow between the hardware registers, including the associated logic implemented using the model digital signals. In addition to the RTL design 1715, low-order designs of logic or transistor levels can be fabricated, designed, or synthesized. Thus, the specific details of the initial design and simulation can vary.

The RTL design 1715 or equivalent may be further synthesized by designing the hardware model 1720, which may be a hardware description language (HDL), or several other representations of physical design data. The HDL can be further simulated or tested to verify the IP core design. Using non-volatile memory 1740 (eg, hard disk, flash memory, or any non-volatile storage device media), the storable IP core is designed for delivery to third party manufacturing facility 1765. Alternatively, the IP core design can be transmitted (e.g., via the Internet) via a wired connection 1750 or a wireless connection 1760. Manufacturing facility 1765 can then fabricate integrated circuitry that is at least partially designed in accordance with the IP core. According to at least one embodiment described herein, the integrated circuit can be assembled to perform the work.

18 is a block diagram depicting an example system wafer integration circuit 1800 that may be fabricated using one or more IP cores, in accordance with an embodiment. An example integrated circuit includes one or more application processors 1805 (eg, For example, the CPU), at least one graphics processor 1810, may further include an image processor 1815 and/or a video processor 1820, either of which may be modular IP cores from the same or a plurality of different design facilities. The integrated circuit includes peripheral devices or bus logic, including a USB controller 1825, a UART controller 1830, an SPI/SDIO controller 1835, and an I2S/I2C controller 1840. In addition, the integrated circuit can include a display device 1845 coupled to one or more high resolution multimedia interface (HDMI) controllers 1850 and a mobile industry processor interface (M1P1) display interface 1855. The storage device can be provided by a flash memory subsystem 1860, including a flash memory and a flash memory controller. The memory interface can be provided via memory controller 1865 for accessing SDRAM or SRAM memory devices. In addition, a number of integrated circuits include an embedded security engine 1870.

In addition, other logic and circuitry may be included in the processor of integrated circuit 1800, including additional graphics processors/cores, peripheral device interface controllers, or general purpose processor cores.

The following examples pertain to further embodiments. Example 1 includes an apparatus comprising: a graphics processing unit (GPU) that copies at least a first portion of a data block from a source to a buffer, and a second portion that copies a data block from a source to a destination; and a central processing unit ( CPU), copying the first portion of the data block from the buffer to one or more corresponding locations in the destination. Example 2 includes the device of example 1, wherein the first portion of the data block includes the first data at the beginning of the data block or the second data at the end of the data block. Example 3 includes the device of example 2, wherein the first data and the second data each have a size smaller than a memory unit. Example 4 includes the design of Example 3. In this case, the memory unit contains a cache column or a 64-bit tuple. Example 5 includes the device of example 1, wherein the second portion of the data block comprises one or more complete memory units. Example 6 includes the device of example 5, wherein each of the one or more full memory cells comprises a 64-bit tuple. Example 7 includes the device of example 1, wherein the source comprises video memory coupled to the GPU. Example 8 includes the device of example 1, wherein the destination comprises system memory coupled to the CPU. Example 9 includes the device of example 1, wherein the GPU includes one or more graphics processing cores. Example 10 includes the device of example 1, wherein the CPU includes one or more processor cores. Example 11 includes the device of example 1, wherein one or more GPUs, CPUs, or memory systems are on a single integrated circuit die.

Example 12 includes a system comprising: a processor coupled to the system memory, the system memory storing the data block copied from the video memory, the processor comprising: a graphics processing unit (GPU) for copying: the data block The first part, from the video memory to the first buffer; the second part of the data block, from the video memory to the system memory; and the third part of the data block, from the video memory to the second buffer And a central processing unit (CPU) for copying: the first portion of the data block, from the first buffer to the corresponding location in the system memory; and the second portion of the data block, from the second buffer to The corresponding location in the system memory. Example 13 includes the system of example 12, wherein the data block is sequentially composed of the first portion, the second portion, and the third portion. Example 14 includes the system of example 12, wherein the first and third portions of the data block each contain fewer bytes than the memory unit. Example 15 includes the system of example 14, wherein the memory unit Contains cached columns or 64-bit tuples. Example 16 includes the system of example 12, wherein the second portion of the data block comprises one or more complete memory units. Example 17 includes the system of example 16, wherein each of the one or more full memory units comprises a 64-bit tuple. Example 18 includes the system of example 12, wherein the first buffer and the second buffer are combined into a single buffer. Example 19 includes the system of example 12, wherein one or more GPUs having one or more graphics processing cores, a CPU having one or more processor cores, at least a portion of system memory, or at least a portion of video memory The system is on a single integrated circuit die.

Example 20 includes a computer readable medium containing one or more instructions that, when executed on a processor, assemble a processor to perform one or more jobs to: cause a graphics processing unit (GPU), Copying at least a first portion of the data block from the source to the buffer, and copying the second portion of the data block from the source to the destination; and causing the central processing unit (CPU) to pass from the first buffer to the destination More of the corresponding location copies the first part of the data block. Example 21 includes the computer readable medium of example 20, wherein the first portion of the data block includes the first data at the beginning of the data block or the second data at the end of the data block. The example 22 includes the computer readable medium of the example 21, wherein the first data and the second data each have a size smaller than a memory unit. Example 23 includes the computer readable medium of Example 22, wherein the memory unit comprises a cache line or a 64-bit tuple. Example 24 includes the computer readable medium of example 20, wherein the second portion of the data block comprises one or more complete memory units. Example 25 includes the computer readable medium of Example 20, wherein one or more complete Each of the memory cells contains a 64-bit tuple.

Example 26 includes a method comprising: causing a graphics processing unit (GPU) to copy at least a first portion of a data block from a source to a buffer, and copying a second portion of the data block from a source to a destination; and causing central processing A unit (CPU) that copies the first portion of the data block from the first buffer to one or more corresponding locations in the destination. Example 27 includes the method of example 26, wherein the first portion of the data block includes the first data at the beginning of the data block, or the second data at the end of the data block, or the second portion of the data block One or more complete memory cells are included, or wherein each of the one or more full memory cells comprises a 64-bit tuple. Example 28 includes the method of example 27, wherein the first data and the second data each have a size smaller than a memory unit. Example 29 includes the method of example 28, wherein the memory unit comprises a cache line or a 64-bit tuple.

Example 30 includes an apparatus that includes mechanisms to implement the method as set forth in any of the preceding examples. Example 31 includes a machine readable storage device that includes machine readable instructions that, when executed, implement or implement a method or apparatus as set forth in any of the preceding examples.

In various embodiments, the operations discussed herein, for example, with reference to Figures 1-18, may be implemented as a hardware (e.g., logic circuit), a software, a body, or a combination thereof, which may be provided as a computer program product, including, for example, An entity (eg, non-transitory) machine readable or computer readable medium having instructions (or software programs) stored thereon for programming a computer to implement the procedures discussed herein. Machine readable media may include storage devices such as those discussed with reference to Figures 1-18.

In addition, the computer readable medium can be downloaded as a computer program product, wherein the program can be transmitted via a communication link (such as a bus, a data machine, or a network connection) via a data signal provided on a carrier wave or other communication medium. And from a remote computer (such as a server) to a requesting computer (such as a customer).

Reference is made to the "an embodiment" or "an embodiment" or "an embodiment" or "an" The phrase "in one embodiment", which is used throughout the specification, may or may not mean the same embodiment.

Moreover, in the description and application, the words "coupled" and "connected" may be used together with their derivatives. In several embodiments, "connected" may be used to mean that two or more elements are in direct physical or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements are not in direct contact with each other, but can still cooperate or interact with each other.

Accordingly, while the embodiments have been described in the language of the embodiments of the embodiments of the invention, it is understood that the claimed subject matter is not limited to the specific components or acts described. Rather, the specific components and acts are disclosed as a sample format for implementing the claimed subject matter.

114‧‧‧ memory

150‧‧‧Video Memory

202‧‧‧Storage device

Claims (24)

A device comprising: a graphics processing unit (GPU), copying at least a first portion of a data block from a source to a buffer, and copying a second portion of the data block from the source to a destination; and a central processing unit (CPU) Copying the first portion of the data block from the buffer to one or more corresponding locations in the destination. The device of claim 1, wherein the first portion of the data block includes the first data at the beginning of the data block or the second data at the end of the data block. The device of claim 2, wherein the first data and the second data each have a size smaller than a memory unit. The device of claim 3, wherein the memory unit comprises a cache column or a 64-bit tuple. The device of claim 1, wherein the second portion of the data block comprises one or more complete memory units. The device of claim 5, wherein each of the one or more complete memory units comprises a 64-bit tuple. The device of claim 1, wherein the source comprises video memory coupled to the GPU. The device of claim 1, wherein the destination comprises system memory coupled to the CPU. The device of claim 1, wherein the GPU comprises one or more graphics processing cores. The device of claim 1, wherein the CPU comprises one or more processor cores. The device of claim 1, wherein the one or more of the GPU, the CPU, or the memory system are on a single integrated circuit die. A system includes a processor coupled to a system memory, the system memory storing a data block copied from the video memory, the processor comprising: a graphics processing unit (GPU) for copying: the data block The first part, from the video memory to the first buffer; the second part of the data block, from the video memory to the system memory; and the third part of the data block, from the video memory And a central processing unit (CPU) for copying: the first portion of the data block, from the first buffer to a corresponding location in the system memory; and the data block The second portion is from the second buffer to a corresponding location in the system memory. The system of claim 12, wherein the data block is sequentially composed of the first part, the second part, and the third part. Such as the system of claim 12, wherein the information The first portion and the third portion of the block each contain fewer bytes than the memory unit. A computer readable medium containing one or more instructions that, when executed on a processor, assemble the processor to perform one or more jobs to: cause a graphics processing unit (GPU), from a source Reaching at least a first portion of the buffer data block and copying the second portion of the data block from the source to the destination; and causing a central processing unit (CPU) to pass from the first buffer to the destination The first portion of the data block is copied by one or more corresponding locations. The computer readable medium as claimed in claim 15 wherein the first part of the data block includes the first data at the beginning of the data block or the second data at the end of the data block. The computer readable medium of claim 16, wherein the first data and the second data each have a size smaller than a memory unit. The computer readable medium of claim 17, wherein the memory unit comprises a cache column or a 64-bit tuple. A computer readable medium as claimed in claim 15 wherein the second portion of the data block comprises one or more complete memory units. A computer readable medium as claimed in claim 15 wherein each of the one or more full memory units comprises a 64-bit tuple. A method comprising: causing a graphics processing unit (GPU) to copy at least a first portion of a data block from a source to a buffer, and copying a second portion of the data block from the source to a destination; and causing a central processing unit (CPU) copying the first portion of the data block from the first buffer to the one or more corresponding locations in the destination. The method of claim 21, wherein the first part of the data block includes the first data at the beginning of the data block, or the second data at the end of the data block, or The second portion of the data block includes one or more complete memory units, or wherein each of the one or more complete memory units comprises a 64-bit unit. The method of claim 22, wherein the first data and the second data each have a size smaller than a memory unit. The method of claim 23, wherein the memory unit comprises a cache column or a 64-bit tuple.