Resource allocation method, resource allocation device, electronic equipment and medium

Abstract

The invention provides a resource allocation method, a resource allocation device, electronic equipment and a medium, and the method comprises the steps: determining whether the number of available memory logic sub-blocks in a shared memory meets the demand of a work group task or not according to the demand number of shared memory resources; under the condition that the number of available memory logic sub-blocks in the shared memory meets the requirements of the working group tasks, the corresponding memory logic sub-blocks are allocated to the working group tasks, and for each thread bundle task in the working group tasks, the corresponding thread bundle task is allocated to the corresponding thread bundle task based on the required number of universal register resources of the corresponding thread bundle task. Determining whether the number of available register logic sub-blocks in one execution unit in the plurality of execution units meets the requirement of a corresponding thread bundle task; and under the condition that the number of the available register logic sub-blocks in one execution unit in the plurality of execution units meets the requirement of the corresponding thread beam task, allocating the corresponding register logic sub-blocks in the execution unit to the corresponding thread beam task. The problem of storage space fragmentation is solved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a resource allocation method, resource allocation device, electronic device, and medium. Background Technology

[0002] A GPU (Graphics Processing Unit), also known as a display core, visual processor, or display chip, is a microprocessor used for image processing and image-related computations in computing devices such as personal computers, tablets, and smartphones. A GPU can act as a coprocessor; when it receives kernel instructions from the CPU (central processing unit), it creates numerous threads to execute those instructions. In a typical GPU architecture, the Compute Unit (CU, also known as a multi-stream processor (SM)) is the basic hardware unit for executing workgroup tasks. Each CU contains multiple Execution Units (EUs, also known as stream processors (SPs)) and shared memory (SMEM). Each EU can independently execute thread-based tasks and manage limited storage resources, such as the General Purpose Register (GPR).

[0003] However, in high-concurrency, multi-task execution scenarios, existing GPU storage resource allocation mechanisms primarily rely on compiler static analysis and hardware static configuration, allocating resources sequentially based on estimated resource requirements during kernel instruction execution. This sequential resource allocation approach easily leads to low storage resource utilization and storage fragmentation when faced with mixed kernels of varying sizes and resource requirements. Summary of the Invention

[0004] This disclosure provides a resource allocation method, resource allocation device, electronic device, and medium, aiming to solve the problem of storage space fragmentation caused by the allocation of contiguous storage resources in existing GPU architectures, thereby improving the resource utilization and overall throughput of GPUs in multi-task concurrent scenarios.

[0005] According to one aspect of this disclosure, a resource allocation method for a computing unit of a graphics processor is provided, the computing unit comprising: a plurality of execution units and shared memory, the execution units comprising general-purpose registers, the general-purpose registers comprising a plurality of register logical sub-blocks, the shared memory comprising a plurality of memory logical sub-blocks, the resource allocation method comprising:

[0006] Obtain the storage requirement information of the workgroup task to be executed, wherein the storage requirement information includes the amount of shared memory resources required by the workgroup task and the amount of general-purpose register resources required by multiple thread bundle tasks in the workgroup task;

[0007] Based on the required amount of shared memory resources, determine whether the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task;

[0008] If the number of available memory logical sub-blocks in the shared memory meets the needs of the workgroup task, then allocate corresponding memory logical sub-blocks to the workgroup task, and

[0009] For each thread bundle task in the workgroup task, based on the number of general register resources required by the corresponding thread bundle task, determine whether there is an execution unit among the multiple execution units whose number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task;

[0010] If, among the plurality of execution units, there exists an execution unit whose number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task, then the corresponding register logic sub-block in that execution unit is allocated to the corresponding thread bundle task.

[0011] Optionally, the computing unit further includes a first counting register and a first mapping table. The first counting register is used to record the number of available memory logical sub-blocks in the shared memory. The first mapping table is set to correspond to the workgroup task. The first mapping table includes the mapping relationship between the virtual shared memory slot number to be used by the workgroup task and the slot number of the allocated memory logical sub-block.

[0012] Optionally, the general-purpose registers include scalar general-purpose registers, and the computing unit further includes multiple second mapping tables and multiple second counting registers. The multiple second mapping tables are configured to correspond to multiple thread bundle tasks in the workgroup task, and the multiple second counting registers are configured to correspond to the multiple execution units. The second mapping table includes a mapping relationship between the virtual scalar general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated scalar general-purpose register logical sub-block. The second counting register is used to record the number of scalar general-purpose register logical sub-blocks available in the corresponding execution unit.

[0013] Optionally, the general-purpose register further includes a vector general-purpose register, and the computing unit further includes multiple third mapping tables and multiple third counting registers. The multiple third mapping tables are set to correspond to multiple thread bundle tasks in the workgroup task, and the multiple third counting registers are set to correspond to the multiple execution units. The third mapping table includes a mapping relationship between the virtual vector general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated vector general-purpose register logical sub-block. The third counting register is used to record the number of available vector general-purpose register logical sub-blocks in the corresponding execution unit.

[0014] Optionally, determining whether the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task based on the required amount of shared memory resources includes:

[0015] The number of shared memory resource requirements is compared with the value of the first counter register. If the number of shared memory resource requirements is less than or equal to the value of the first counter register, it is determined that the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task.

[0016] If the required amount of shared memory resources is greater than the value of the first counter register, it is determined that the number of available memory logical sub-blocks in the shared memory does not meet the requirements of the workgroup task, and resource allocation for the workgroup task is suspended.

[0017] Optionally, if the number of available memory logical sub-blocks in the shared memory meets the needs of the workgroup task, allocating corresponding memory logical sub-blocks to the workgroup task includes:

[0018] Allocate corresponding memory logic sub-blocks for the tasks in the workgroup;

[0019] The first mapping table records the mapping relationship between the virtual shared memory slot number to be used by the workgroup task and the slot number of the allocated memory logical sub-block;

[0020] Subtract the required amount of shared memory resources from the value of the first counter register.

[0021] Optionally, determining whether there exists an execution unit among the plurality of execution units that has an available number of register logic sub-blocks that meet the requirements of the corresponding thread bundle task, based on the general register resource requirements of the corresponding thread bundle task, for each thread bundle task in the workgroup task, includes:

[0022] For each thread bundle task, the number of scalar general-purpose register resource requirements of the corresponding thread bundle task is compared with the value of the corresponding second counter register of the corresponding execution unit, and the number of vector general-purpose register resource requirements of the corresponding thread bundle task is compared with the value of the corresponding third counter register of the corresponding execution unit.

[0023] If the number of scalar general-purpose register resources required for the corresponding thread bundle task is less than or equal to the value of the second counter register corresponding to the selected execution unit, and the number of vector general-purpose register resources required for the corresponding thread bundle task is less than or equal to the value of the third counter register corresponding to the selected execution unit, then it is determined that the number of available register logic sub-blocks in the execution unit meets the requirements of the thread bundle task.

[0024] If the scalar general-purpose register resource requirement of the corresponding thread bundle task is greater than the value of the second counter register corresponding to the selected execution unit, and / or the vector general-purpose register resource requirement of the corresponding thread bundle task is greater than the value of the third counter register corresponding to the selected execution unit, then it is determined that the number of available register logic sub-blocks in the execution unit does not meet the requirements of the thread bundle task. The next execution unit is selected by polling, and it is determined whether the number of available register logic sub-blocks in the next execution unit meets the requirements of the thread bundle task.

[0025] If none of the multiple execution units can meet the requirements of the thread bundle task, then the resource allocation for the thread bundle task is suspended.

[0026] Optionally, when there is an execution unit among the plurality of execution units whose number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task, allocating the corresponding register logic sub-block in the execution unit to the corresponding thread bundle task includes:

[0027] Allocate corresponding scalar general-purpose register logic sub-blocks and / or vector general-purpose register logic sub-blocks to the corresponding thread bundle tasks;

[0028] The second mapping table records the mapping relationship between the virtual scalar general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated scalar general-purpose register logical sub-block, and / or

[0029] The mapping relationship between the virtual vector general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated vector general-purpose register logical sub-block is recorded in the corresponding third mapping table.

[0030] Subtract the scalar general-purpose register resource requirement from the value of the corresponding second counter register, and / or

[0031] Subtract the number of vector general-purpose register resources required from the value of the corresponding third counter register.

[0032] Optionally, after allocating the corresponding register logic sub-blocks in the execution unit to the corresponding thread bundle task when the number of available register logic sub-blocks in one of the plurality of execution units meets the requirements of the corresponding thread bundle task, the resource allocation method further includes:

[0033] For each thread bundle task in the workgroup task, after the corresponding thread bundle task is completed, release the scalar general-purpose register logic sub-block and / or vector general-purpose register logic sub-block occupied by it.

[0034] Remove the mapping relationship between the virtual scalar general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated scalar general-purpose register logical sub-block in the corresponding second mapping table, and / or

[0035] Remove the mapping relationship between the virtual vector general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated vector general-purpose register logical sub-block in the corresponding third mapping table.

