A method for allocating and releasing a unified dyeing graphics processor shared register file

Abstract

This invention relates to a method for allocating and releasing shared register files in a unified coloring graphics processor. The method includes the following steps: 1) dividing the physical memory unit into 8 banks and 128 blocks; 2) establishing a block allocation and release table; 3) integrating the physical memory unit division and the block allocation and release table to achieve the conversion from logical addresses to physical register addresses; 4) allocating and releasing data based on the physical register addresses, using one or more blocks as the scheduling unit. This invention solves the problem of limited coloring kernel size caused by the exclusive use of register files by the coloring kernel, and has the advantage of improving the utilization rate of the unified coloring array registers.

Description

Technical Field

[0001] This invention belongs to the field of unified coloring graphics processor technology, and relates to a strategy for allocating and releasing shared register files, and more particularly to a method for allocating and releasing shared register files in a unified coloring graphics processor. Background Technology

[0002] The unified shading array is the computational core of the unified shading graphics processor, and it occupies a considerable area in the graphics processor layout. Streaming multi-core processors are the core components of the unified shading architecture GPU for performing texture processing, and the shading kernel is the basic shading unit of the unified shading array. The organization of the register file is an important aspect of its design.

[0003] To support the large-scale thread-level parallelism of GPUs, GPUs are equipped with a large number of stream processors (SPs) composed of colored kernels. Stream processors enable GPUs to achieve thread-level parallelism in a single instruction multiple data (SIMD) or single instruction multiple thread (SIMT) manner.

[0004] Registers are the most efficient storage components on a GPU. They are stored in register files. To reduce the cost of context switching, GPUs deploy a large number of register file resources for stream processors. The number of register files varies on each stream multi-core processor of a GPU with different computing power. In a GPU, due to the large number of colored cores and kernel instances, the number of register files and the scale of instances are considerable. Therefore, the management and use of register files are of great significance to GPU performance.

[0005] In a GPU, each colored core in a streaming multi-core processor exclusively uses the RF (Radio Frequency) within its SM (Streaming Controller). A warp is the basic unit of GPU scheduling and execution. Each warp needs to be allocated its own dedicated architecture register file, indexed by a warp ID, and each architecture register has a corresponding physical register allocated in the register file. Once a register is allocated, it is not released until the cooperative thread array to which the warp belongs has completed its execution.

[0006] In other words, even if some threads on a Service Pack (SP) have finished executing, but there are still threads in the Warp that have not finished executing, the register files on all SPs mapped to the Warp cannot be released. While this simplifies register management hardware, it comes at the cost of insufficient register utilization, resulting in a limitation on the size of the colored kernel. Given a fixed GPU area, there is an urgent need to find a method for sharing register files. Summary of the Invention

[0007] To overcome the shortcomings of insufficient utilization of the unified color array registers in traditional graphics processors, this invention provides a novel method for allocating and releasing shared register files in unified color graphics processors.

[0008] The technical solution of this invention is as follows: This invention provides a method for allocating and releasing shared register files in a unified coloring graphics processor, characterized in that the method includes the following steps:

[0009] 1) Divide the physical storage unit into 8 banks and 128 blocks;

[0010] 2) Establish a Block request and release table;

[0011] 3) Integrate the partitioning of physical memory units and the block allocation and release table to realize the conversion from logical address to physical register address;

[0012] 4) Allocate and release blocks based on physical register addresses, using one or more blocks as scheduling units.

[0013] Furthermore, the specific steps of step 1) are as follows:

[0014] 1.1) Using 4KB physical storage units as the scheduling unit, the data width of a single shared register file is 32 bits, and there are a total of 1K register files with a bit width of 32 bits in this scheduling unit;

[0015] 1.2) The physical storage unit is divided into 8 banks, each bank containing 128 physical register files with a width of 32 bits;

[0016] 1.3) Divide the entire storage unit into 128 blocks, with each block consisting of 8 register files, and ensuring that each block exactly covers Bank 0 to Bank 7.

[0017] Furthermore, the specific steps of step 2) are as follows:

[0018] 2.1) The scheduling granularity is set to 32, meaning that each Warp can allocate 1 to 32 Blocks at a time;

[0019] 2.2) Provide a Block allocation and release table for each Warp. Each Warp's allocation and release table contains 32 blocks to store the number of the Block allocated to that Warp and its valid signal. Since each register file needs to support 16 Warp sharing, there are a total of 16 such allocation and release tables.

[0020] 2.3) Organize the block allocation and release tables of the 16 warps into a two-dimensional array;

[0021] Furthermore, the specific steps of step 3) are as follows:

[0022] 3.1) By integrating the partitioning of physical storage units and the Block allocation and release table, the virtual and physical address mapping relationship of the register file can be obtained; the logical address contains a total of 12 bits, of which the high 4 bits are the Warp ID, representing the Warp number corresponding to the logical address, ranging from 0 to 15; the low 3 bits are the Bank ID, representing the Bank number corresponding to the logical address, ranging from 0 to 7; the middle 5 bits are the Block ID, representing the column number (not the actual Block number) stored in the Block allocation and release table corresponding to the logical address, ranging from 0 to 31;

