JP5928914B2 - Graphics processing apparatus and graphics processing method - Google Patents

Description

  The present invention relates to a graphics processing technique for decompressing a compressed texture.

  High-quality images such as playing games and simulations using high-quality 3D computer graphics and playing video content that combines live-action and computer graphics on personal computers and game machines The use of graphics is spreading.

  In general, graphics processing is executed by cooperation of a CPU and a graphics processing unit (GPU). While the CPU is a general-purpose processor that performs general-purpose operations, the GPU is a dedicated processor for performing advanced graphics operations. The CPU performs a geometry calculation such as projection conversion based on the three-dimensional model of the object, and the GPU receives vertex data from the CPU and executes rendering. The GPU is composed of dedicated hardware such as a rasterizer and a pixel shader, and executes graphics processing by pipeline processing. Some recent GPUs have programmable shader functions called programmable shaders, and graphics libraries are generally provided to support shader programming.

  In the graphics processing, texture mapping is performed in which a texture is pasted on the surface of the object in order to express the texture of the surface of the object. As the images used in applications such as games become higher in definition, higher resolution data is used for textures, and the volume of texture data is increasing. For example, the texture used in the game is in the order of GiB (Gibibyte), and it is difficult to store all necessary texture data on the memory.

  In view of this, uncompressed textures or low-compressed textures that can be directly handled by the GPU are stored in a storage device such as a hard disk, and loaded into a texture buffer on a memory and used for drawing as necessary. The time it takes to load a texture from the hard disk is usually tens of milliseconds to sometimes several seconds and is not stable. Therefore, when the texture loading from the hard disk is not in time, there arises a problem that the texture to be originally displayed cannot be used.

  On the other hand, in the case of a highly compressed texture, even a texture exceeding the main memory capacity can be held in the memory, and the texture can be handled without loading from the hard disk. However, in this case, since the high-compression texture is generally not directly handled by the GPU, dedicated hardware for decompressing the high-compression texture in real time is required. If dedicated hardware is not available, the CPU will decompress the compressed texture and expand it in the texture buffer. In this case, however, it takes time to decompress and it becomes difficult to perform drawing in real time.

  The present invention has been made in view of these problems, and an object thereof is to provide a graphics processing technique capable of efficiently decompressing a compressed texture.

  In order to solve the above problems, a graphics processing device according to an aspect of the present invention is a graphics processing device including a main memory and a graphics processing unit, wherein the graphics processing unit has a run length of a compressed texture. A run-length decompression unit that performs decompression, and an inverse spatial frequency transform unit that restores the texture by subjecting the run-length decompressed texture to inverse spatial frequency transform. The main memory includes a texture pool that partially caches the restored texture.

  Another aspect of the present invention is a graphics processing method. This method is a graphics processing method in a graphics processing apparatus including a main memory and a graphics processing unit, and the graphics processing unit executes run-length decompression of a compressed texture by a compute shader, and the run-length decompression. The texture is restored by performing inverse spatial frequency transformation on the texture, and the restored texture is stored in the texture pool in the main memory that partially caches the texture.

  It should be noted that any combination of the above-described constituent elements and the expression of the present invention converted between a method, an apparatus, a system, a computer program, a data structure, a recording medium, and the like are also effective as an aspect of the present invention.

  According to the present invention, it is possible to efficiently decompress a compressed texture.

1 is a configuration diagram of a graphics processing device according to an embodiment. FIG. Fig.2 (a)-FIG.2 (c) are the figures explaining a mipmap texture. It is a figure explaining the mechanism of PRT of this Embodiment. FIG. 4A to FIG. 4E are diagrams for explaining the data amount of texture subjected to run-length compression. Fig.5 (a)-FIG.5 (c) are the figures explaining the run-length compression and expansion | extension of this Embodiment. It is a flowchart explaining the flow of the run length expansion | extension of this Embodiment. It is a figure explaining the execution process of the thread | thread when a branch destination has no bias for a comparison. It is a figure explaining the execution process of the thread | thread when a branch destination has a bias. It is a block diagram of the graphics processing apparatus which concerns on another embodiment. FIG. 10A to FIG. 10F are diagrams for explaining the amount of texture data subjected to Zlib compression. FIG. 11A and FIG. 11B are diagrams for explaining the advantages of run-length compression of textures in the present embodiment. It is a figure explaining the performance of the expansion process of the compression texture by the graphics processing apparatus of this Embodiment.