[0036] Add the value of the corresponding second counter register to the scalar general-purpose register resource requirement, and / or

[0037] Add the value of the corresponding third counter register to the number of vector general-purpose register resources required.

[0038] Optionally, after allocating the corresponding register logic sub-blocks in the execution unit to the corresponding thread bundle task when the number of available register logic sub-blocks in one of the plurality of execution units meets the requirements of the corresponding thread bundle task, the resource allocation method further includes:

[0039] After the workgroup task is completed, the memory logical sub-block it occupies is released;

[0040] Remove the mapping relationship between the virtual shared memory slot number to be used by the workgroup task and the slot number of the allocated memory logical sub-block in the first mapping table;

[0041] Add the value of the first counter register to the number of shared memory resources required.

[0042] Optionally, the shared memory includes memory cells arranged in an array, the physical storage addresses of the memory cells are continuous in the row direction and connected end to end in the row direction, the memory cells are divided into multiple storage banks in the column direction, and the memory logical sub-block includes multiple consecutive rows of memory cells located in the multiple storage banks.

[0043] Optionally, the general-purpose register includes register cells arranged in an array, the physical storage addresses of the register cells are continuous in the row direction and are connected end to end in the row direction, the register cells are divided into multiple memory banks in the column direction, and the register logic sub-block includes multiple consecutive rows of register cells located in the multiple memory banks.

[0044] According to one aspect of this disclosure, a resource allocation device for a computing unit of a graphics processor is provided, the computing unit comprising: a plurality of execution units and shared memory, the execution units including general-purpose registers, the general-purpose registers including a plurality of register logic sub-blocks, the shared memory including a plurality of memory logic sub-blocks, the resource allocation device being integrated in the computing unit, the resource allocation device comprising:

[0045] The storage requirement information acquisition unit is used to acquire the storage requirement information of the workgroup task to be executed. The storage requirement information includes the number of shared memory resources required by the workgroup task and the number of general-purpose register resources required by multiple thread bundle tasks in the workgroup task.

[0046] The available memory determination unit is used to determine whether the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task based on the quantity of shared memory resource demand.

[0047] A memory allocation unit is configured to allocate corresponding memory logical sub-blocks to the workgroup task, provided that the number of available memory logical sub-blocks in the shared memory meets the needs of the workgroup task.

[0048] The available register determination unit is used to determine, for each thread bundle task in the workgroup task, whether there is an execution unit among the multiple execution units whose number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task, based on the number of general register resource requirements of the corresponding thread bundle task.

[0049] The register allocation unit is used to allocate the corresponding register logic sub-block in the execution unit to the corresponding thread bundle task when there is an execution unit in which the number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task.

[0050] According to one aspect of this disclosure, an electronic device is provided, the electronic device including a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for implementing connection communication between the processor and the memory, wherein the program is executed by the processor to implement the resource allocation method as described in any of the preceding claims.

[0051] According to one aspect of this disclosure, a computer-readable storage medium is provided that stores one or more programs, which can be executed by one or more processors to implement the resource allocation method as described in any of the preceding claims.

[0052] In the resource allocation method proposed in this embodiment, based on the shared memory resource requirements of the workgroup tasks to be executed, it is determined whether the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup tasks. If the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup tasks, corresponding memory logical sub-blocks are allocated to the workgroup tasks. Furthermore, for each thread bundle task in the workgroup tasks, based on the general register resource requirements of the corresponding thread bundle task, it is determined whether there is an execution unit among the multiple execution units whose number of available register logical sub-blocks meets the requirements of the corresponding thread bundle task. If there is an execution unit among the multiple execution units, the number of available register logical sub-blocks in the execution unit meets the requirements of the corresponding thread bundle task. When the number of register logic sub-blocks meets the requirements of the corresponding thread bundle task, the corresponding register logic sub-block in the execution unit is allocated to the corresponding thread bundle task. This enables decoupled, non-contiguous dynamic allocation of shared memory and general-purpose register resources in the computing unit. Since each memory logic sub-block and register logic sub-block can be allocated and reclaimed independently, physical address contiguity is no longer required. Therefore, even in high-concurrency multi-task scenarios with frequent resource allocation and release, the scattered idle resource blocks can still be fully utilized, significantly improving the overall utilization rate of hardware storage resources. This effectively avoids the utilization rate decline problem caused by fragmentation after resource release under the traditional static contiguous allocation mechanism. At the same time, by first determining whether the shared memory resources meet the requirements and then allocating thread bundles to appropriate execution units one by one, the orderly and scalable nature of the resource allocation process is ensured, preventing the entire workgroup task from failing to start due to a resource bottleneck.

[0053] Furthermore, by logically dividing the physical storage resources of general-purpose registers and shared memory into multiple logical sub-blocks and introducing a dynamic management mechanism combining mapping tables and counting registers, fine-grained, non-contiguous allocation of critical storage resources in computing units is achieved, thus overcoming the limitation of resource allocation based on contiguous address spaces in traditional GPU architectures. This mechanism allows the system to flexibly select available memory or register logical sub-blocks from different physical locations for allocation based on the actual distribution of idle resources, without waiting for the release of large contiguous spaces, significantly reducing task scheduling latency caused by storage resource fragmentation. Simultaneously, by establishing an independent mapping relationship between virtual address slots and physical address slots of logical sub-blocks for each workgroup task or thread bundle task, the program logic can still access resources in a contiguous address space manner, shielding the complexity of underlying non-contiguous allocation and maintaining the transparency and compatibility of the programming model.

[0054] Furthermore, shared memory is organized as an array of memory cells, with their physical storage addresses contiguously arranged row-wise and divided into multiple memory banks along the column direction to support parallel access and high-bandwidth data throughput. Each logical sub-block of memory consists of several consecutive rows spanning multiple memory banks, ensuring access locality while avoiding access conflicts within a single memory bank. Similarly, general-purpose registers are organized using the same array structure, with register cells addressed contiguously in the row direction and divided into multiple memory banks along the column direction. Register logical sub-blocks consist of multiple consecutive rows of register cells located within multiple memory banks. This structural design not only facilitates the division of physical resources into fixed-size logical sub-blocks but also provides a unified hardware support foundation for subsequent resource scheduling, address decoding, and conflict detection, enhancing the implementability and scalability of resource management mechanisms.

[0055] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0056] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0057] Figure 1A This is a schematic diagram illustrating the continuous storage resource usage according to one embodiment of the related art;

[0058] Figure 1B yes Figure 1A A diagram illustrating the allocation of storage resources to a thread bundle under conditions of continuous storage resource occupancy;

[0059] Figure 2A This is a schematic diagram illustrating the continuous storage resource usage according to yet another embodiment of the related art;

[0060] Figure 2B yes Figure 2A A diagram illustrating the allocation of storage resources to a thread bundle under conditions of continuous storage resource occupancy;

[0061] Figure 3 This is a system architecture diagram of the resource allocation method applied in the embodiments of this disclosure;

[0062] Figure 4 This is a schematic diagram of the structure of a computing unit according to an embodiment of the present disclosure;

[0063] Figure 5A This is a schematic diagram of shared memory according to an embodiment of the present disclosure;

[0064] Figure 5B This is a schematic diagram of a scalar general-purpose register according to an embodiment of the present disclosure;

[0065] Figure 5C This is a schematic diagram of a vector general-purpose register according to an embodiment of the present disclosure;

[0066] Figure 6 This is a main flowchart of a resource allocation method according to an embodiment of the present disclosure;

[0067] Figure 7A This is a schematic diagram of a first mapping table for shared memory according to an embodiment of the present disclosure;

[0068] Figure 7B This is a schematic diagram of a second mapping table for a scalar general-purpose register according to an embodiment of the present disclosure;

[0069] Figure 7C This is a schematic diagram of a third mapping table for a vector general-purpose register according to an embodiment of the present disclosure;

[0070] Figure 7D This is a schematic diagram of the slots for allocating logical sub-blocks of memory according to an embodiment of the present disclosure;

[0071] Figure 7E This is a schematic diagram of the slots allocated to a scalar general-purpose register logic subblock according to an embodiment of the present disclosure;

[0072] Figure 7F This is a schematic diagram of the slots of an allocation vector general-purpose register logic subblock according to an embodiment of the present disclosure;

[0073] Figure 8 yes Figure 2A A schematic diagram illustrating the allocation of storage resources for a thread bundle according to an embodiment of this disclosure under the condition of continuous storage resource occupancy;

[0074] Figure 9 This is a schematic diagram of the structure of a resource allocation device according to an embodiment of the present disclosure;

[0075] Figure 10 This is an architecture diagram of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0076] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0077] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0078] A thread is the smallest unit of execution in a graphics processing unit (GPU) when performing data processing tasks. Each thread can independently perform the same pattern of processing on different data.