[0023] 3.2) Map the Warp ID and Block ID together in the Block allocation and release table. The combination of the two can obtain a unique block of the Block allocation and release table. The data stored in this block is the Physical Block Number, that is, the actual Block number. Its bit width is 7 bits and the range is 0-127. This value is sent as the offset to the partition table of the physical register.

[0024] 3.3) The Physical Block Number and Bank ID are mapped together in the partition table of physical registers. The combination of the two can yield a unique physical register file number, which is the physical register address.

[0025] Furthermore, in step 4), the usage of each physical register block in the register file is statistically analyzed and its status is marked, a physical register block usage status table is generated, and the register file that has finished using in the current instruction is found, released, reclaimed, and reallocated.

[0026] Furthermore, in step 4), the usage status table, which uses 4 blocks as the scheduling unit, consists of 5 parts: Free Bit, Free List, allocation pointer ap_cnt, release pointer rp_cnt, and indices corresponding to 32 positions. The Free List is a 5-bit, 32-bit register stack used to store the block group number, i.e., the Block ID. Each register in the Free List stores values ​​from 0 to 31. Initially, the data stored in each register in the Free List is the same as its index, i.e., registers 0-31 are initialized sequentially to 0-31. The Free Bit, corresponding to the Free List, is a 32-bit register used to indicate the allocation and reclamation status of each register in the Free List. Each bit corresponds to one register in the Free List. When this bit is 0, it indicates that the current Free List is free and can be allocated and scheduled; when this bit is 1, it indicates that the current Free List has been allocated and cannot be scheduled further. Initially, each bit of the Free Bit is 0. The allocation pointer and release pointer are both 5-bit registers used to store Free Bit values. The list stores the numbers of the currently allocated and released blocks, both ranging from 0 to 31. The release pointer always points to the current write position, i.e., the position of the released and reclaimed block group in the current Free List. The allocation pointer always points to the next read position, i.e., the position of the next block to be allocated. Initially, both pointers point to the 0th block. Furthermore, since both pointers are 5 bits wide, when the allocation or release pointer points to the last Free List (31), the data stored inside is 5'b11111. If further allocation or release of blocks is needed, simply add the corresponding allocation or release quantity to 5'b11111. Due to data overflow, the next pointer bit will start directly from 5'b00000, without needing additional checks or subtractions. If allocation and release pointers are not used, a polling method is needed to find the positions where the Free Bit is 1 and 0 respectively for block allocation and release, and release the used blocks back to their original positions.

[0027] Furthermore, the specific steps of step 4) are as follows:

[0028] 4.1) Using 4 blocks as the scheduling unit, allocation and release instructions are introduced;

[0029] 4.2) First, the number of free blocks in the Free List needs to be calculated and named Free Space, with an initial value of 32. The calculation of the number of free blocks is related to the pointer position. The allocation pointer is named ap_cnt, and the release pointer is named rp_cnt. When the Free List is not fully released or not fully allocated, Free Space is equal to rp_num + 32 - ap_num when the allocation pointer is greater than the release pointer, and equal to rp_num - ap_num when the allocation pointer is less than the release pointer. In addition, the functions of checking if the Free List is full and empty need to be added.

[0030] 4.3) During the allocation process, special allocation instructions are required. The instructions must specify the number of physical registers to be allocated and their corresponding warp, in blocks.

[0031] 4.4) During the Warp release of physical registers, a special allocation instruction is required. The instruction must specify the number of physical registers to be allocated and their corresponding Warp, in blocks.

[0032] Furthermore, the specific steps of step 4.3) are as follows:

[0033] 4.3.1) When an allocation instruction is received, the Warp id and Block Count are first decoded. The Warp id represents the Warp number that needs to be allocated registers, and the Block Count represents the number of Blocks that need to be allocated to the Warp.

[0034] 4.3.2) Compare the number of free blocks (Free Space) with the number of blocks that Warp needs to request (Block Count). If Free Space is greater than Block Count, the allocation is feasible; otherwise, the allocation is not possible.

[0035] 4.3.3) When allocation is feasible, starting from the allocation pointer, send the data from the consecutive Free Lists of Block Count to the Block allocation and release table corresponding to the Warp id for temporary storage. At the same time, add the number of Blocks to be requested to the allocation pointer, i.e., ap_cnt = ap_cnt + Block Count.

[0036] Furthermore, the specific steps of step 4.4) are as follows:

[0037] 4.4.1) The allocation instruction first decodes the Warp id and Block Count. The Warp id represents the Warp number that needs to be released from the register, and the Block Count represents the number of Blocks that need to be released from the Warp.

[0038] 4.4.2) Take the consecutive Block Count data starting from 0 in the Block request and release table corresponding to the Warp id and send it to the consecutive Block Count positions in the Free List starting from the release pointer. At the same time, add the number of released Blocks to the release pointer.

[0039] This invention analyzes traditional GPU register scheduling strategies and, based on domestically produced dedicated GPUs, explores a unified coloring array shared register file design suitable for domestic technology levels. It also proposes a method for allocating and releasing the unified coloring graphics processor shared register file, realizing the conversion from register logical address to physical register address. Without changing the GPU area, it solves the problem of limited coloring kernel size caused by the exclusive use of register files by the coloring kernel, and has the advantage of improving the utilization rate of the unified coloring array register. Attached Figure Description