(First embodiment)
FIG. 1 is a configuration diagram of the graphics processing apparatus according to the first embodiment. The graphics processing device includes a main processor 100, a graphics processing unit (GPU) 200, and a main memory 300.

  The main processor 100 may be a single main processor, a multiprocessor system including a plurality of processors, or a multicore processor in which a plurality of processor cores are integrated in one package. Good. The main processor 100 can read / write data from / to the main memory 300 via the bus.

  The GPU 200 is a graphic chip equipped with a graphic processor core, and can read / write data from / to the main memory 300 via a bus.

  The main processor 100 and the GPU 200 are connected by a bus, and the main processor 100 and the GPU 200 can exchange data with each other via the bus.

  FIG. 2 shows a configuration related to texture processing in the graphics processing, and the configuration related to other processing is omitted.

  The memory area of the main memory 300 is memory-mapped in an address space referred to by the GPU 200 so that the GPU 200 can access the GPU 200, and the GPU 200 can read texture data from the main memory 300. Texture data is partially cached in the main memory 300 using a method called PRT (Partially Resident Textures).

  The main processor 100 includes a graphics calculation unit 20 and a PRT control unit 10. The graphics calculation unit 20 receives an LOD (level of detail) value indicating the level of detail of the texture from the graphics processing unit 50 of the GPU 200 and passes the LOD value to the PRT control unit 10. Based on the LOD value received from the graphics processing unit 50, the PRT control unit 10 calculates a mipmap texture that will be required in the future, instructs the PRT cache 320, which is a texture pool, and uses it. PRT mapping is updated by removing the missing page.

  Fig.2 (a)-FIG.2 (c) are the figures explaining a mipmap texture. The mipmap texture is a plurality of textures having different resolutions according to the level of detail (LOD). The mipmap texture 340 in FIG. 2A is a high-resolution texture. The mipmap texture 342 in FIG. 2B is a medium resolution texture in which the vertical and horizontal sizes of the high resolution mipmap texture 340 in FIG. The mipmap texture 344 in FIG. 2C is a low resolution texture in which the vertical and horizontal sizes of the medium resolution mipmap texture 342 in FIG.

  Returning to FIG. 1, the PRT control unit 10 instructs the GPU 200 to read the mipmap texture of the level of detail specified in the graphics calculation unit 20. More specifically, the PRT control unit 10 controls the run length expansion unit 30 and the inverse discrete cosine transform unit 40 of the GPU 200, and controls swap-in and swap-out of the PRT cache 320 stored in the main memory 300. To do.

  The GPU 200 includes a run-length decompression unit 30, an IDCT unit 40, and a graphics processing unit 50.

  The run-length decompression unit 30 reads the compressed texture 310 corresponding to the level of detail specified by the PRT control unit 10 from the main memory 300, decompresses the compressed texture 310, and stores it in the DCT block ring buffer 80.

  The IDCT unit 40 performs inverse discrete cosine transform on the DCT block of the texture after the run length decompression stored in the DCT block ring buffer 80 and stores the DCT block in the PRT cache 320.

  The graphics processing unit 50 reads a necessary mipmap texture from the PRT cache 320. The PRT cache 320 is a texture tile pool that partially caches textures, swaps in necessary textures, and swaps out unnecessary ones.

  FIG. 3 is a diagram for explaining the mechanism of the PRT according to the present embodiment.

  On the virtual memory, areas of mipmap textures 340, 342, and 344 are arranged. The texture area is divided into chunks of a certain size, and only the necessary texture area is stored in the texture tile pool 360 using the page table 330. Here, since the texture exists in the main memory 300 as the compressed texture 310, when the texture area is cached in the texture tile pool 360, a process for expanding the compressed texture 310 is required. The PRT control unit 10 controls the run length expansion unit 30 and the IDCT unit 40 in accordance with a request from the graphics processing unit 50, and expands the compressed texture 310 as necessary.

  In the example shown in the figure, the chunk 352 of the high resolution mipmap texture 340 and the chunk 358 of the medium resolution mipmap texture 342 are associated with the pages 332 and 338 of the page table 330, respectively, and the physical memory is a texture tile. Mapped from pool 360.

  On the other hand, the chunk 354 of the high-resolution mipmap texture 340 and the chunk 356 of the medium-resolution mipmap texture 342 are associated with the pages 334 and 336 of the page table 330, respectively. Not mapped from pool 360. In this case, as described above, the PRT control unit 10 controls the texture tile pool 360 so that the necessary texture is in the texture tile pool 360 based on the LOD value received from the graphics processing unit 50, and the physical memory of the texture tile pool 360 is The necessary texture data is expanded from the compressed texture 310 and stored in the texture tile pool 360. On the other hand, the graphics processing unit 50 reads the mipmap texture from the texture tile pool 360 using the LOD value calculated by itself without going through the main processor 100. At this time, if the mipmap texture corresponding to the calculated LOD value does not exist in the texture tile pool 360, the graphics processing unit 50 falls back to reduce the requested detail level, Read from the texture tile pool 360 and draw.

  FIG. 4A to FIG. 4E are diagrams for explaining the data amount of texture subjected to run-length compression. As shown in FIG. 4A, it is assumed that the original texture data is in RGB 32-bit format, for example, 16 Mib (Mevibyte). FIG. 4B shows a texture compressed by a texture compression method called BC5 or BC7, which is a compression ratio of about 1/4 compared to the original texture data, and the quality is kept relatively good. Data volume can be reduced to 4MiB. If the quality may be relatively low, a texture compressed by a texture compression method called BC1 or DXT1 may be used as shown in FIG. 4 (c). Compared with the compression rate of about 1/8, the data amount can be reduced to 2 MiB. 4A to 4C are texture formats that can be directly handled by the GPU 200. FIG.

  On the other hand, the GPU 200 cannot directly handle, but if a texture compressed by JPEG as shown in FIG. 4D is used, a compression ratio of about 1/20 is obtained compared to the original texture data, and 0.5 to Data volume can be reduced to 1 MiB. In this case, it is inefficient to execute a complicated algorithm such as JPEG decompression in the compute shader of the GPU 200, and if there is no dedicated hardware capable of performing JPEG decompression, the compressed texture is decompressed in real time. It is difficult to use for processing.

  On the other hand, as shown in FIG. 4E, if discrete cosine transform (DCT) and run length compression are performed, a compression ratio of about 1/10 is obtained, and the data amount is reduced to 1 to 2 MiB. Can be reduced. When high compression is performed up to this point, the compressed texture 310 can be made resident in the main memory 300. The GPU 200 can read the compressed texture 310 from the main memory 300 and restore the texture by executing run-length expansion and inverse discrete cosine transform (IDCT) in real time using a compute shader.

  Since textures compressed with JPEG cannot be directly used by the GPU 200, they need to be decoded once by a JPEG decoder. A graphics device equipped with a JPEG codec can handle JPEG-compressed textures, but generally cannot use a JPEG codec. JPEG compression performs Huffman coding after subjecting an image to discrete cosine transform and quantization. Since Huffman coding is a complicated compression algorithm, if the compute shader of the GPU 200 performs Huffman decoding of a texture that has been JPEG-compressed, the amount of calculation will be enormous.

  In contrast, simple computations such as run-length expansion can be efficiently performed by the GPU 200 compute shader. With reference to FIGS. 5 to 8, it will be described that the compute shader of the GPU 200 can efficiently execute run-length expansion.

  Fig.5 (a)-FIG.5 (c) are the figures explaining the run-length compression and expansion | extension of this Embodiment. 5A shows the original data string, FIG. 5B shows the run-length compressed data string, and FIG. 5C shows the run-length decompressed data string.

  In the run-length compression of this embodiment, compression is performed in units of bytes, and input values other than “00” and “ff” are output as they are in hexadecimal. The input values “3f”, “4d”, “e8”, “02”, “a5”, “01” of the first 6 bytes indicated by reference numeral 410 in FIG. 5A can be “00” or “ff”. However, as shown in FIG. 5B, the 6-byte output values “3f”, “4d”, “e8”, “02”, “a5”, “01” are encoded as they are.

  In the run-length compression according to the present embodiment, when n input values “00” are arranged in succession, they are encoded as 2-byte output values “ff” and “n−1”. For example, when seven “00” s are consecutively arranged as indicated by reference numeral 420 in FIG. 5A, encoding is performed as a 2-byte output value “ff06” as indicated by reference numeral 422 in FIG. 5B. .

  In the run-length compression of the present embodiment, when an actual value “ff” is input, it is converted into “ff00” of 2 bytes to identify the actual value “ff”. The input value “ff” indicated by reference numeral 430 in FIG. 5A is encoded as a 2-byte output value “ff00” as indicated by reference numeral 432 in FIG.

  The run-length expansion of the present embodiment may be performed by performing the inverse conversion of the run-length compression. The input values “3f”, “4d”, “e8”, “02”, “a5”, “01” of the first 6 bytes in FIG. 5B are output as they are as shown in FIG. The For “ff06” indicated by reference numeral 422 in FIG. 5B, the first “ff” is converted into “00” as shown by reference numeral 424 in FIG. Is output. For “ff00” indicated by reference numeral 432 in FIG. 5C, this indicates that it is an actual value “ff”. Therefore, as indicated by reference numeral 434 in FIG. "Ff" is output.

  FIG. 6 is a flowchart for explaining the flow of run-length expansion according to this embodiment.

  The variable RL indicates the number of times (n-1) to repeat the output of “00”. Since RL = 0 as an initial value (No in S10), 1 byte is read from the input data string (S20). ). If the data read in step S20 is not “ff” (Yes in S22), the read data is output as it is (S24), and the process returns to step S10. When the data read in step S20 is “ff” (No in S22), the next 1 byte is further read (S30).

  If the data read in step S30 is “00” (Yes in S32), it means that “ff” read immediately before is an actual value, so “ff” is output. (S34), it returns to step S10.

  If the data read in step S30 is not “00” (No in S32), the read data is substituted into the variable RL (S40). As a result, the number (n−1) of repeating the output of “00” is substituted into RL. Thereafter, the first “00” is output (S42), and the process returns to step S10.

  When returning from step S24 and step S34 to step S10, since variable RL = 0 (No in step S10), the process proceeds to step S20, and the subsequent steps are repeated.

  When returning from step S42 to step S10, since variable RL = n−1 (Yes in step S10), 1 is subtracted from variable RL (S12), “00” is output (S14), and the process returns to step S10. . Steps S12 and S14 are repeated until the variable RL becomes 0, and "00" is output (n-1) times.

  In texture compression according to the present embodiment, discrete cosine transform (DCT) is performed on a block of an image, and then quantized and run-length compressed. When a natural image is subjected to discrete cosine transform, most of the frequency components are concentrated in the low frequency region, and the high frequency components become so small that they can be ignored. In particular, due to quantization, the DCT coefficient of the high frequency component becomes almost zero. For this reason, the run length compression input data often has many zeros.

  Steps S10, S12, and S14 in FIG. 6 are branch A, steps S20, S22, and S24 are branch B, steps S30, S32, and S34 are branch C, and steps S40 and S42 are branch D. Texture data after discrete cosine transform Since many zeros continue in many cases, when run-length extension is performed, the number of passes through branch A is extremely high. In the case of a general natural image texture, it has been experimentally confirmed that about 80% or more passes through the branch A. Due to the nature of the run-length expansion, the compute shader of the GPU 200 can efficiently perform the run-length expansion. This is because the GPU 200 has a SIMD (Single Instruction Multiple Data) architecture, and a plurality of threads execute the same instruction simultaneously on different data, so if the branch condition is biased, the degree of parallelism increases and the execution efficiency increases. .

  In the GPU 200, one program counter (PC) refers to an instruction stored in the instruction cache, and, for example, 16 ALUs (Arithmetic Logic Units) execute instructions referred to by the PC at the same time. Different instructions are set in 16 threads for each branch of the if-then-else loop and executed simultaneously. For 16 threads, if the if condition is satisfied in the if branch (true), the thread responsible for the pixel is enabled and executed in parallel, and if the else condition is satisfied in the else branch (false) Enable the thread responsible for the pixel to run in parallel. When the if condition is satisfied and the else condition is satisfied, the number of threads to be activated is frequently changed in the case of True and False, but if condition is 80%, If the else condition is biased such as 20%, the set of threads to be enabled in the case of True can be used repeatedly, and execution efficiency increases. This point will be described in more detail with reference to FIGS.

  FIG. 7 is a diagram for explaining the thread execution process when there is no bias in the branch destination for comparison.

  The GPU 200 includes a plurality of computing units. The number of threads simultaneously executed by one calculation unit of the GPU 200 is determined by the number of arithmetic units in the calculation unit. A group of up to 16 threads that can be simultaneously input to one computing unit is called a “thread set”. Each thread included in the thread set executes the same shader program, but the data to be processed is different. If there is a branch in the program, each thread may have a different branch destination. One calculation unit executes one thread set (here, a maximum of 16 threads) in parallel in a certain cycle.

  For example, even if the number of instructions required at each branch destination is only a few, the program counter is one, and all the arithmetic units in the calculation unit have a SIMD structure that executes the same instruction. Each instruction of each branch is executed while changing the thread to be executed.

  As an example, assume that branch A in the flowchart of FIG. 6 is executed with 3 instructions, branch B with 4 instructions, branch C with 2 instructions, and branch D with 5 instructions. In the example of FIG. 7, branch destinations of 16 threads in the thread set 450 are A, A, C, A, A, A, C, B, C, A, C, A, C, A, C, The case of D is described.

  In cycle 1, only the thread that executes branch A (in this case, eight threads) is enabled, and the three instructions A-1, A-2, and A-3 of branch A are executed while the program counter is advanced one by one. Run.

  In cycle 3, only the thread that executes branch B (in this case, one thread) is enabled, and the four instructions B-1, B-2, B-3, B-4 is executed.

  In cycle 8, only the thread that executes branch C (in this case, six threads) is enabled, and the two instructions C-1 and C-2 of branch C are executed while the program counter is incremented by one.

  In cycle 10, only the thread that executes branch D (in this case, one thread) is enabled, and while the program counter is incremented one by one, five instructions D-1, D-2, D-3, D-4 and D-5 are executed.

  Thus, in the example of FIG. 7, 14 cycles are required for the 16 threads included in the thread set to execute all the instructions of the four branches A to D.

  FIG. 8 is a diagram illustrating a thread execution process when there is a bias in the branch destination. In the example of FIG. 8, the branch destinations of 16 threads in the thread set 452 are A, A, C, A, A, A, C, C, C, A, C, A, C, A, C, The case of A is described. In this example, there are four types of branch destinations in the shader program, but the pixels satisfying the branch condition are biased, and there are only two types of branch destinations, branch A and branch C. The 16 threads included in the thread set need only execute these two types of branches.

  In cycle 1, only the thread that executes branch A (in this case, nine threads) is enabled, and the three instructions A-1, A-2, and A-3 of branch A are executed while the program counter is advanced one by one. Run.

  In cycle 4, only the thread that executes branch C (in this case, seven threads) is enabled, and the two instructions C-1 and C-2 of branch C are executed while the program counter is advanced one by one.

  In this way, in the example of FIG. 8, the 16 threads included in the thread set only need to execute all the instructions of the two branches A and C, and the necessary number of cycles is reduced to 5.

  If there is a bias in the branch destination of the program due to the nature of the input data, the same thread mask can be used as it is to execute the instruction repeatedly, improving the execution efficiency. If there are variations in the branch destinations, the thread mask is switched for each branch, and the execution efficiency decreases.

  Here is the advantage of run length compression after discrete cosine transform of the texture. Due to the nature of DCT coefficients derived from natural images, values other than 0 are concentrated on the upper left low frequency component of the DCT coefficient matrix, and 0 continues to the lower right high frequency component of the DCT coefficient matrix. Therefore, when an image block after the discrete cosine transform is made into a one-dimensional array by a zigzag pattern, the DCT coefficient of any block tends to be a data string in which a non-zero value continues first and 0 continues in the latter half.

  Based on the tendency of the DCT coefficient, run-length compressed data is assigned to each thread of the thread set so as to process the DCT coefficient of a different DCT block, and each thread has a DCT coefficient at a relatively same position in the DCT block. Configure the thread set to perform run-length expansion. Depending on whether the value of the DCT coefficient is “00”, “ff”, or any other value, the branch destination is one of the branches A to D. From the configuration of the thread set, the tendency of the DCT coefficient is similar at the relatively same position in the DCT block, so that the branch destination of each thread in the thread set is biased to the same. Accordingly, the branch destinations do not vary as shown in FIG. 7, but the branch destinations become biased as shown in FIG. 8, and the efficient execution state of the thread set can be continued for a long time. As a result, run-length expansion is efficiently performed by the thread set.

  According to the graphics processing apparatus of the present embodiment, the texture capacity that has been run-length compressed after discrete cosine transform is used, so that the texture capacity can be greatly reduced. Since the compute shader of the GPU 200 performs run-length expansion of the compressed texture and inverse discrete cosine transform, the compressed texture can be expanded at high speed and input to the graphics processing. Since the highly compressed texture can be resident in the memory, it is not necessary to read out a large-capacity texture from a storage device such as a hard disk, and the PRT can be executed on-memory. Since the compressed texture is on-memory, the latency is short and texture processing can be executed in real time even if the compressed texture is read out as needed, decompressed, and swapped into the PRT cache.