[0079] A warp is the basic unit of scheduling and execution in a graphics processing unit (GPU). It contains a fixed number of threads, typically 32 or 64. All threads execute the same instructions within the same clock cycle, but can operate on different data, enabling Single Instruction Multiple Data (SIMD) parallel computation. When a grid is started (grid startup is equivalent to kernel startup, with each kernel corresponding to its own grid), the grid contains workgroups. After a workgroup is assigned to a computing unit, it is divided into multiple warps. Within a warp, all threads execute in a single-instruction multiple-threaded manner, executing the same instructions at each step, but processing private data, meaning the data corresponds to a specific thread.

[0080] Work Group: A group of threads consisting of multiple threads, also known as a thread block. Threads in a single work group are generally used to perform the same pattern of processing on different data.

[0081] A grid consists of multiple workgroups. Each workgroup is a grid point in the grid, and each workgroup has corresponding grid point coordinates. A grid can be one-dimensional, two-dimensional, or three-dimensional. The shape of the grid is defined by the user during the programming process.

[0082] A Compute Unit (CU) is a processing module in electronic devices such as a Graphics Processing Unit (GPU). In some architectures, a CU may also be called a Stream Multiprocessor (SM). A GPU can include multiple CUs. A CU can be considered a processing core within a GPU. Each CU can execute instructions independently, and the GPU can process data in parallel through multiple CUs.

[0083] Execution Unit (EU): The execution unit in a microprocessor is responsible for executing instructions and performing computational tasks such as arithmetic operations, logical operations, and shift operations. In fact, it has the functions of both a controller and an arithmetic unit.

[0084] Shared memory (SMEM) refers to a certain amount of memory in a multiprocessor computer system that can be accessed by different processors. Because multiple processors need to access memory quickly, memory caching is necessary. When any cached data is updated, the shared memory needs to be updated immediately, otherwise different processors might use different data.

[0085] General Purpose Registers (GPRs) are used to store thread-private data, such as address indices, loop variables, or temporary calculation results. Each thread has its own independent GPR space, which is accessed extremely quickly and is a key resource for achieving thread-level parallel computing. In the Single Instruction Multithreaded (SIMT) execution model, GPRs and SMEMs work together: GPRs store thread-private states, while SMEMs carry shared data between thread bundles. Together, they support the efficient execution of high-concurrency computing tasks.

[0086] Scalar General Purpose Registers (SGPR): Used to store scalar data, such as control flow variables, loop counters, and address offsets. Vector General Purpose Registers (VGPR): Used to store vector data, such as operands for floating-point or integer vector operations.

[0087] In high-concurrency, multi-task execution scenarios, existing GPU storage resource allocation mechanisms primarily rely on compiler static analysis and hardware static configuration, allocating resources sequentially based on estimated resource requirements during kernel instruction execution. This sequential resource allocation approach is prone to low storage resource utilization and storage fragmentation when faced with a mix of kernels of varying sizes and resource requirements.

[0088] Figure 1A This diagram illustrates the continuous storage resource usage of one embodiment in the related art. Figure 1B This demonstrates the process of allocating storage resources for a new thread bundle under this resource occupancy mode. For example... Figure 1A As shown, a segment of memory resources with contiguous physical addresses in the GPU is divided into memory blocks 0 to 5. Under the traditional contiguous resource allocation strategy, thread bundles 0 to 4 are allocated memory resources sequentially: thread bundle 0 occupies memory block 0, thread bundle 1 occupies memory block 1, thread bundle 2 occupies memory block 2, thread bundle 3 occupies memory block 3, and thread bundle 4 occupies memory block 4, while memory block 5 is initially idle. When thread bundles 1 and 3 complete their tasks, their occupied memory blocks 1 and 3 are released, forming two scattered idle areas. The remaining thread bundles continue to occupy their original resources, resulting in a fragmented distribution of overall available resources. Figure 1BAs shown, in Figure 1A In the resource occupancy state shown, new thread bundles N through N+3 (where N is an integer greater than 4) are waiting to be allocated storage resources. The resource capacity required by thread bundles N and N+1 exceeds the size of storage blocks 1 and 3, respectively. While the resource capacity required by thread bundle N+2 is less than that of storage block 3, it is greater than that of storage block 1. Because the traditional mechanism requires the allocation of contiguous physical storage space, storage blocks 1 and 3 are insufficient to meet the needs of thread bundles N and N+1, nor can they be used by thread bundles N+2 and N+3. Therefore, the system can only start allocation from the larger free area, storage block 5: thread bundles N and N+1 are allocated to contiguous space in storage block 5, while thread bundle N+2 is allocated to storage block 3. However, the resource size required by thread bundle N+3 exceeds both the capacity of storage block 1 and the remaining available space in storage block 5, making it impossible to find a contiguous storage area that meets its needs, ultimately leading to resource allocation failure. It is evident that as tasks are dynamically executed and resources are released, small-sized free blocks are difficult to utilize effectively and remain idle for extended periods, resulting in a waste of storage resources and severely restricting the resource utilization rate of GPUs in multi-task concurrent scenarios.

[0089] Figure 2A A schematic diagram illustrating the continuous storage resource usage of another embodiment in the related art is shown. Figure 2B This demonstrates the process of allocating storage resources for the new thread bundle under this resource distribution. For example... Figure 2A As shown, a segment of memory resources with contiguous physical addresses in the GPU is divided into memory blocks 0 to 8. Under the traditional contiguous resource allocation mechanism, thread bundles 0 to 8 are allocated memory resources sequentially: thread bundle 0 occupies memory block 0, thread bundle 1 occupies memory block 1, thread bundle 2 occupies memory block 2, thread bundle 3 occupies memory block 3, thread bundle 4 occupies memory block 4, thread bundle 5 occupies memory block 5, thread bundle 6 occupies memory block 6, thread bundle 7 occupies memory block 7, and thread bundle 8 occupies memory block 8. When the tasks of thread bundles 1, 3, 5, and 7 are completed, their occupied memory blocks 1, 3, 5, and 7 are released, forming multiple scattered and discontinuous free areas. Meanwhile, thread bundles 0, 2, 4, 6, and 8 continue to occupy their respective memory blocks, resulting in severe fragmentation of the available memory space. Figure 2B As shown, in Figure 2AIn the resource occupancy scenario shown, new thread bundles M through M+3 (where M is an integer greater than 8) request storage resource allocation. The storage space required by these new tasks is greater than the individual capacities of storage blocks 1, 3, 5, and 7, making it impossible to utilize these small, free blocks that have already been released. Although the total capacity of the free storage blocks in the system is sufficient to meet the resource requirements of the new thread bundles, the traditional allocation strategy requires allocating contiguous physical address space for each thread bundle, making it impossible to integrate multiple non-contiguous small blocks of resources. This results in the inability to allocate sufficient storage resources to thread bundles M through M+3. This allocation failure due to address discontinuity fully exposes the limitations of existing technologies in managing storage resources in a multi-task dynamic scheduling environment. Even with a sufficient total amount of free resources, a lack of sufficiently large contiguous space can still cause task delays or blocking, thereby reducing the overall throughput and resource utilization of the GPU.

[0090] Based on this, this disclosure provides a resource allocation method, resource allocation device, electronic device, and medium to solve the problem of storage space fragmentation caused by continuous storage resource allocation in existing GPU architectures, thereby improving the resource utilization and overall throughput of GPUs in multi-task concurrent scenarios.

[0091] System architecture description applied in the embodiments of this disclosure

[0092] Figure 3 This is a schematic diagram of the system architecture used in the resource allocation method of this disclosure embodiment. The system mainly includes a computing component 300, which includes a scheduling unit 310 for workgroup scheduling and multiple computing units 320. Computing units 0 to 3 are shown in the figure as an example, but it should be understood that the architecture is not limited thereto, and the computing component 300 may contain more or fewer computing units 320 according to actual design requirements. Multiple computing units 320 may be included in a cluster according to design requirements. Each computing unit 320 further includes a scheduling unit 321 for thread bundle scheduling, multiple execution units 322, and shared memory 324. Each execution unit 322 includes a register file 323. Execution units 0 to 3 are shown in the figure, and are also only for illustrative purposes; in actual implementation, any number of execution units 322 may be included.

[0093] The computing component 300 is a computer processing device with parallel processing capabilities, suitable for high-concurrency, high-throughput computing tasks. Typical applications include graphics processing, scientific computing, and artificial intelligence training and inference. This computing component can be implemented using various processor architectures, such as a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a General-Purpose Computing on Graphics Processing Units (GPGPU), a Neural Processing Unit (NPU), or a Tensor Processing Unit (TPU). When processing graphics-related tasks, such as image recognition, 3D rendering, or animation generation, the computing component 300 typically employs a GPU architecture to fully leverage its massively parallel computing advantages; while for performing general computing tasks, such as operating system scheduling or serial logic processing, a CPU architecture can be used to balance flexibility and control efficiency.