[0040] Figure 1 A schematic diagram of the physical register partitioning of this invention;

[0041] Figure 2 The present invention provides a two-dimensional array of block request and release tables corresponding to 16 warps;

[0042] Figure 3 The virtual and physical address mapping relationship of the register file in this invention;

[0043] Figure 4 This invention uses a usage status table with 4 blocks as the scheduling unit;

[0044] Figure 5 The mapping relationship between the Block allocation and release table and the Free List under the two methods of this invention;

[0045] Figure 6 The encoding format of the allocation / release instructions of this invention;

[0046] Figure 7 Examples of block request and release in this invention. Detailed Implementation

[0047] This invention uses a 4KB physical storage unit as the scheduling unit, and the individual data width of the shared register file is 32 bits. Therefore, this scheduling unit has 1K register files with a width of 32 bits. Eight banks are set up to share this physical storage unit, so each bank contains 128 physical register files with a width of 32 bits. Register files are allocated and released on a warp-by-warp basis. A single warp can access all eight banks for read and write operations, and each register file supports at least 16 warps sharing. For an existing warp, a set of register files needs to be allocated for operand collection. When all threads in a warp have finished executing, the allocated register files will also be used up, and these register files will be released for other warps to continue scheduling.

[0048] The entire memory unit is divided into 128 blocks, with each block consisting of 8 register files, and each block exactly covering Banks 0 through 7. A block is defined as the smallest scheduling unit for dynamic allocation and reclamation management of register files in this design; that is, Warp scheduling is based on blocks. This ensures that every Bank is covered regardless of how many blocks are scheduled at a time.

[0049] To support Single Instruction Multithreading (SIMT), we tested scheduling granularities of 8, 16, 24, 32, and 40. The results showed that if the scheduling granularity was too small, the scheduling strategy would be very complex, while if the scheduling granularity was too large, it would reduce the parallelism of warp allocation and make it impossible to allocate enough register files for multiple warps at the same time. Ultimately, we determined the scheduling granularity to be 32, meaning that each warp can allocate 1-32 blocks at a time.

[0050] Based on the established scheduling granularity, we provide a Block allocation and release table for each Warp. Each Warp's allocation and release table contains 32 blocks, which are used to store the number of the Block allocated to that Warp and its valid signal. And so on. Since each register file needs to support 16 Warp sharing, there are a total of 16 such allocation and release tables. The Block allocation and release tables of the 16 Warp are organized into a two-dimensional array.

[0051] By integrating the partitioning of physical registers with the Block allocation and release table, the virtual and physical address mapping relationship of the register file can be obtained. The logical address consists of 12 bits: the high 4 bits are the Warp ID, representing the Warp number corresponding to the logical address, ranging from 0 to 15; the low 3 bits are the Bank ID, representing the Bank number corresponding to the logical address, ranging from 0 to 7; and the middle 5 bits are the Block ID, representing the column number (not the actual Block number) stored in the Block allocation and release table corresponding to the logical address, ranging from 0 to 31.

[0052] The Warp ID and Block ID are mapped together in the Block allocation and release table. Combining these two values ​​yields a unique block in the Block allocation and release table. This block stores the Physical Block Number, i.e., the actual Block number, which is 7 bits wide and ranges from 0 to 127. This value is used as an offset and sent to the physical register partitioning table. The Physical Block Number and Block ID are also mapped together in the physical register partitioning table. Combining these two values ​​yields a unique physical register file number, which is the physical address. Thus, we have achieved the conversion from logical (virtual) address to physical register address.

[0053] Since each thread bundle can allocate or release 1-32 physical register blocks at a time, scheduling can be performed using a single physical register block or multiple physical register blocks as the scheduling unit. Clearly, both approaches have advantages and disadvantages. Scheduling using a single physical register block avoids memory fragmentation, but the register file allocation and deallocation table becomes very large, consuming significant resources. Scheduling using multiple physical register blocks reduces the size of the register file allocation and deallocation table, but it introduces memory fragmentation, and the larger the scheduling unit, the higher the probability of fragmentation. Considering all the advantages and disadvantages, we choose 4 blocks as the scheduling unit.

[0054] Next, we introduced allocation and deallocation instructions. During the allocation and distribution of register files, the number of free blocks in the Free List must first be calculated and named Free Space, initially set to 32. The calculation of the number of free blocks depends on the pointer positions. The allocation pointer is named ap_cnt, and the deallocation pointer is named rp_cnt. When the Free List is not fully freed or not fully allocated, if the allocation pointer is greater than the deallocation pointer, Free Space equals rp_num + 32 - ap_num; if the allocation pointer is less than the deallocation pointer, Free Space equals rp_num - ap_num. Furthermore, we need to add functionality to check if the Free List is full or empty.