(Second Embodiment)
FIG. 9 is a configuration diagram of the graphics processing apparatus according to the second embodiment. The graphics processing apparatus according to the second embodiment is different from the first embodiment in that it includes a Zlib engine 60. The description of the configuration common to the first embodiment will be omitted as appropriate, and the configuration different from the first embodiment will be mainly described in detail.

  The Zlib engine 60 is a dedicated circuit that executes Zlib decompression. Zlib is a data compression / decompression library that implements a reversible compression algorithm called Deflate.

  In the present embodiment, as the compressed texture 310, a texture that has been subjected to discrete cosine transform, run-length compressed, and then reversibly compressed by Zlib is used. The compressed texture 310 is stored in the main memory 300.

  The Zlib engine 60 performs Zlib decompression on the compressed texture 310 stored in the main memory 300 and stores it in the run-length blocking ring buffer 70.

  The run-length decompression unit 30 performs run-length decompression on the compressed texture after Zlib decompression stored in the run-length block ring buffer 70 and stores it in the DCT block ring buffer 80. The subsequent processing is the same as in the first embodiment.

  FIG. 10A to FIG. 10F are diagrams for explaining the amount of texture data subjected to Zlib compression. Since the compressed texture that can be handled by the GPU 200 in FIGS. 10A to 10C is the same as that in FIGS. 4A to 4C, the description thereof is omitted.

  FIG. 10D to FIG. 10F are compressed textures that the GPU 200 cannot directly handle. The discrete cosine transform and Zlib compressed texture of FIG. 10 (e) can obtain a compression ratio of approximately 1/20, similar to the JPEG compressed texture of FIG. 10 (d). However, if the DCT coefficient is Zlib-compressed as it is, as will be described later, a load exceeding the normal hardware performance is imposed on the Zlib engine 60 at the time of expansion, resulting in poor efficiency. Therefore, in the present embodiment, as shown in FIG. 10F, a texture that is Zlib compressed after discrete cosine transform and run-length compression is used.

  FIG. 11A and FIG. 11B are diagrams for explaining the advantages of run-length compression of textures in the present embodiment.

  For comparison, FIG. 11A shows a case where a texture that has not been run-length compressed is Zlib decompressed by the Zlib engine 60. When the compression ratio of the compressed texture is 1/20, when the Zlib engine 60 receives a compressed texture input at a transfer rate of 50 MB / s (megabytes / second), the Zlib decompressed texture at a transfer rate of 1333 MB / s Must be output. The Zlib decompressed texture is subjected to inverse discrete cosine transform by the IDCT unit 40, and a texture restored at a transfer rate of 1000 MB / s is output.

  The normal input / output ratio of the Zlib engine 60 is 2 to 4 times. On the other hand, in the case of a texture that is not run-length compressed, an output performance of about 20 times is required. However, since it exceeds the normal hardware limit of the Zlib engine 60, it is not practical to implement it. Absent. If the Zlib engine 60 having the normal output performance is used, the required output performance cannot be obtained, so that the output of the Zlib engine 60 becomes a bottleneck, and the time required for restoring the texture becomes extremely long.

  FIG. 11B shows a case where a Zlib engine 60 decompresses a run-length compressed texture. In this case, when the Zlib engine 60 receives a compressed texture input at a transfer rate of 50 MB / s (megabytes / second), the Zlib decompressed texture may be output at a transfer rate of 125 MB / s. This is because, after that, the run-length expansion unit 30 can perform the run-length expansion on the Zlib-extended texture and output it at a transfer rate of 1333 Mb / s. The texture subjected to the run-length expansion is subjected to inverse discrete cosine transform by the IDCT unit 40, and a texture restored at a transfer rate of 1000 MB / s is output.

  Since both the run length decompression unit 30 and the IDCT unit 40 are executed by the compute shader of the GPU 200, the data transfer bandwidth is sufficiently large, and the data transfer from the run length decompression unit 30 to the IDCT unit 40 is 1333 Mb / s. The transfer speed can be realized. In this case, since the output performance of the Zlib engine 60 is about twice, it can be implemented within the range of normal hardware restrictions.

  FIG. 12 is a diagram for explaining the performance of the compressed texture expansion processing by the graphics processing apparatus according to the present embodiment. As an example, a case will be described in which a compressed texture having a length of 640 pixels and a width of 640 pixels is expanded. Here, the GPU 200 has 18 calculation units (CUs) as an example. Since the Zlib engine 60 is also used for applications other than texture expansion, the compressed texture is Zlib expanded at 26 Mib / s using a part of the resources of the Zlib engine 60 whose output performance is 200 Mib / s. This takes 6.2 ms (milliseconds). After that, run length expansion is performed using one CU, which takes 1.3 ms. Thereafter, the inverse discrete cosine transform is performed using 18 CUs, which takes 0.3 ms. In total, the compressed texture on the main memory 300 is expanded to a latency of 8 ms, and the compressed texture can be expanded and input to the graphics processing in real time.

  If a texture that is not run-length compressed is used, the Zlib engine 60 with normal output performance will take about 10 times 62 ms to Zlib decompress the compressed texture, making it unusable for practical use. By using the run-length compressed texture, the load applied to the Zlib engine 60 can be lightened, and the run-length expansion can be performed at high speed by the compute shader, so that the latency due to the compression processing of the compressed texture can be shortened.

  According to the graphics processing apparatus of the second embodiment, since the texture subjected to the Zlib compression after the discrete cosine transform and the run length compression is used, the texture capacity can be greatly reduced similarly to the JPEG compression. The highly compressed texture can be made resident in the memory, and the PRT can be executed on-memory.

  In a graphics processing apparatus including a Zlib decoder, by using a texture that has been run-length compressed before Zlib compression, it is possible to reduce the load on the Zlib decoder when decompressing the compressed texture.

  Similarly to the first embodiment, the compute shader of the GPU 200 performs run-length expansion of the compressed texture and inverse discrete cosine transform, so that the highly compressed texture is expanded in real time and input to the graphics processing. it can.

  The present invention has been described based on the embodiments. The embodiments are exemplifications, and it will be understood by those skilled in the art that various modifications can be made to combinations of the respective constituent elements and processing processes, and such modifications are within the scope of the present invention. .

  In the above embodiment, the compressed texture is stored in the memory. However, the compressed texture may be stored in a recording medium such as a hard disk or an optical disk. Since the texture is highly compressed, the storage capacity can be suppressed, and the latency in reading from the recording medium can be suppressed to some extent although it does not meet the latency in the case of on-memory.

  In the above embodiment, the discrete cosine transform is used as an example of the spatial frequency transform for transforming the spatial region of the image into the spatial frequency region. However, other spatial frequency transforms such as a discrete Fourier transform may be used.

  In the above embodiment, as an example of run-length compression, when “00” is continuous, encoding is performed with a combination of specific lengths of “ff” and “00”, but run-length compression is Other methods may be used. For example, when values other than “00” are consecutive, encoding may be performed with a length continuous with a specific code.

  In the above embodiment, the case where the Zlib decoder can be used as hardware has been described. However, the present invention can also be applied to a case where a decoder that decompresses data compressed by a compression algorithm other than Zlib is implemented as hardware. Embodiments can be applied.

  10 PRT control unit, 20 graphics operation unit, 30 run length decompression unit, 40 inverse discrete cosine transform unit, 50 graphics processing unit, 60 Zlib engine, 70 run length block ring buffer, 80 DCT block ring buffer, 100 main processor , 200 GPU, 300 main memory, 310 compressed texture, 320 PRT cache, 330 page table, 340 mipmap texture, 360 texture tile pool.