[0094] During task execution, the scheduling unit 310 is responsible for dividing the received computing tasks into several workgroups and assigning these workgroups to appropriate computing units 320 for processing. Each workgroup consists of multiple warps. After entering a computing unit, the scheduling unit 321 within that unit further distributes the warps to execution units 322 for parallel computation. During execution, the register file 323 provides low-latency data storage and access support for each thread, while the shared memory 324 serves as a temporary storage area for efficient data sharing and collaborative communication between threads within the same workgroup. Each computing unit 320 exclusively uses the physical resource areas of the register file 323 and shared memory 324 allocated to it, ensuring resource isolation between different computing units. Within the same computing unit 320, multiple execution units 322 can share access to the shared memory 324 resources allocated to that computing unit 320 to support inter-thread cooperation. The resources of the register file 323 are divided according to threads or execution units, with each execution unit 322 exclusively using its allocated register space. This ensures the independence of thread execution, avoids data conflicts, and improves overall execution efficiency. This architecture provides the hardware foundation for the subsequent implementation of fine-grained, non-contiguous resource allocation mechanisms.

[0095] Figure 4 This is a schematic diagram of the structure of a computing unit according to an embodiment of this disclosure. Figure 4As shown, the computing unit 320 includes multiple execution units 322, a scheduling unit 321, and shared memory 324. Execution units 322 include general-purpose registers, namely scalar general-purpose register 431 and vector general-purpose register 432. Execution units 0 to 3 are shown as examples in the figure; however, it should be understood that the architecture is not limited to this, and the computing unit 320 may contain more or fewer execution units 322 depending on actual design requirements. The multiple execution units 322 in the computing unit 320 dynamically allocate thread bundles through the scheduling unit 321 and select either scalar general-purpose register 431 or vector general-purpose register 432 for data processing based on the instruction type.

[0096] Figure 5A This is a schematic diagram of shared memory according to one embodiment of the present disclosure. In some embodiments, such as Figure 5A As shown, the shared memory 324 includes memory cells arranged in an array, with the physical storage addresses of the memory cells being consecutive in the row direction and connected end-to-end in the row sequence. The memory cells of the shared memory 324 are divided into multiple first banks in the column direction. It should be noted that the banks in this embodiment can independently respond to access requests, supporting parallel read / write operations to improve bandwidth utilization. The shared memory 324 includes multiple memory logical sub-blocks 510, each memory logical sub-block 510 including multiple consecutive rows of memory cells located in multiple banks. For example, the memory cells of the shared memory 324 are divided into first banks 10 to 17 in the column direction, with additional... Figure 5A The first memory bank is labeled Bank10 to Bank17, with each bank having a width of 512 bits. Each first memory bank has a depth (also known as the number of rows) of 256 rows. The total storage capacity of the shared memory (324) is... The memory cells located in the first memory bank 10 to 17, comprising four consecutive rows (i.e., consecutive word lines) in the shared memory 324, are divided into a single memory logical sub-block 510. The first memory bank 10 to 17 are further divided into 64 memory logical sub-blocks 510, each with a storage capacity of [missing information]. Each memory logical sub-block 510 can be allocated to any workgroup for exclusive use until the workgroup releases the memory logical sub-block.

[0097] Figure 5B This is a schematic diagram of a scalar general-purpose register according to an embodiment of the present disclosure. In some embodiments, such as Figure 5BAs shown, the scalar general-purpose register 431 includes scalar general-purpose register cells arranged in an array. The physical storage addresses of the register cells are consecutive in the row direction and connected end-to-end in the column direction. The register cells are divided into multiple second storage banks in the column direction. The scalar general-purpose register 431 includes multiple scalar general-purpose register logic sub-blocks 520, each of which includes multiple consecutive rows of scalar general-purpose register cells located in multiple second storage banks. For example, the scalar general-purpose register cells of the scalar general-purpose register 431 are divided into second storage banks 20 and second storage banks 21 in the column direction. Figure 5B The two banks are labeled Bank20 and Bank21, respectively. Each second bank has a width of 32 bits, and one row of register cells in each second bank forms a 32-bit register. Each second bank has a depth (also known as the number of rows) of 256 rows, capable of storing 256 32-bit register data. The total storage capacity of the scalar general-purpose register 431 is 2 × 256 × 32 bits = 2 KB. The 32-bit register numbers in second banks 20 and 21 are consecutive in the row direction and connected end-to-end, forming a continuous register numbering space from 0 to 511 (represented as SGPR0 to SGPR511 in the diagram). Second bank 20 stores 32-bit registers with even-numbered registers, and second bank 21 stores 32-bit registers with odd-numbered registers, implementing an interleaved storage structure. This layout allows adjacent register data to be distributed across different banks, supporting concurrent access and improving data throughput. In one example, eight contiguous 32-bit registers are divided into a single scalar general-purpose register logic subblock 520, each with a storage capacity of 8 × 32 bits = 32 bytes. A total of 512 physically contiguous 32-bit register resources are divided into 64 scalar general-purpose register logic subblocks 520. Each scalar general-purpose register logic subblock 520 includes four 32-bit registers with odd-numbered register numbers and four 32-bit registers with even-numbered register numbers. Each scalar general-purpose register logic subblock 520 can be exclusively allocated to any thread bundle until the thread bundle releases it.

[0098] Figure 5C This is a schematic diagram of a vector general-purpose register according to an embodiment of the present disclosure. In some embodiments, such as Figure 5CAs shown, the vector general-purpose register 432 includes vector general-purpose register cells arranged in an array. The physical storage addresses of the register cells are contiguous in the row direction and connected end-to-end in the column direction. The register cells are divided into multiple third storage banks in the column direction. The vector general-purpose register 432 includes multiple vector general-purpose register logic sub-blocks 530, each of which includes multiple consecutive rows of vector general-purpose register cells located in multiple third storage banks. For example, the vector general-purpose register cells of the vector general-purpose register 432 are divided into third storage banks 30 and 31 in the column direction, and in the appendix... Figure 5C The third storage bank is labeled Bank30 and Bank31 respectively. Each third storage bank has a bit width of 1024 bits, and each row of register cells in each third storage bank forms 32 32-bit registers (i.e., each row of register cells in the third storage bank can be allocated to 32 threads (labeled thread0 to thread31 in the diagram)). Each third storage bank has a depth (also called the number of rows) of 256 rows, which can store 256 32×32-bit register data. The total storage capacity of the vector general-purpose register 432 is 2×256×1024 bits = 64 KB. The 32×32-bit registers in third storage banks 30 and 31 are numbered consecutively in the row direction and connected end-to-end, forming a continuous register numbering space from 0 to 511 (represented as R0 to R511 in the diagram). Third storage bank 30 stores 32×32-bit registers with even-numbered registers, and third storage bank 31 stores 32×32-bit registers with odd-numbered registers, implementing a cross-storage structure. This layout distributes adjacent register data across different memory banks, supporting concurrent access and improving data throughput. In one example, four contiguous 32×32-bit registers are divided into a single vector general-purpose register logical subblock 530, each with a storage capacity of 4×1024 bits = 512 bytes. The 512 physically contiguous 32×32-bit register resources are divided into 128 vector general-purpose register logical subblocks 530. Each vector general-purpose register logical subblock 530 includes two odd-numbered 32×32-bit registers and two even-numbered 32×32-bit registers. Each vector general-purpose register logical subblock 530 can be exclusively allocated to any thread bundle until the thread bundle releases the subblock 530.

[0099] Understandably, shared memory is organized as an array of memory cells, with their physical storage addresses contiguously arranged row-wise and divided into multiple memory banks along the column direction to support parallel access and high-bandwidth data throughput. Each logical sub-block of memory consists of several consecutive rows spanning multiple memory banks, ensuring access locality while avoiding access conflicts within a single memory bank. Similarly, general-purpose registers are organized using the same array structure, with register cells addressed contiguously in the row direction and divided into multiple memory banks along the column direction. A register logical sub-block consists of multiple consecutive rows of register cells located within multiple memory banks. This structural design not only facilitates the division of physical resources into fixed-size logical sub-blocks but also provides a unified hardware support foundation for subsequent resource scheduling, address decoding, and conflict detection, enhancing the feasibility and scalability of resource management mechanisms.

[0100] Overall Implementation of the Resource Allocation Method in the Embodiments of this Disclosure

[0101] The resource allocation method provided in this disclosure is applied in... Figure 4 The calculation unit shown Figure 6 This is a main flowchart of a resource allocation method according to an embodiment of this disclosure. Figure 6 As shown, the resource allocation method includes the following steps:

[0102] Step S601: Obtain the storage requirement information of the workgroup task to be executed. The storage requirement information includes the number of shared memory resources required by the workgroup task and the number of general-purpose register resources required by multiple thread bundle tasks in the workgroup task.

[0103] Step S602: Based on the required amount of shared memory resources, determine whether the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task.

[0104] Step S603: If the number of available memory logical sub-blocks in the shared memory meets the needs of the workgroup task, allocate corresponding memory logical sub-blocks to the workgroup task, and

[0105] For each thread bundle task in the workgroup task, based on the number of general register resources required by the corresponding thread bundle task, determine whether there is an execution unit among the multiple execution units whose number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task.