[0055] During the allocation process, dedicated allocation instructions are required. These instructions specify the number of physical registers to be allocated and their corresponding Warp, in blocks. Upon receiving the allocation instruction, Warpid and Block Count are first decoded. Warp id represents the Warp number for which registers need to be allocated, and Block Count represents the number of Blocks to be allocated within that Warp. The number of free blocks (Free Space) is compared with the number of Blocks requested by the current Warp (Block Count). If Free Space is greater than Block Count, the allocation is feasible; otherwise, it is not. When allocation is feasible, starting from the allocation pointer, data from the consecutive Free Lists of Block Count are temporarily moved to the Block allocation and release table corresponding to the Warp id. Simultaneously, the allocation pointer is incremented by the number of Blocks requested, i.e., ap_cnt = ap_cnt + Block Count.

[0056] The process of releasing physical registers in a Warp is similar to that of allocating them. The allocation instruction first decodes the Warp id and BlockCount. The Warp id represents the Warp number whose registers need to be released, and the BlockCount represents the number of Blocks that need to be released in that Warp. The consecutive BlockCount data points starting from 0 in the Block allocation and release table corresponding to the Warp id are moved to consecutive BlockCount positions in the Free List starting from the release pointer. Simultaneously, the release pointer is incremented by the number of Blocks to be released.

[0057] During the allocation and scheduling of physical register files, it's possible that a target register file may be occupied, leading to conflicts. Therefore, after setting up the register file allocation and deallocation table for thread bundles, it's necessary to track the usage of each physical register block in the register file and mark its status. This allows us to know which physical register blocks have been allocated and which are currently free and available for thread bundle allocation. Furthermore, it's necessary to locate register files that have finished using in the current instruction and release, reclaim, and reallocate them. Therefore, a physical register block usage status table is required.

[0058] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0059] In a specific embodiment of the present invention, the physical storage unit size is 4KB, and the single data width of the shared register file is 32 bits. Therefore, this scheduling unit has a total of 1K register files with a bit width of 32 bits. A total of 8 execution units share this scheduling unit. Each register file supports at least 16 warps for sharing, and register files need to be allocated and released in units of warps. That is, each warp can execute 8 threads simultaneously. Therefore, each time a warp is generated, 16 read operand addresses, 8 write operand addresses, and the corresponding write operands are generated simultaneously.

[0060] The physical storage unit is divided into 8 banks. Since the physical storage unit size in this design is 4KB and the width of a single data file in the shared register file is 32 bits, each bank contains 128 physical register files with a width of 32 bits. A single warp can access all 8 banks for read and write operations.

[0061] See Figure 1 This diagram illustrates the physical register allocation for the eight banks in this design, where each small square represents a physical register file. The vertical columns show the physical register information allocated to each bank, from left to right: Bank 0–Bank 7. The horizontal rows are named Blocks, from top to bottom: Block 0–Block 127. As shown, each Block contains eight physical register files, exactly covering Banks 0–Bank 7. Therefore, we define a Block as the smallest scheduling unit for dynamic allocation and reclamation of register files in this design. This ensures that regardless of the number of Blocks scheduled, each bank is always covered.

[0062] To achieve cross-warp physical register file sharing, the architectural register files of each warp need to be separated from the physical register space they occupy. Register files originally exclusive to the colored kernel are dynamically partitioned, and sharing is achieved through virtual-physical register address mapping. In the previous section, we divided the physical memory unit into 8 banks and 128 blocks, defining the block as the smallest scheduling unit for dynamic allocation and reclamation management of register files in this design. To support Single Instruction Multithreading (SIMT), we tested scheduling granularities of 8, 16, 24, 32, and 40. The results showed that if the scheduling granularity was too small, the scheduling strategy would be very complex, while if the granularity was too large, the parallelism during warp allocation would decrease, making it impossible to allocate enough register files to multiple warps simultaneously. Ultimately, we determined the scheduling granularity to be 32, meaning each warp can allocate 1-32 blocks at a time.

[0063] Based on the established scheduling granularity, we provide a Block allocation and release table for each Warp. Each Warp's allocation and release table contains 32 blocks, which are used to store the number of the Block allocated to that Warp and its valid signal. And so on. Since each register file needs to support 16 Warp sharing, there are a total of 16 such allocation and release tables. The Block allocation and release tables of the 16 Warp are organized into a two-dimensional array.

[0064] See Figure 2 The vertical columns represent the block numbers stored in each warp and their corresponding enable signals, from left to right, indicating the block numbers from 0 to 31 stored in each warp. The horizontal rows represent the warp numbers, from top to bottom: warp 0 to warp 15. For dynamic allocation and reclamation management of the register file, a minimum of 1 block and a maximum of 32 blocks are allocated at a time, but the total number of blocks allocated across 16 warps cannot exceed 128.

[0065] Will Figure 1 The partition table of physical registers and Figure 2 By integrating the block allocation and deallocation tables, the virtual and physical address mapping relationship of the register file can be obtained.