Claims (5)

A graphics processing device including a main memory and a graphics processing unit,
The graphics processing unit includes a run-length decompression unit that performs run-length decompression of a compressed texture, and an inverse spatial frequency transform unit that restores a texture by performing inverse spatial frequency transform on the run-length decompressed texture,
The main memory is seen containing a texture pool partially cache the reconstructed texture,
The run-length decompression unit is executed by a plurality of threads of a compute shader, and each thread performs run-length decompression of spatial frequency transform coefficients at the same position in the spatial frequency transform block of the compressed texture. Graphics processing device. The graphics processing apparatus according to claim 1 , wherein the compressed texture is stored in the main memory, and the run-length expansion unit reads the compressed texture from the main memory. A decompression circuit for decompressing the compressed texture before the run length decompression by the graphics processing unit;
The run-length decompression unit, a graphics processing device according to claim 1 or 2, characterized in that to perform the run length expansion of the texture that is decompressed by the decompression circuit. A graphics processing method in a graphics processing apparatus including a main memory and a graphics processing unit,
In the main memory, the graphics processing unit performs run-length decompression of the compressed texture by a compute shader, restores the texture by performing inverse spatial frequency conversion on the run-length decompressed texture, and partially caches the texture. storing the restored texture in the texture pool,
The run-length expansion is performed by a plurality of threads of a compute shader, and each thread performs the run-length expansion of spatial frequency transform coefficients at the same position in the spatial frequency transform block of the compressed texture. Graphics processing method. Performing run-length decompression of the compressed texture; restoring the texture by inverse spatial frequency transforming the run-length decompressed texture; and storing the restored texture in a texture pool that partially caches the texture; Is executed by the compute shader of the graphics processing unit ,
The run-length expansion is performed by a plurality of threads of a compute shader, and each thread performs the run-length expansion of spatial frequency transform coefficients at the same position in the spatial frequency transform block of the compressed texture. program.

Images