[0106] Step S604: If there is an execution unit among the plurality of execution units where the number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task, allocate the corresponding register logic sub-block in the execution unit to the corresponding thread bundle task.

[0107] In step S601, storage requirement information can be generated by parsing the intermediate representation of kernel functions to determine the actual scale of shared memory and general-purpose register usage for each task.

[0108] In some embodiments, such as Figure 4 As shown, the computing unit 320 also includes a first counting register 411 and a first mapping table 421. The first counting register 411 is used to record the number of available memory logical sub-blocks 510 in the shared memory 324. The first mapping table 421 is configured to correspond to the workgroup tasks, and includes the mapping relationship between the virtual shared memory slot number to be used by the workgroup task and the slot number of the allocated memory logical sub-block 510. Figure 7A This is a schematic diagram of a first mapping table for shared memory according to an embodiment of the present disclosure. Figure 7A As shown, the first mapping table 421 records the virtual shared memory slot number (virtual smem slot id) to be used by the workgroup tasks. Figure 7A The virtual slot number (abbreviated as "virtual slot number") is the slot number (physical smem slot id) from the allocated memory logical subblock 510. Figure 7A This refers to a dynamic mapping relationship (abbreviated as "physical slot number"), which is dynamically established during task scheduling and supports flexible resource allocation and reclamation. For example, the shared memory resource requirement for workgroup task number 0 is 4 KB, the shared memory resource requirement for workgroup task number k is 4 KB, and the shared memory resource requirement for workgroup task number n (where n is a positive integer, and k is greater than 0 and less than n) is 2 KB.

[0109] In step S602, the required amount of shared memory resources is compared with the value of the first counter register 411. If the required amount of shared memory resources is less than or equal to the value of the first counter register 411, it is determined that the number of available memory logical sub-blocks 510 in shared memory 324 meets the requirements of the workgroup task. If the required amount of shared memory resources is greater than the value of the first counter register 411, it is determined that the number of available memory logical sub-blocks 510 in shared memory 324 does not meet the requirements of the workgroup task, and resource allocation for the workgroup task is suspended. It should be noted that, if necessary, the required amount of shared memory resources and the value of the first counter register 411 may be compared after a certain unit conversion to determine whether the number of available memory logical sub-blocks 510 in shared memory 324 meets the requirements of the workgroup task.

[0110] In step S603, if the number of available memory logical sub-blocks 510 in shared memory 324 meets the needs of the workgroup task, the corresponding memory logical sub-blocks 510 are allocated to the workgroup task. The mapping relationship between the virtual shared memory slot number to be used by the workgroup task and the slot number of the allocated memory logical sub-block is recorded in the first mapping table 421. The value of the first counter register 411 is subtracted from the number of shared memory resources required. In some embodiments, the allocation strategy for memory logical sub-blocks 510 includes: the memory units of shared memory 324 are divided into multiple memory logical sub-blocks 510, and the multiple memory logical sub-blocks 510 correspond to multiple physical slots, and the physical slots of the memory logical sub-blocks 510 are numbered; the physical slot number of the first free memory logical sub-block 510 is recorded using a start pointer, and its value is dynamically updated with resource allocation and reclamation to ensure that the allocation process of memory logical sub-blocks 510 is continuous and efficient; when performing resource allocation, the required number of free memory logical sub-blocks 510 are continuously allocated from the physical slot indicated by the start pointer until the shared memory requirements of the workgroup task are met; if the requirements are not met even after reaching the end of the physical slot, the search continues to the starting position to ensure maximum utilization of fragmented free slots; after the allocation is completed, the correspondence between virtual shared memory slots and physical slots in the first mapping table 421 is updated, and the start pointer is updated to point to the next free physical slot.

[0111] Figure 7D This is a schematic diagram of slots for allocating logical sub-blocks of memory according to one embodiment of the present disclosure. In some embodiments, such as Figure 7D As shown, the shared memory 324 memory cells are divided into 64 memory logical sub-blocks 510. Each of the 64 memory logical sub-blocks 510 corresponds to a physical slot. These physical slots are numbered from physical slot 0 to physical slot 63. Figure 7D Physical slots 0 to 63 are represented by blocks 0 to 63, respectively. Dark blocks represent allocated (i.e., occupied) memory logical sub-blocks 510, while light blocks represent unallocated (i.e., free) memory logical sub-blocks 510. A start pointer records the physical slot number of the first free memory logical sub-block 510. In some embodiments, if the number of available memory logical sub-blocks 510 in shared memory 324 meets the needs of the workgroup task, the required number of free memory logical sub-blocks 510 are allocated consecutively starting from the physical slot indicated by the start pointer. If the number of free physical slots from the start pointer to the end is insufficient, the search for free physical slots continues starting from physical slot 0 until a sufficient number of consecutive free memory logical sub-blocks 510 are found and allocated. After allocation, the correspondence between virtual shared memory slots and physical slots in the first mapping table 421 is updated, and the start pointer is pointed to the next free physical slot.

[0112] Refer again Figure 7A Taking task number 0 as an example, the virtual shared memory slots for the required 4 KB shared memory are numbered 0 and 1. Virtual shared memory slot number 0 corresponds to virtual shared memory depths 0 to 3, and virtual shared memory slot number 1 corresponds to virtual shared memory depths 4 to 7. In the first mapping table 421, a mapping relationship is established between virtual shared memory slot number 0 and slot number 62 of the allocated memory logical sub-block 510, and a mapping relationship is established between virtual shared memory slot number 1 and slot number 63 of the allocated memory logical sub-block 510. Slot number 62 of the allocated memory logical sub-block 510 corresponds to physical shared memory depths 248 to 251, and slot number 63 corresponds to physical shared memory depths 252 to 255. Taking task number k as an example, the virtual shared memory slots for the required 4 KB shared memory are numbered 0 and 1. Virtual shared memory slot number 0 corresponds to virtual shared memory depths 0 to 3, and virtual shared memory slot number 1 corresponds to virtual shared memory depths 4 to 7. In the first mapping table 421, a mapping relationship is established between virtual shared memory slot number 0 and slot number 0 of the allocated memory logical sub-block 510, and a mapping relationship is established between virtual shared memory slot number 1 and slot number 1 of the allocated memory logical sub-block 510. Slot number 0 of the allocated memory logical sub-block 510 corresponds to physical shared memory depths 0 to 3, and slot number 1 corresponds to physical shared memory depths 4 to 7. Taking a workgroup task with number n as an example, the virtual shared memory slot number for its required 2 KB shared memory is 0, and virtual shared memory slot number 0 corresponds to virtual shared memory depths 0 to 3. In the first mapping table 421, a mapping relationship is established between virtual shared memory slot number 0 and slot number 32 of the allocated memory logical sub-block 510. Slot number 32 of the allocated memory logical sub-block 510 corresponds to physical shared memory depths 128 to 131.

[0113] In some embodiments, such as Figure 4 As shown, the computation unit 320 also includes multiple second mapping tables 422 and multiple second counting registers 412. The multiple second mapping tables 422 are configured to correspond to multiple thread bundle tasks in the workgroup task, and the multiple second counting registers 412 are configured to correspond to the multiple execution units 322. The second mapping table 422 includes the mapping relationship between the virtual scalar general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated scalar general-purpose register logical sub-block 520. The second counting registers 412 are used to record the number of scalar general-purpose register logical sub-blocks 520 available in the corresponding execution unit 322. Figure 7B This is a schematic diagram of a second mapping table for a scalar general-purpose register according to an embodiment of the present disclosure. Figure 7B As shown, the second mapping table 422 records the virtual scalar general-purpose register slot number (virtual sgpr slot id) used by the thread bundle task. Figure 7B The virtual slot number (marked as "virtual slot number") is the slot number (physical sgpr slot id) of the allocated scalar general-purpose register logic subblock 520. Figure 7B The dynamic mapping relationship between the physical slot numbers (marked as "physical slot numbers") is established dynamically during task scheduling, supporting flexible resource allocation and reclamation. For example, the scalar general-purpose register resource requirement for thread bundle task number 0 is 128 32-bit registers, while the scalar general-purpose register resource requirement for thread bundle task number m (where m is a positive integer) is 32 32-bit registers.

[0114] In some embodiments, such as Figure 4 As shown, the computing unit 320 also includes multiple third mapping tables 423 and multiple third counting registers 413. The multiple third mapping tables 423 are configured to correspond to multiple thread bundle tasks in the workgroup task, and the multiple third counting registers 413 are configured to correspond to the multiple execution units 322. The third mapping table 423 includes the mapping relationship between the virtual vector general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated vector general-purpose register logical sub-block 530. The third counting register 413 is used to record the number of available vector general-purpose register logical sub-blocks 530 in the corresponding execution unit 322. Figure 7C This is a schematic diagram of a third mapping table for a vector general-purpose register according to an embodiment of this disclosure. Figure 7C As shown, the third mapping table 423 records the virtual vector general-purpose register slot number (virtual vgpr slot id) used by the thread bundle task. Figure 7C The slot number (marked as "virtual slot number") and the slot number (physical vgpr slot id) of the allocated vector general-purpose register logic subblock 530 are used to determine the slot number. Figure 7C The dynamic mapping relationship between the physical slot numbers (marked as "physical slot numbers") is established dynamically during task scheduling, supporting flexible resource allocation and reclamation. For example, the vector general-purpose register resource requirement for thread bundle task number 0 is 256 32×32-bit registers, while the vector general-purpose register resource requirement for thread bundle task number m (where m is a positive integer) is 32 32×32-bit registers.