[0066] See Figure 3 Logical address such as Figure 3As shown in the upper right corner, it contains 12 bits. The high 4 bits are the Warp ID, representing the Warp number corresponding to the logical address, ranging from 0 to 15, as shown by the horizontal dashed box in the figure. The low 3 bits are the Bank ID, representing the Bank number corresponding to the logical address, ranging from 0 to 7, as shown by the vertical dashed box in the figure. The middle 5 bits are the Block ID, representing the column number (not the actual Block number) stored in the Block allocation and release table corresponding to the logical address, ranging from 0 to 31, as shown by the vertical dashed box in the figure. In the figure, the Warp ID and Block ID are mapped together in the Block allocation and release table. The combination of the two can obtain a unique block of the Block allocation and release table, as shown by the square in the figure. The data stored in this block is the Physical Block Number in the figure, that is, the actual Block number. Its bit width is 7 bits, ranging from 0 to 127. This value is sent as an offset to the partition table of physical registers, as shown by the horizontal dashed line in the figure. The Physical Block Number and Bank ID are mapped together in the partition table of physical registers. The combination of the two can yield a unique physical register file number, as shown in the block in the figure. This number is the physical address. Thus, we have realized the conversion from logical (virtual) address to physical register address. Taking logical address 12'b0010_00010_001 as an example, its high 4 bits are 4'b0010, representing Warp number 2, and its middle 5 bits are 5'b00010, representing column number 2 in the Block allocation and release table. Combining these two bits, we get the block Block_w2_2 in the Block allocation and release table shown in the figure. Assuming that the data stored in this block is 7'b0000010, then the Physical Block Number is 7'b0000010, which means the offset of the physical register partition table is 2. The low 3 bits of the logical address are 3'b001, representing Bank number 1. Combining this with the offset 2, we get the physical address 10'd130, that is, the physical address corresponding to logical address 12'b0010_00010_001 is 10'd130.

[0067] During the allocation and scheduling of physical register files, it's possible that a target register file may be occupied, leading to conflicts. Therefore, after setting up the Warp Block allocation and deallocation table, it's necessary to track the usage of each block in the register file and mark its status to determine which blocks have been allocated and which are currently free and available for Warp allocation. Furthermore, it's necessary to locate register files that have finished using in the current instruction and release, reclaim, and reallocate them. Therefore, a Block usage status table is required.

[0068] Since each warp can allocate or release 1-32 blocks at a time, scheduling can be done using a single block or multiple blocks as the scheduling unit. For example, if 11 blocks need to be allocated, scheduling with a single block would directly allocate 11 blocks and write their corresponding block addresses into the appropriate block allocation and release table. If scheduling with multiple blocks as the scheduling unit, assuming a unit of 4, then 3 groups of 12 blocks need to be allocated, and their corresponding block addresses need to be written into the appropriate block allocation and release table. Clearly, both approaches have advantages and disadvantages. Scheduling with a single block as the scheduling unit has the advantage of avoiding memory fragmentation, but the disadvantage is that the block allocation and release table is very large, consuming significant resources. Scheduling with multiple blocks as the scheduling unit has the advantage of a relatively small block allocation and release table, but the disadvantage is that it generates memory fragmentation, and the larger the scheduling unit, the higher the probability of memory fragmentation. After analysis and testing, we ultimately chose a scheme using 4 blocks as the scheduling unit.

[0069] See Figure 4 This is a usage status table with 4 blocks as the scheduling unit. It consists of 5 parts: Free Bit, Free List, allocation pointer ap_cnt (Allocate Pointer Count), release pointer rp_cnt (Release Pointer Count), and indices corresponding to 32 positions. The Free List is a 5-bit, 32-bit register file used to store block group numbers, i.e., Block IDs. Each register in the Free List stores values ​​from 0 to 31. Initially, the data stored in each register in the Free List is the same as its index, i.e., registers 0-31 are initialized sequentially to 0-31. The Free Bit, corresponding to the Free List, is a 32-bit register used to indicate the allocation and reclamation status of each register in the Free List. Each bit corresponds to one register in the Free List. When this bit is 0, it means the current Free List is free and can be allocated and scheduled; when this bit is 1, it means the current Free List has been allocated and cannot be scheduled further. Initially, every bit of the Free Bit is 0.

[0070] Both the allocation pointer and the release pointer are 5-bit registers used to store the numbers of the currently allocated and released blocks in the Free List. Their storage range is 0-31. The release pointer always points to the current write position, i.e., the position of the released / reclaimed block group in the current Free List. The allocation pointer always points to the next read position, i.e., the next block to be allocated. Initially, both pointers point to the 0th block. Furthermore, since both pointers are 5-bit, when the allocation or release pointer points to the last Free List (31), its internal data is 5'b11111. If further allocation or release of blocks is needed, simply add the corresponding allocation or release amount to 5'b11111. Due to data overflow, the next pointer bit will start directly from 5'b00000, without requiring additional checks or subtraction. If allocation and release pointers are not used, a polling method is needed to find the positions where the Free Bit is 1 and 0 respectively for block allocation and release, and to release the used blocks back to their original positions. If this method is used, the process of allocating blocks for the first few warps is relatively simple. However, since different warps have different execution times, the order in which warps release blocks is not necessarily the order in which they were allocated. It is possible that the warps allocated later will finish executing and release blocks first. Therefore, under this scheme, after several rounds of allocation and recycling, the free list will be very messy, and each block needs to be polled and searched.

[0071] See Figure 5 ,like Figure 5 The left side shows the mapping relationship between the Block allocation and release table and the Free List after several rounds of allocation and release, without using allocation and release pointers. Figure 5 The right side shows the mapping relationship between Block allocation, release table, and Free List after several rounds of allocation when using allocation and release pointers.

[0072] Next, we introduced allocation and deallocation instructions. In the process of requesting and allocating register files, we first need to calculate the number of free blocks in the Free List and name them free space. The calculation of the number of free blocks is related to the position of the read and write pointers. We name the read pointer rp_cnt and the write pointer wp_cnt. When the register file is not full or not empty, if the read pointer is greater than the write pointer, the free space is equal to rp_cnt - wp_cnt. When the read pointer is less than the write pointer, the free space is equal to rp_num + 32 - ap_num.

[0073] Upon receiving an allocation instruction, the warp id and block count are first decoded. The warp id represents the thread bundle number that needs register allocation, and the block count represents the number of physical register blocks that the thread bundle needs to be allocated. The number of free blocks (free space) is compared with the number of physical register blocks the current thread bundle needs to request (block count). If the free space is greater than the block count, the allocation is feasible; otherwise, it cannot be allocated. When allocation is feasible, starting from the read pointer, the data in the block count consecutive Free Lists is temporarily stored in the register file allocation and release table corresponding to the warp id. At the same time, the read pointer is incremented by the number of physical register blocks requested, i.e., rp_cnt = rp_cnt + block count.

[0074] During the allocation process, a dedicated allocation instruction is required. This instruction must specify the number of physical registers to be allocated and their corresponding thread bundles, in blocks. The instruction format is: Reg Allocate: opcode_allocate, allocation_wrap_id, allocation_block_count. Here, Reg Allocate represents the physical register allocation instruction; opcode_allocate is 1 bit wide and indicates the validity of the allocation instruction. When opcode_allocate is 1, it indicates that the current allocation instruction is valid and decoding can begin; allocation_wrap_id, or warp id, represents the thread bundle number that needs to allocate physical registers; and allocation_block_count, or block count, represents the number of physical register blocks that the current thread bundle needs to request. The encoding format of the allocation instruction is as follows: Figure 6 As shown.

[0075] The process of releasing physical registers for a thread bundle is similar to that of allocation. When an allocation instruction is received, the warp id and block count are first decoded. The warp id represents the thread bundle number whose registers need to be released, and the block count represents the number of physical register blocks that need to be released for that thread bundle. During the release operation, the consecutive block counts of data starting from 0 in the register file allocation and release table corresponding to the warp id are moved to consecutive block counts of positions in the Free List starting from the write pointer. At the same time, the read / write pointer is incremented by the number of physical register blocks to be released, i.e., wp_cnt = wp_cnt + block count.

[0076] The release process also uses a dedicated release instruction. The instruction must specify the number of physical registers to be released and their corresponding thread bundles, in blocks. Instruction format: Reg Release: opcode_release, release_wrap_id, release_block_count. Here, Reg Release represents the physical register release instruction; release_wrap_id, or warp id, indicates which thread bundle the physical registers to be released come from; release_block_count, or block count, indicates the number of physical register blocks to be released from the previous thread bundle. The encoding format of the release instruction is also as follows... Figure 6 As shown.

[0077] To improve register file utilization, we are not limited to the original thread bundle order when releasing register files, but can release them out of order.

[0078] See Figure 7 Because thread bundles don't necessarily complete their register allocations in the order they were requested—for example, warp0 might allocate a register earlier than warp1, but warp1 executes faster and needs to release the register earlier than warp0—warp1 can release it directly without waiting for warp0 to finish. To maintain a continuous number of free blocks in the Free List, regardless of which thread bundle performs the release operation, the physical register block address information is continuously stored in the Free List starting from the write pointer position, rather than being released according to the original allocation position. Registers allocated by completed thread bundles are released from the corresponding register file allocation and release tables, and the values ​​and pointer positions in the Free List are updated promptly so that other thread bundles can continue to allocate these registers.

[0079] Figure 7The first line represents the initial state, with no physical register blocks allocated, all Free Bits set to 0, and WP and RP pointing to position 0. In the second line, warp 0 generates and requests blocks 0-2, allocates these three blocks to warp 0, sets the corresponding Free Bits to 1, RP points to position 3, and WP still points to position 0. In the third line, warp 1 generates and requests blocks 3-6, allocates these three blocks to warp 1, sets the corresponding Free Bits to 1, RP points to position 7, and simultaneously, warp 0 releases blocks 0-2, placing them in positions 0, 1, and 2 of the Free List, setting the corresponding Free Bits to 0, and WP pointing to position 3. In the fourth line, several warps have already requested blocks, but no warp other than warp_0 has released any blocks. Warp_n generates and requests blocks 63-65, allocates these three blocks to warp_n, sets the corresponding Free Bits to 1, RP points to position 66, and simultaneously, warp_m releases blocks 32-65. 33. These two blocks are released to positions 3 and 4 of the Free List, with the corresponding Free Bits set to 0 and WP pointing to position 5. During this process, since the threads in warp m finish execution earlier than the thread bundles generated before them, the Free List is empty at the beginning. Therefore, the two blocks released by warp m are filled into positions 3 and 4 of the Free List in free order, instead of being released and reclaimed according to positions 32 and 33 when they were allocated.