[0115] Next, in step S603, if the number of available memory logical sub-blocks 510 in shared memory 324 meets the needs of the workgroup tasks, after allocating corresponding memory logical sub-blocks 510 to the workgroup tasks, for each thread bundle task, the number of scalar general-purpose register resource requirements of the corresponding thread bundle task is compared with the value of the corresponding second counter register 412 of the corresponding execution unit 322, and the number of vector general-purpose register resource requirements of the corresponding thread bundle task is compared with the value of the corresponding third counter register 413 of the corresponding execution unit 322. If the number of scalar general-purpose register resource requirements of the corresponding thread bundle task is less than or equal to the value of the second counter register 412 corresponding to the selected execution unit 322, and the number of vector general-purpose register resource requirements of the corresponding thread bundle task is less than or equal to the value of the third counter register 413 corresponding to the selected execution unit 322, then it is determined that the number of available register logical sub-blocks in the execution unit 322 meets the needs of the thread bundle task. If the scalar general-purpose register resource requirement of the corresponding thread bundle task is greater than the value of the second counter register 412 corresponding to the selected execution unit 322, and / or the vector general-purpose register resource requirement of the corresponding thread bundle task is greater than the value of the third counter register 413 corresponding to the selected execution unit 322, then it is determined that the number of available register logic sub-blocks in the execution unit 322 does not meet the requirements of the thread bundle task. A polling method is then used to select the next execution unit 322 to determine whether the number of available register logic sub-blocks in the next execution unit 322 meets the requirements of the thread bundle task. If none of the multiple execution units 322 can meet the requirements of the thread bundle task, then resource allocation for the thread bundle task is paused. It should be noted that, if necessary, the number of scalar general-purpose register resources required for the corresponding thread bundle task and the value of the corresponding second counter register 412 of the corresponding execution unit 322 are compared after a certain unit conversion. Similarly, if necessary, the number of vector general-purpose register resources required for the corresponding thread bundle task and the value of the corresponding third counter register 413 of the corresponding execution unit 322 are compared after a certain unit conversion to determine whether the number of available register logic sub-blocks in the execution unit 322 meets the requirements of the thread bundle task.

[0116] In step S604, if one of the plurality of execution units 322 has enough available register logic sub-blocks to meet the requirements of the corresponding thread bundle task, a corresponding scalar general-purpose register logic sub-block 520 and / or vector general-purpose register logic sub-block 530 is allocated to the corresponding thread bundle task. The mapping relationship between the virtual scalar general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated scalar general-purpose register logic sub-block 520 is recorded in the corresponding second mapping table 422, and / or the mapping relationship between the virtual vector general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated vector general-purpose register logic sub-block 530 is recorded in the corresponding third mapping table 423. The value of the corresponding second counter register 412 is subtracted from the scalar general-purpose register resource requirement, and / or the value of the corresponding third counter register 413 is subtracted from the vector general-purpose register resource requirement. In some embodiments, the allocation strategy for scalar general-purpose register logic sub-blocks 520 includes: dividing the scalar general-purpose register 431 into multiple scalar general-purpose register logic sub-blocks 520, with each sub-block corresponding to a physical slot; and numbering the physical slots of the scalar general-purpose register logic sub-blocks 520; using a start pointer to record the physical slot number of the first currently free scalar general-purpose register logic sub-block 520, with its value dynamically updated during resource allocation and reclamation to ensure the scalar general-purpose register logic sub-blocks 520 remain free. The allocation process of 20 is continuous and efficient. When performing resource allocation, the required number of free scalar general-purpose register logical sub-blocks 520 are continuously allocated starting from the physical slot indicated by the start pointer until the scalar general-purpose register requirements of the corresponding thread bundle task are met. If the requirements are not met even after reaching the end of the physical slot, the search continues to the starting position to ensure maximum utilization of fragmented free slots. After allocation, the correspondence between the virtual scalar general-purpose register slot number and the physical slot in the second mapping table 422 is updated, and the start pointer is updated to point to the next free physical slot.

[0117] Figure 7E This is a schematic diagram of slots allocated to scalar general-purpose register logic subblocks according to an embodiment of this disclosure. In some embodiments, such as Figure 7E As shown, the 512 contiguous 32-bit register resources of the scalar general-purpose register 431 are divided into 64 scalar general-purpose register logical sub-blocks 520. These 64 sub-blocks correspond to 64 physical slots, which are numbered from physical slot 0 to physical slot 63. Figure 7EPhysical slots 0 to 63 are represented by blocks 0 to 63, respectively. Dark blocks represent allocated (i.e., occupied) scalar general-purpose register logical sub-blocks 520, while light blocks represent unallocated (i.e., free) scalar general-purpose register logical sub-blocks 520. A start pointer records the physical slot number of the first free scalar general-purpose register logical sub-block 520. In some embodiments, if the number of available scalar general-purpose register logical sub-blocks 520 in scalar general-purpose register 431 meets the requirements of the thread bundle task, the required number of scalar general-purpose register logical sub-blocks 520 are continuously allocated starting from the physical slot indicated by the start pointer. If the number of free physical slots from the start pointer to the end is insufficient, the search for free physical slots continues starting from physical slot 0 until a sufficient number of consecutive scalar general-purpose register logical sub-blocks 520 are found and allocated. After allocation, the correspondence between virtual scalar general-purpose register slots and physical slots in the second mapping table 422 is updated, and the start pointer is pointed to the next free slot.

[0118] Refer again Figure 7B Taking thread bundle task number 0 as an example, the virtual scalar general-purpose register slots numbered 0 to 16 for the 128 required 32-bit registers, which correspond to virtual scalar general-purpose register numbers R0 to R127. In the second mapping table 422, virtual scalar general-purpose register slots 0 to 16 are mapped to slots 32 to 47 of the allocated scalar general-purpose register logic sub-block 520. Slots 32 to 47 of the allocated scalar general-purpose register logic sub-block 520 correspond to physical scalar general-purpose register numbers R256 to R383. Taking thread bundle task number m as an example, the virtual scalar general-purpose register slots numbered 0 to 4 for the 32 required 32-bit registers, which correspond to virtual scalar general-purpose register numbers R0 to R31. In the second mapping table 422, virtual scalar general-purpose register slot numbers 0 to 4 are mapped to slot numbers 62, 63, 0, and 1 of the allocated scalar general-purpose register logic sub-block 520. The slot numbers 62, 63, 0, and 1 of the allocated scalar general-purpose register logic sub-block 520 correspond to physical scalar general-purpose register numbers R496 to R511 and R0 to R15.

[0119] In some embodiments, the allocation strategy for vector general-purpose register logical sub-blocks 530 includes: the vector general-purpose register 432 is divided into multiple vector general-purpose register logical sub-blocks 530, each corresponding to a physical slot; the physical slot numbers of the vector general-purpose register logical sub-blocks 530 are assigned; a start pointer is used to record the physical slot number of the first free vector general-purpose register logical sub-block 530, and its value is dynamically updated with resource allocation and reclamation to ensure the continuity and efficiency of the allocation process of vector general-purpose register logical sub-blocks 530; when performing resource allocation, the required number of free vector general-purpose register logical sub-blocks 530 are continuously allocated starting from the physical slot indicated by the start pointer until the vector general-purpose register requirements of the corresponding thread bundle task are met; if the requirements are not met even after reaching the end of the physical slot, the search continues to the starting position to ensure maximum utilization of fragmented free slots; after allocation, the correspondence between virtual vector general-purpose register slot numbers and physical slots in the third mapping table 423 is updated, and the start pointer is updated to point to the next free physical slot.

[0120] Figure 7F This is a schematic diagram of the slots of an allocation vector general-purpose register logic subblock according to an embodiment of this disclosure. In some embodiments, such as Figure 7F As shown, the 512 contiguous 32×32-bit register resources of the vector general-purpose register 432 are divided into 128 vector general-purpose register logical sub-blocks 530. These 128 sub-blocks correspond to physical slots, which are numbered from physical slot 0 to physical slot 127. Figure 7F Physical slots 0 to 127 are represented by blocks 0 to 127, respectively. Dark blocks represent allocated (i.e., occupied) vector general-purpose register (GPUR) logical sub-blocks 530, while light blocks represent unallocated (i.e., free) GPUR logical sub-blocks 530. A start pointer records the physical slot number of the first free GPUR logical sub-block 530. In some embodiments, if the number of available GPUR logical sub-blocks 530 in the vector general-purpose register 432 meets the requirements of the thread bundle task, the required number of GPUR logical sub-blocks 530 are continuously allocated starting from the physical slot indicated by the start pointer. If the number of free physical slots from the start pointer to the end is insufficient, the search for free physical slots continues starting from physical slot 0 until a sufficient number of consecutive GPUR logical sub-blocks 530 are found and allocated. After allocation, the correspondence between virtual GPUR logical register slots and physical slots in the third mapping table 423 is updated, and the start pointer is pointed to the next free slot.