[0080] Regarding the allocation and deallocation of pointers, initially, the allocation pointer always precedes the deallocation pointer. In a sense, the allocation and deallocation pointers are chasing each other, but neither can surpass the other; otherwise, an error will occur. In practical operations, such as... Figure 4 The FreeBit in the Block state table is not used because all Free List blocks after the allocation pointer (excluding the current position of the allocation pointer) and before the release pointer (including the current position of the release pointer) have been allocated, which is equivalent to FreeBit equal to 1; all Free List blocks before the allocation pointer (including the current position of the allocation pointer) and after the release pointer (excluding the current position of the release pointer) are free and can be allocated, which is equivalent to FreeBit equal to 0.

[0081] However, there is a special case: when the allocation pointer and the free pointer point to the same location, it's impossible to directly determine whether the allocation pointer has caught up with the free pointer (i.e., all Free List blocks are empty and all Free List blocks have been allocated) or the free pointer has caught up with the allocation pointer (i.e., all Free List blocks are full and all Free List blocks are free) based on the conditions given in previous sections. These two situations have different effects. When the Free List is completely empty, the system can only receive free commands, not allocation commands, because there are no free Free List blocks to allocate. In this case, a FULL signal needs to be sent to the outside world (this signal is also released when the Free Space is less than the Block Count). When the Free List is completely full, the system can only receive allocation commands, because all Free List blocks are free. Therefore, these two situations need to be clearly distinguished.

[0082] Analysis revealed that when the read and release pointers are equal, the Free List is either empty or full. The only difference lies in whether the release pointer catches up with the allocation pointer or vice versa. So how do we distinguish which catches up? We refer to the method used for asynchronous FIFOs to determine fullness or emptiness, adding one bit before the most significant bit of the data representing the read and release pointers to differentiate between an empty and full Free List. Taking a Free List depth of 32 as an example, the read and release pointer width is 5 bits, and the width of the extended read and release pointers is 6 bits. We name the extended read and release pointers ap_extend and rp_extend, and the extended bits aap_flag and rp_flag. The original read and release pointers before extension remain ap_cnt and rp_cnt.

[0083] Initially, both `ap_extend` and `rp_extend` are 6'b000000, and the Free List is empty. When the allocation pointer increments and passes the last Free List, the highest bit of `ap_extend`, `ap_flag`, is inverted, becoming 6'b100000. At this point, the allocation pointer catches up with the release pointer, the Free List is completely empty, and all Free List blocks have been allocated. Similarly, when the release pointer passes the last Free List, the highest bit of `rp_extend`, `rp_flag`, is also inverted. It can be seen that when the highest bits of `ap_extend` and `rp_extend` are different, but the remaining bits are the same, the Free List is completely empty, and all Free List blocks have been allocated; when the highest bits are equal, and the remaining bits are the same, the Free List is completely full, and all Free List blocks are free.

[0084] When the allocation pointer catches up with the free pointer, it means that all blocks in the Free List have been allocated. At this point, a FULL signal needs to be sent to the outside world to indicate that no new allocation instructions can be sent in. However, when the free pointer catches up with the allocation pointer, it is not necessary to send an EMPTY signal to the outside world. This is because the data that can be written back to the Free List are all those previously allocated from the Free List, with a maximum of 32 entries. When the Free List is full, it means that all the warp pointers that previously allocated registers have already freed the registers, and no new free instructions will be sent in. Therefore, the EMPTY signal is not needed.

[0085] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for allocating and releasing shared register files in a unified coloring graphics processor, characterized in that: The method includes the following steps: 1) Divide the physical storage unit into 8 banks and 128 blocks; 1.1) Using 4KB physical storage units as the scheduling unit, the data width of a single shared register file is 32 bits, and there are a total of 1K register files with a bit width of 32 bits in this scheduling unit; 1.2) The physical storage unit is divided into 8 banks, each bank containing 128 physical register files with a width of 32 bits; 1.3) Divide the entire memory unit into 128 blocks, with each block consisting of 8 register files, and ensuring that each block exactly covers Bank 0 through Bank 7; 2) Establish a Block request and release table; 2.1) The scheduling granularity is set to 32, meaning that each Warp can allocate 1 to 32 Blocks at a time; 2.2) Provide a Block allocation and release table for each Warp. Each Warp's allocation and release table contains 32 blocks to store the number of the Block allocated to that Warp and its valid signal. Since each register file needs to support 16 Warp sharing, there are a total of 16 such allocation and release tables. 2.3) Organize the block allocation and release tables of the 16 warps into a two-dimensional array; 3) Integrate the partitioning of physical memory units and the block allocation and release table to realize the conversion from logical address to physical register address; 3.1) By integrating the partitioning of physical storage units and the Block allocation and release table, the virtual and physical address mapping relationship of the register file can be obtained; the logical address contains a total of 12 bits, of which the high 4 bits are the Warp ID, representing the Warp number corresponding to the logical address, ranging from 0 to 15; the low 3 bits are the Bank ID, representing the Bank number corresponding to the logical address, ranging from 0 to 7; the middle 5 bits are the Block ID, representing the column number stored in the Block allocation and release table corresponding to the logical address, ranging from 0 to 31; 3.2) Map the Warp ID and Block ID together in the Block allocation and release table. The combination of the two can obtain a unique block of the Block allocation and release table. The data stored in this block is the Physical Block Number, that is, the actual Block number. Its bit width is 7 bits and the range is 0-127. This value is used as the offset and sent to the partition table of the physical register. 3.3) The Physical Block Number and Bank ID are mapped together in the physical register partition table. The combination of the two can yield a unique physical register file number, which is the physical register address. 4) Allocate and release blocks based on physical register addresses, using single or multiple blocks as the scheduling unit. In step 4), the usage of each physical register block in the register file is statistically analyzed and its status is marked, a physical register block usage status table is generated, and the register file that has finished using in the current instruction is found, released, reclaimed, and reallocated. In step 4), the scheduling unit is 4 blocks. The usage status table for these 4 blocks consists of 5 parts: Free Bit, Free List, allocation pointer ap_cnt, release pointer rp_cnt, and indices corresponding to 32 positions. The Free List is a 5-bit, 32-bit register file used to store the block group number, i.e., Blockid. Each register in the Free List stores data ranging from 0 to 31. Initially, the data stored in each register in the Free List is the same as its index, i.e., registers 0 to 31 are initialized sequentially to 0 to 31. The Free Bit, corresponding to the Free List, is a 32-bit register used to indicate the allocation and reclamation status of each register in the Free List. Each bit corresponds to one register in the Free List. When this bit is 0, it means that the current Free List is free and can be allocated and scheduled. When this bit is 1, it means that the current Free List has been allocated and cannot be scheduled further. Initially, each bit of the Free Bit is 0. The allocation pointer and release pointer are both 5-bit registers used to store Free Bit data. The list stores the numbers of currently allocated and released blocks, both ranging from 0 to 31. The release pointer always points to the current write position, i.e., the position of the released and reclaimed block group in the current Free List. The allocation pointer always points to the next read position, i.e., the position of the next block to be allocated. Initially, both pointers point to the 0th block. Furthermore, since both pointers are 5 bits wide, when the allocation or release pointer points to the last Free List (31), the data stored inside is 5'b11111. If further allocation or release of blocks is needed, simply add the corresponding allocation or release quantity to 5'b11111. Due to data overflow, the next pointer bit will start directly from 5'b00000, without needing additional checks or subtractions. If allocation and release pointers are not used, a polling method is needed to find the positions where the Free Bit is 1 and 0 respectively for block allocation and release, and release the used blocks back to their original positions.

2. The method for allocating and releasing shared register files for a unified coloring graphics processor according to claim 1, characterized in that: The specific steps of step 4) are as follows: 4.1) Using 4 blocks as the scheduling unit, allocation and release instructions are introduced; 4.2) First, the number of free blocks in the Free List needs to be calculated and named Free Space, with an initial value of 32. The calculation of the number of free blocks is related to the pointer position. The allocation pointer is named ap_cnt, and the release pointer is named rp_cnt. When the Free List is not fully released or not fully allocated, if the allocation pointer is greater than the release pointer, the Free Space is equal to rp_num + 32 - ap_num. If the allocation pointer is less than the release pointer, the Free Space is equal to rp_num - ap_num. In addition, the functions of checking if the Free List is full and empty need to be added. 4.3) During the allocation process, special allocation instructions are required. The instructions must specify the number of physical registers to be allocated and their corresponding warp, in blocks. 4.4) During the Warp release of physical registers, a special allocation instruction is required. The instruction must specify the number of physical registers to be allocated and their corresponding Warp, in blocks.

3. The method for allocating and releasing shared register files for a unified coloring graphics processor according to claim 2, characterized in that: The specific steps of step 4.3) are as follows: 4.3.1) When an allocation instruction is received, the Warp id and Block Count are first decoded. The Warp id represents the Warp number that needs to be allocated registers, and the Block Count represents the number of Blocks that need to be allocated to the Warp. 4.3.2) Compare the number of free blocks (Free Space) with the number of blocks that Warp needs to request (Block Count). If Free Space is greater than Block Count, the allocation is feasible; otherwise, the allocation is not possible. 4.3.3) When allocation is feasible, starting from the allocation pointer, send the data from the consecutive Free Lists of Block Count to the Block allocation and release table corresponding to the Warp ID for temporary storage. At the same time, add the number of Blocks to be requested to the allocation pointer, i.e., ap_cnt = ap_cnt + Block Count.

4. The method for allocating and releasing shared register files for a unified coloring graphics processor according to claim 3, characterized in that: The specific steps of step 4.4) are as follows: 4.4.1) The allocation instruction first decodes the Warp id and Block Count. The Warp id represents the Warp number that needs to be released from the register, and the Block Count represents the number of Blocks that need to be released from the Warp. 4.4.2) Take the consecutive Block Count data starting from 0 in the Block request and release table corresponding to the Warp id and send it to the consecutive Block Count positions in the Free List starting from the release pointer. At the same time, add the number of released Blocks to the release pointer.

Images