[0121] Refer again Figure 7C Taking thread bundle task number 0 as an example, the virtual vector general-purpose register slots numbered 0 to 64 for the 256 required 32×32-bit registers, which correspond to virtual vector general-purpose register numbers R0 to R255. In the third mapping table 423, virtual vector general-purpose register slots 0 to 64 are mapped to slots 2 to 65 of the allocated vector general-purpose register logic sub-block 530. Slots 2 to 65 of the allocated vector general-purpose register logic sub-block 530 correspond to physical vector general-purpose register numbers R4 to R259. Taking thread bundle task number m as an example, the virtual vector general-purpose register slots numbered 0 to 7 for the 32 required 32×32-bit registers, which correspond to virtual vector general-purpose register numbers R0 to R31. In the third mapping table 423, virtual vector general-purpose register slot numbers 0 to 7 are mapped to slot numbers 121 to 127 and 0 of the allocated vector general-purpose register logic sub-block 530. The slot numbers 121 to 127 and 0 of the allocated vector general-purpose register logic sub-block 530 correspond to physical vector general-purpose register numbers R484 to R511 and R0 to R3.

[0122] Next, after step S604, for each thread bundle task in the workgroup task, after the corresponding thread bundle task is completed, the scalar general-purpose register logic subblock 520 and / or vector general-purpose register logic subblock 530 occupied by it are released; the mapping relationship between the virtual scalar general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated scalar general-purpose register logic subblock 520 is deleted in the corresponding second mapping table 422, and / or the mapping relationship between the virtual vector general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated vector general-purpose register logic subblock 530 is deleted in the corresponding third mapping table 423; the value of the corresponding second counter register 412 is added to the scalar general-purpose register resource requirement, and / or the value of the corresponding third counter register 413 is added to the vector general-purpose register resource requirement.

[0123] Next, after step S604, after the workgroup task has finished executing, the memory logical sub-block 510 it occupies is released; the mapping relationship between the virtual shared memory slot number to be used by the workgroup task and the slot number of the allocated memory logical sub-block 510 is deleted from the first mapping table 421; the value of the first counter register 411 is added to the shared memory resource requirement. In some embodiments, the mapping relationships in the first mapping table 421, the second mapping table 422, and the third mapping table 423 may not be actively deleted, but the mapping table entries may be updated during subsequent task allocation by overwriting. In this case, the deletion of the mapping relationship is naturally completed by writing the mapping table entry of the new task, thereby reducing control overhead.

[0124] Figure 8 yes Figure 2A A schematic diagram illustrating the allocation of storage resources to a thread bundle according to an embodiment of this disclosure under conditions of continuous storage resource occupancy. In some embodiments, such as Figure 8 As shown, in Figure 2A In the resource occupancy scenario shown, new thread bundles M to M+3 (where M is an integer greater than 8) request storage resource allocation. The storage space required by these new tasks is greater than the capacity of each of storage blocks 1, 3, 5, and 7. In the resource allocation method of this embodiment, storage blocks 1, 3, 5, and 7 are divided into multiple register logic sub-blocks (scalar general-purpose register logic sub-blocks or vector general-purpose register logic sub-blocks). Based on the specific resource requirements of each thread bundle, the allocation is dynamically combined by establishing a mapping relationship between virtual address slots and physical address slots of the logic sub-blocks in the corresponding second or third mapping table. For example, storage blocks 1, 3, and 5 are allocated to thread bundle M.

[0125] It is understood that the embodiments of this disclosure, by logically dividing the physical storage resources of general-purpose registers and shared memory into multiple logical sub-blocks and introducing a dynamic management mechanism combining mapping tables and counting registers, achieve fine-grained, non-contiguous allocation of critical storage resources in computing units, thereby breaking through the limitation of resource allocation based on contiguous address spaces in traditional GPU architectures. This mechanism allows the system to flexibly select available memory logical sub-blocks or register logical sub-blocks for allocation from different physical locations according to the actual distribution of idle resources, without waiting for the release of large contiguous spaces, significantly reducing task scheduling latency caused by storage resource fragmentation. Simultaneously, by establishing an independent mapping relationship between virtual address slots and physical address slots of logical sub-blocks for each workgroup task or thread bundle task, the program logic can still access resources in a contiguous address space manner, shielding the complexity of underlying non-contiguous allocation and maintaining the transparency and compatibility of the programming model.

[0126] It is understood that the embodiments of this disclosure can achieve decoupled, non-contiguous dynamic allocation of shared memory and general-purpose register resources in the computing unit. Since each memory logical sub-block and register logical sub-block can be allocated and reclaimed independently, the continuity of physical addresses is no longer required. Therefore, even in high-concurrency multi-tasking scenarios with frequent resource allocation and release, the scattered idle resource blocks can still be fully utilized, significantly improving the overall utilization rate of hardware storage resources. This effectively avoids the utilization rate decline problem caused by fragmentation after resource release under the traditional static contiguous allocation mechanism. At the same time, by first determining whether the shared memory resources meet the requirements and then allocating thread bundles to appropriate execution units one by one, the orderliness and scalability of the resource allocation process are ensured, preventing the entire workgroup task from failing to start due to a resource bottleneck.

[0127] Description of apparatus and devices according to embodiments of this disclosure

[0128] Reference Figure 9 , Figure 9 This is a schematic diagram of a resource allocation device 900 disclosed herein. The resource allocation device 900 is integrated into a computing unit, which includes multiple execution units and shared memory. The execution units include general-purpose registers, which include multiple register logic sub-blocks. The shared memory includes multiple memory logic sub-blocks. The resource allocation device 900 includes:

[0129] The storage requirement information acquisition unit 910 is used to acquire the storage requirement information of the workgroup task to be executed. The storage requirement information includes the number of shared memory resources required by the workgroup task and the number of general-purpose register resources required by multiple thread bundle tasks in the workgroup task.

[0130] The available memory determination unit 920 is used to determine whether the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task based on the number of shared memory resource requirements.

[0131] The memory allocation unit 930 is configured to allocate corresponding memory logical sub-blocks to the workgroup task, provided that the number of available memory logical sub-blocks in the shared memory meets the needs of the workgroup task.

[0132] Available register determination unit 940 is used to determine, for each thread bundle task in the workgroup task, whether there is an execution unit among the multiple execution units whose number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task based on the number of general register resource requirements of the corresponding thread bundle task.

[0133] Register allocation unit 950 is used to allocate the corresponding register logic sub-block in the execution unit to the corresponding thread bundle task when there is an execution unit in which the number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task.

[0134] The resource allocation apparatus disclosed herein is used to execute the resource allocation method as described in the above embodiments. Its specific processing procedure is the same as that of the resource allocation method described in the above embodiments, and will not be repeated here.

[0135] This disclosure also provides an electronic device 1000, comprising:

[0136] At least one processor, and,

[0137] A memory that is communicatively connected to at least one processor; wherein,

[0138] The memory stores instructions that are executed by at least one processor to cause the at least one processor to perform the method as described in any of the above embodiments of this application when executing the instructions.

[0139] The following is combined Figure 10 The hardware structure of the electronic device is described in detail. The electronic device includes: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050.

[0140] The processor 1010 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this disclosure.

[0141] The memory 1020 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1020 and is invoked by the processor 1010 to execute the resource allocation method of the embodiments of this disclosure.

[0142] The input / output interface 1030 is used to implement information input and output;

[0143] The communication interface 1040 is used to enable communication and interaction between this device and other devices. Communication can be achieved via wired means (e.g., USB, Ethernet cable) or wireless means (e.g., mobile network, Wi-Fi, Bluetooth).

[0144] Bus 1050 transmits information between various components of the device (e.g., processor 1010, memory 1020, input / output interface 1030, and communication interface 1040);

[0145] The processor 1010, memory 1020, input / output interface 1030 and communication interface 1040 are connected to each other within the device via bus 1050.

[0146] This application also provides a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement the resource allocation method of the above embodiments, which will not be described again here.

[0147] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0148] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0149] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0150] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0151] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0152] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0153] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0154] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A method for resource allocation of a compute unit of a graphics processor, the compute unit comprising: The resource allocation method includes multiple execution units and shared memory, wherein each execution unit includes a general-purpose register, each general-purpose register includes multiple register logical sub-blocks, and the shared memory includes multiple memory logical sub-blocks. Obtain the storage requirement information of the workgroup task to be executed, wherein the storage requirement information includes the amount of shared memory resources required by the workgroup task and the amount of general-purpose register resources required by multiple thread bundle tasks in the workgroup task; Based on the required amount of shared memory resources, determine whether the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task; If the number of available memory logical sub-blocks in the shared memory meets the needs of the workgroup task, then allocate corresponding memory logical sub-blocks to the workgroup task, and For each thread bundle task in the workgroup task, based on the number of general register resources required by the corresponding thread bundle task, determine whether there is an execution unit among the multiple execution units whose number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task; If, among the plurality of execution units, there exists an execution unit whose number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task, then the corresponding register logic sub-block in that execution unit is allocated to the corresponding thread bundle task.

2. The resource allocation method of claim 1, wherein, The computing unit further includes a first counting register and a first mapping table. The first counting register is used to record the number of available memory logical sub-blocks in the shared memory. The first mapping table is set to correspond to the workgroup task. The first mapping table includes the mapping relationship between the virtual shared memory slot number to be used by the workgroup task and the slot number of the allocated memory logical sub-block.

3. The resource allocation method of claim 2, wherein, The general-purpose registers include scalar general-purpose registers. The computing unit also includes multiple second mapping tables and multiple second counting registers. The multiple second mapping tables are set to correspond to multiple thread bundle tasks in the workgroup task. The multiple second counting registers are set to correspond to the multiple execution units. The second mapping table includes the mapping relationship between the virtual scalar general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated scalar general-purpose register logical sub-block. The second counting register is used to record the number of scalar general-purpose register logical sub-blocks available in the corresponding execution unit.

4. The resource allocation method of claim 3, wherein, The general-purpose registers also include vector general-purpose registers. The computing unit also includes multiple third mapping tables and multiple third counting registers. The multiple third mapping tables are set to correspond to multiple thread bundle tasks in the workgroup task. The multiple third counting registers are set to correspond to the multiple execution units. The third mapping table includes the mapping relationship between the virtual vector general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated vector general-purpose register logical sub-block. The third counting register is used to record the number of available vector general-purpose register logical sub-blocks in the corresponding execution unit.

5. The resource allocation method of claim 4, wherein, The step of determining whether the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task based on the shared memory resource demand includes: The number of shared memory resource requirements is compared with the value of the first counter register. If the number of shared memory resource requirements is less than or equal to the value of the first counter register, it is determined that the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task. If the required amount of shared memory resources is greater than the value of the first counter register, it is determined that the number of available memory logical sub-blocks in the shared memory does not meet the requirements of the workgroup task, and resource allocation for the workgroup task is suspended.

6. The resource allocation method of claim 5, wherein, When the number of available memory logical sub-blocks in the shared memory meets the needs of the workgroup task, the corresponding memory logical sub-blocks are allocated to the workgroup task, including: Allocate corresponding memory logic sub-blocks for the tasks in the workgroup; The first mapping table records the mapping relationship between the virtual shared memory slot number to be used by the workgroup task and the slot number of the allocated memory logical sub-block; Subtract the required amount of shared memory resources from the value of the first counter register.

7. The resource allocation method of claim 6, wherein, For each thread bundle task in the workgroup task, based on the general register resource requirements of the corresponding thread bundle task, determining whether there is an execution unit among the multiple execution units with an available number of register logic sub-blocks that meet the requirements of the corresponding thread bundle task includes: For each thread bundle task, the number of scalar general-purpose register resource requirements of the corresponding thread bundle task is compared with the value of the corresponding second counter register of the corresponding execution unit, and the number of vector general-purpose register resource requirements of the corresponding thread bundle task is compared with the value of the corresponding third counter register of the corresponding execution unit. If the number of scalar general-purpose register resources required for the corresponding thread bundle task is less than or equal to the value of the second counter register corresponding to the selected execution unit, and the number of vector general-purpose register resources required for the corresponding thread bundle task is less than or equal to the value of the third counter register corresponding to the selected execution unit, then it is determined that the number of available register logic sub-blocks in the execution unit meets the requirements of the thread bundle task. If the scalar general-purpose register resource requirement of the corresponding thread bundle task is greater than the value of the second counter register corresponding to the selected execution unit, and / or the vector general-purpose register resource requirement of the corresponding thread bundle task is greater than the value of the third counter register corresponding to the selected execution unit, then it is determined that the number of available register logic sub-blocks in the execution unit does not meet the requirements of the thread bundle task. The next execution unit is selected by polling, and it is determined whether the number of available register logic sub-blocks in the next execution unit meets the requirements of the thread bundle task. If none of the multiple execution units can meet the requirements of the thread bundle task, then the resource allocation for the thread bundle task is suspended.

8. The resource allocation method according to claim 7, wherein, When one of the plurality of execution units has a number of available register logic sub-blocks that meet the requirements of the corresponding thread bundle task, the allocation of the corresponding register logic sub-block in that execution unit to the corresponding thread bundle task includes: Allocate corresponding scalar general-purpose register logic sub-blocks and / or vector general-purpose register logic sub-blocks to the corresponding thread bundle tasks; The second mapping table records the mapping relationship between the virtual scalar general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated scalar general-purpose register logical sub-block, and / or The mapping relationship between the virtual vector general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated vector general-purpose register logical sub-block is recorded in the corresponding third mapping table. Subtract the scalar general-purpose register resource requirement from the value of the corresponding second counter register, and / or Subtract the number of vector general-purpose register resources required from the value of the corresponding third counter register.

9. The resource allocation method according to claim 8, wherein, When, among the plurality of execution units, there exists an execution unit with a number of available register logic sub-blocks that meet the requirements of the corresponding thread bundle task, after allocating the corresponding register logic sub-block in that execution unit to the corresponding thread bundle task, the resource allocation method further includes: For each thread bundle task in the workgroup task, after the corresponding thread bundle task is completed, release the scalar general-purpose register logic sub-block and / or vector general-purpose register logic sub-block occupied by it. Remove the mapping relationship between the virtual scalar general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated scalar general-purpose register logical sub-block in the corresponding second mapping table, and / or Remove the mapping relationship between the virtual vector general-purpose register slot number to be used by the corresponding thread bundle task and the slot number of the allocated vector general-purpose register logical sub-block in the corresponding third mapping table. Add the value of the corresponding second counter register to the scalar general-purpose register resource requirement, and / or Add the value of the corresponding third counter register to the number of vector general-purpose register resources required.

10. The resource allocation method according to claim 9, wherein, When, among the plurality of execution units, there exists an execution unit with a number of available register logic sub-blocks that meet the requirements of the corresponding thread bundle task, after allocating the corresponding register logic sub-block in that execution unit to the corresponding thread bundle task, the resource allocation method further includes: After the workgroup task is completed, the memory logical sub-block it occupies is released; Remove the mapping relationship between the virtual shared memory slot number to be used by the workgroup task and the slot number of the allocated memory logical sub-block in the first mapping table; Add the value of the first counter register to the number of shared memory resources required.

11. The resource allocation method according to claim 1, wherein, The shared memory includes memory cells arranged in an array, the physical storage addresses of the memory cells are continuous in the row direction and connected end to end in the row direction, the memory cells are divided into multiple storage banks in the column direction, and the memory logical sub-block includes multiple consecutive rows of memory cells located in the multiple storage banks.

12. The resource allocation method according to claim 1, wherein, The general-purpose register includes register cells arranged in an array. The physical storage addresses of the register cells are continuous in the row direction and are connected end to end in the row direction. The register cells are divided into multiple memory banks in the column direction. The register logic sub-block includes multiple consecutive rows of register cells located in the multiple memory banks.

13. A resource allocation device for a computing unit of a graphics processor, the computing unit comprising: The system includes multiple execution units and shared memory. Each execution unit includes a general-purpose register, which in turn includes multiple register logic sub-blocks. The shared memory includes multiple memory logic sub-blocks. A resource allocation device is integrated into the computing unit. The resource allocation device includes: The storage requirement information acquisition unit is used to acquire the storage requirement information of the workgroup task to be executed. The storage requirement information includes the number of shared memory resources required by the workgroup task and the number of general-purpose register resources required by multiple thread bundle tasks in the workgroup task. The available memory determination unit is used to determine whether the number of available memory logical sub-blocks in the shared memory meets the requirements of the workgroup task based on the quantity of shared memory resource demand. A memory allocation unit is configured to allocate corresponding memory logical sub-blocks to the workgroup task, provided that the number of available memory logical sub-blocks in the shared memory meets the needs of the workgroup task. The available register determination unit is used to determine, for each thread bundle task in the workgroup task, whether there is an execution unit among the multiple execution units whose number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task, based on the number of general register resource requirements of the corresponding thread bundle task. The register allocation unit is used to allocate the corresponding register logic sub-block in the execution unit to the corresponding thread bundle task when there is an execution unit in which the number of available register logic sub-blocks meets the requirements of the corresponding thread bundle task.

14. An electronic device comprising a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for enabling communication between the processor and the memory, wherein the program is executed by the processor to implement the resource allocation method as described in any one of claims 1 to 12.

15. A computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement the resource allocation method as described in any one of claims 1 to 12.

Images