Graphics processor and computer equipment

Abstract

The invention discloses a graphics processing unit and computer equipment, the graphics processing unit comprises at least two chip bare bands, each chip bare band comprises a front-end scheduling system, a routing broadcast module and at least two GPU cores, and the front-end scheduling system comprises a scheduling control module and at least two CPU cores. Wherein the scheduling control module of the first chip bare band is configured to receive a task event corresponding to a target task and notify at least one target CPU core to schedule the task event; the routing broadcast module of the second chip bare band is configured to route the task event to at least one target GPU core or route the task event to at least one target CPU core; wherein the at least one target GPU core is a GPU core used for processing the target task in all GPU cores of the graphics processor; the at least one target CPU core is a CPU core having an association relationship with the at least one target GPU core in all CPU cores of the graphics processor.

Description

Technical Field

[0001] This application relates to the field of graphics processing technology, and more particularly to a graphics processor and computer device. Background Technology

[0002] In the field of computer graphics processing, with the increasing complexity of application scenarios and the exponential growth of data processing demands, the performance optimization and resource management of Graphics Processing Units (GPUs) have become crucial for improving overall system efficiency. Traditional single-chip GPUs, when faced with high-concurrency, large-scale computing tasks, are limited by factors such as physical space, power consumption, and heat dissipation, making it difficult to achieve a linear performance increase simply by expanding the number of cores. Therefore, multi-chip die integration technology has gradually become the mainstream solution. This technology integrates multiple functionally independent chip dies into the same package or system, enabling distributed deployment and collaborative operation of computing resources. How to effectively allocate and process tasks within a multi-chip die GPU has become a significant issue. Summary of the Invention

[0003] In view of this, embodiments of this application provide at least one graphics processor and computer device.

[0004] The technical solution of this application embodiment is implemented as follows: On one hand, embodiments of this application provide a graphics processor. The graphics processor includes at least two bare chip bands, each bare chip band including a front-end scheduling system, a routing broadcast module, and at least two GPU cores. The front-end scheduling system includes a scheduling control module and at least two CPU cores, wherein: the scheduling control module of a first bare chip band is configured to receive a task event corresponding to a target task and notify at least one target CPU core to schedule the task event; the first bare chip band is the bare chip band among the at least two bare chip bands used for scheduling the target task; the routing broadcast module of a second bare chip band is configured to route the task event to at least one target GPU core, or route the task event to the at least one target CPU core; the second bare chip band is the bare chip band where the target CPU core is located among the at least two bare chip bands; wherein the at least one target GPU core is the GPU core among all GPU cores of the graphics processor used for processing the target task; the at least one target CPU core is the CPU core among all CPU cores of the graphics processor that has an association with the at least one target GPU core.

[0005] On the other hand, embodiments of this application provide a computer device including the aforementioned graphics processor.

[0006] Based on the embodiments disclosed in this application, the front-end scheduling processor, leveraging the cross-die and intra-die transmission functions of the routing broadcast module, can not only call CPU and GPU cores within its own die, but also CPU and GPU cores in other dies, greatly expanding the scope of resource access. In task scheduling event processing, it can fully utilize multi-die resources to achieve efficient task allocation and parallel processing; during execution feedback event processing, it can also achieve cross-die information feedback and monitoring. Based on the dynamically configured association between CPU and GPU cores, it can better adapt to different task requirements. The overall solution improves the scheduling efficiency, processing speed, and resource utilization of the graphics processor, enhancing its overall performance.

[0007] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0008] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0009] Figure 1A This application provides a schematic diagram of the structure of a symmetric multi-core full-featured graphics processor. Figure 1B This is a schematic diagram of a GPU core grouping provided in an embodiment of this application; Figure 1C A schematic diagram of a front-end scheduling system provided in an embodiment of this application; Figure 1D A schematic diagram of a graphics processor comprising two identical bare chip bands, provided for an embodiment of this application; Figure 2 A schematic diagram of a graphics processor including a routing broadcast module provided for an embodiment of this application; Figure 3 A schematic diagram of a graphics processor including bare chip bands interconnected via a routing broadcast module, provided for an embodiment of this application; Figure 4 A schematic diagram illustrating the mapping relationship between physical identifiers and logical identifiers provided in an embodiment of this application; Figure 5 A schematic diagram of a task scheduling scenario provided in this application embodiment; Figure 6 This application provides an illustration of a task scheduling scenario. Figure 2 . Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0011] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0012] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0013] Graphics processors (GPUs), as high-performance parallel computing devices, are widely used in data centers, artificial intelligence, and graphics rendering. With the ever-increasing demand for computing power, modern GPUs typically employ a multi-core architecture and integrate multiple bare chips (dies) through advanced packaging technologies to achieve higher performance and scalability. In this architecture, the front-end scheduling system is responsible for task allocation and resource management, while the routing and broadcasting module handles task distribution and communication between different processing units.

[0014] In related technologies, the front-end scheduling processor is moved out of the GPU core and replaced by a multi-core front-end scheduling system composed of multiple symmetric CPU cores and a scheduling control module, thereby achieving dynamic scheduling of the GPU core and its subsystems. Simultaneously, multiple graphics processor dies can work collaboratively through shared memory and interconnect mechanisms, presenting themselves as a unified GPU functional module from the host side. This solution improves overall utilization through flexible task scheduling capabilities, but its scheduling logic and routing mechanism still have room for optimization.

[0015] However, existing technologies lack a more granular correlation mechanism between the front-end scheduling system and the routing broadcast module, making it difficult to efficiently match task events to associated CPU and GPU cores. This is especially true in cross-chip bare-band scenarios, where the accuracy and timeliness of task scheduling are limited, impacting overall processing efficiency and resource utilization.

[0016] Please see Figure 1AThe following diagram illustrates the architecture of a symmetric multi-core full-featured graphics processor: Modern graphics processing units (GPUs) are complex multi-core systems, with each GPU core (GPU CORE) having the same functional modules. Figure 1A The system shown is an 8-core GPU system, with each GPU core containing a front-end scheduling processor and multiple other subsystems (including, but not limited to, a graphics subsystem, a computing subsystem, a 2D subsystem, and other subsystems such as video, DMA-engine, etc.).

[0017] The front-end scheduling processor is part of the GPU core and consists of one or more CPU cores and a scheduling control module. The CPU core in the front-end scheduling processor is responsible for running firmware processing programs and configuring its own GPU core or other GPU cores. The scheduling control module is responsible for receiving tasks sent by the main processor and events sent by its own GPU core or other GPU cores, and then triggering the CPU core to process them.

[0018] The operation involves the host processor sending tasks to the front-end scheduling processor (FPS) within the GPU cores via the operating system. The FPS scheduler then schedules the task to the current GPU core or another GPU core, coordinates its processing, and returns the completion status to the host processor. The GPU core receiving the task is called the primary core, and the cores that work with the primary core to complete the task are called secondary cores. The primary and secondary cores cooperate to complete the tasks sent by the application. At least one primary core is required in the configuration to receive tasks. A primary core and its corresponding secondary core form a group. Each core can be configured as a primary core (each GPU core can receive tasks from the host processor), or one core can be configured as a primary core while the others are all secondary cores (only one GPU core receives tasks), or the cores can be configured into several groups to receive different tasks (one GPU core in each group receives tasks). In the primary-secondary core operation, the host core's FPS sends tasks to the secondary cores via a configuration bus. After completion, the secondary core returns the results (including events) to the host core via the configuration bus.

[0019] Please see Figure 1B , Figure 1B This is a schematic diagram of GPU core grouping provided in an embodiment of this application. For the graphics subsystem, the GPU cores are divided into two groups. GPU core 0 is a single group, which is the first group, and GPU cores 1 to 7 are a second group. In the second group, the front-end scheduling processor of GPU core 1 is responsible for receiving tasks and scheduling the other 7 GPU cores.

[0020] It can be seen that the above Figure 1AThe provided embodiments have the following drawbacks: (1) All GPU cores on the symmetric multi-core image processor have the same function, and there is no master-slave division in terms of function. They are divided into master cores and slave cores according to the scheduling function of the front-end scheduling processor. Only the front-end scheduling processor in the master core works. Such a configuration has a large granularity. Each GPU core has a front-end scheduling processor, which not only wastes resources, but also cannot give full play to the performance of the front-end scheduling processor in most scenarios. For example, in Figure 1B In the second group introduced in the article, only the front-end scheduling processor in GPU core 1 (main core) is working, while the front-end scheduling processors in other cores are idle; (2) The configuration flexibility is not high. The front-end scheduling processor and the GPU core are one-to-one, while the CPU core inside the front-end scheduling processor is fixed and lacks scalability.

[0021] Based on this, the embodiments of this application provide another front-end scheduling system, please refer to... Figure 1C The front-side scheduling processor is removed from the GPU core, and a front-side scheduling system (front-side scheduling multi-core processor system) 910 is added outside the GPU core. The front-side scheduling system 910 consists of multiple symmetric CPU cores 911 (such as...). Figure 1C It consists of CPUs #0 to #11 and a scheduling control module 912. The number of CPU cores is adapted according to the scheduling load (there is no strict correspondence with the number of GPU cores). Figure 1C The number of CPU processors is 12. Dynamic configuration is performed in two dimensions: the dimension of GPU cores and the dimension of subsystems within GPU cores. Multiple CPU processors can be configured to schedule a single GPU core, or multiple CPU processors can be configured to schedule the same subsystem within multiple GPU cores. There are no physical restrictions on the correspondence between CPU cores and GPU cores.

[0022] As data centers and other applications demand ever-increasing computing power, multiple identical bare-chip dies are being packaged using advanced technology to share storage, achieving computing power many times greater than a single chip. From the host's (main processor's) perspective, this constitutes a GPU function. Each GPU die has an independent front-end, and the front-end scheduling processors (including CPU cores, other sub-modules, and scheduling control modules) are interconnected to logically achieve the functionality of a single GPU. Please refer to [link to relevant documentation]. Figure 1D The two scenes shown are encapsulated in dies. Figure 1D This is a schematic diagram of a graphics processor comprising two identical bare chip bands, provided as an embodiment of this application.

[0023] Traditionally, a single die is packaged into a chip and soldered onto the motherboard, with communication between dies occurring via traces on the motherboard. This method is slow, has high latency, and consumes a lot of power, becoming a bottleneck for performance improvement (known as the "memory wall" or "interconnect wall"). The advanced packaging technology in this application allows multiple dies to be connected within the package at extremely close distances using extremely high-bandwidth lines (with a density far exceeding that of the motherboard wiring). Thus, communication speed between dies is as fast as if they were within the same die, with extremely low latency and lower power consumption.

[0024] Experimental research revealed the following problems with the above scheme: (1) Each front-end scheduling processor on a die essentially controls the chip on its own die. Therefore, multiple front-end scheduling processors need to handle a lot of communication to realize the function of a single logical GPU. For example, a logical GPU needs to split the task through the front-end scheduling processor, distribute and schedule the task after splitting, and finally wait for the task to be completed before synchronizing and finally merging back to the host. The actual situation is even more complicated. This not only increases the task difficulty of the front-end scheduling processor, but also results in efficiency loss.

[0025] (2) If more dies need to be combined together, each front-end scheduling processor handles all the scheduling functions of its own die chip, and cannot allocate the scheduling computing power as needed. For example, the front-end scheduling processor of Die0 implements the scheduling of all computing subsystem functions, and the front-end scheduling processor of Die1 implements the scheduling of all graphics subsystems. Such scheduling requirements are difficult to meet.

[0026] Based on this, embodiments of this application provide a graphics processor. Figure 2 This is an optional structural diagram of the graphics processor provided in the embodiments of this application. The following will be combined with... Figure 2 The structure within is explained. For example... Figure 2 As shown, the graphics processor includes two bare chip bands ( Figure 2 The image exemplarily shows chip bare band 21 and chip bare band 22, each of which includes a front-end scheduling system, a routing broadcast module, and at least two GPU cores. Figure 2 The example illustrates n+1 GPU cores, such as GPU core 2110 to GPU core 211n. The front-end scheduling system may include a scheduling control module and at least two CPU cores (…). Figure 2 The example illustrates n+1 CPU cores, such as CPU core 2120 to CPU core 212n. Through the routing broadcast module, the front-end scheduling system can flexibly route task events to any target GPU core or target CPU core, thereby achieving unified scheduling and management of all GPU cores of the graphics processor.

[0027] The scheduling control module of the first chip bare tape is configured to receive a task event corresponding to the target task and notify at least one target CPU core to schedule the task event; the first chip bare tape is the chip bare tape used to schedule the target task among the at least two chip bare tapes; The routing broadcast module of the second chip bare band is configured to route the task event to at least one target GPU core, or to the at least one target CPU core; the second chip bare band is the chip bare band where the target CPU core is located among at least two chip bare bands; Wherein, the at least one target GPU core is the GPU core used to process the target task among all GPU cores of the graphics processor; the at least one target CPU core is the CPU core that is associated with the at least one target GPU core among all CPU cores of the graphics processor.

[0028] In some embodiments, the task event includes at least one of the following: task scheduling event and execution feedback event.

[0029] In some possible implementations, when the task event is a task scheduling event, the main processor sends the task scheduling event to a first chip bareband. Here, the first chip bareband is one of at least two chip barebands used for scheduling the target task. The scheduling control module in the first chip bareband determines at least one target CPU core for scheduling the target task from all CPU cores in the graphics processor and sends the task scheduling event to at least one target CPU core in the second chip bareband. The at least one target CPU core sends the task scheduling event to at least one target GPU core through the routing broadcast module of the second chip bareband; subsequently, the at least one target GPU core processes the target task.

[0030] In some embodiments, the routing broadcast module of the second chip bare band can send the task scheduling event to the at least one target GPU core through cross-die transmission, or the routing broadcast module of the second chip bare band can send the task scheduling event to the at least one target GPU core through intra-die transmission.

[0031] It is understood that the chip bare tape used to schedule the target task (i.e., the first chip bare tape) and the chip bare tape where the at least one target CPU core is located (i.e., the second chip bare tape) can be the same chip bare tape or different chip bare tapes. Here, since the first chip bare tape that receives the task scheduling event is the chip bare tape that schedules the target task, the scheduling control module in the first chip bare tape is also used to schedule the target task.

[0032] In some embodiments, the at least one target GPU core is a GPU core among all GPU cores in the graphics processor used to process the target task. The scheduling control module of the first chip bare-band is configured to receive a target task sent by the main processor, which is pre-configured to be processed by at least one target GPU core among all GPU cores in the graphics processor. Furthermore, the scheduling control module of the first chip bare-band can, based on the association between CPU cores and GPU cores, determine at least one target CPU core corresponding to at least one target GPU core among at least two CPU cores, and then notify the at least one target CPU core to schedule the target task.

[0033] Therefore, when the task event is a task scheduling event, the routing broadcast module of the second chip bare band is configured to receive a task scheduling event sent by at least one target CPU core, the task scheduling event being used to instruct a target GPU core to process all or part of the target task; the routing broadcast module of the second chip bare band is also configured to send the task scheduling event to the at least one target GPU core; the at least one target GPU core is configured to process all or part of the target task in response to the task scheduling event.

[0034] In some possible implementations, when the task event is an execution feedback event, the execution feedback event is an event generated after the target GPU core executes all or part of the target task, used to characterize the execution status of all or part of the target task. When the task event is an execution feedback event, the target GPU core reports the execution feedback event to the scheduling control module of the first chip bare band used to schedule the target task; the scheduling control module of the first chip bare band used to schedule the target task reports the execution feedback event to the at least one target CPU core; and the at least one target CPU core, in response to the execution feedback event, reports the execution result of the target task to the main processor.

[0035] In some embodiments, during the above process, the scheduling control module of the first chip bare band and the target CPU core may or may not be located in the same chip bare band. In some embodiments, during the above process, the scheduling control module of the first chip bare band and the target GPU core may or may not be located in the same chip bare band.

[0036] In some possible implementations, the routing broadcast module of the second chip bare band is configured to receive execution feedback events reported by the target GPU core via intra-die transmission, or the routing broadcast module of the second chip bare band is configured to receive execution feedback events reported by the target GPU core via inter-die transmission.

[0037] In some possible implementations, the scheduling control module of the first chip bare band is configured to report the execution feedback event to at least one target CPU core in the first chip bare band.

[0038] In some embodiments, the association between the CPU cores and GPU cores described above is dynamically configured based on the dimensions of the GPU cores and / or the subsystems within the GPU cores. That is, for a target task, at least one target GPU core can be determined from among multiple GPU cores based on the GPU cores and / or the subsystems within the GPU cores that process the target task. Furthermore, based on the scheduling load of the target task, at least one target CPU core can be determined from at least two CPU cores. This establishes an association between the at least one target CPU core and the at least one target GPU core, thereby obtaining the associations corresponding to all tasks.

[0039] In some embodiments, the scheduling load here may be the computing resources occupied by the CPU core for processing the issuance of task scheduling events and the computing resources occupied by the CPU core for processing the reporting of execution feedback events. In some embodiments, the CPU core with remaining computing resources that meet the scheduling load can be selected from all CPU cores as the target CPU core.

[0040] In some embodiments, when the association is configured based on the dimension of GPU core subsystems, all GPU cores are target GPU cores, and the target subsystem in each target GPU core is used to process the target task, wherein the target task and the target subsystem have the same service type. When the association is configured based on the dimensions of GPU core subsystems and GPU cores, at least one GPU core among all GPU cores is the target GPU core, and the target subsystem in each target GPU core is used to process the target task, wherein the target task and the target subsystem have the same service type.

[0041] If the association between CPU cores and GPU cores is dynamically configured based on the dimension of subsystems within GPU cores, then when the target task is processed through the target subsystem, all GPU cores can be identified as target GPU cores. For example, if the business type of the target task is graphics processing, and it is processed through a graphics subsystem with the same business type, then each GPU core includes the graphics subsystem, and therefore all GPU cores are identified as target GPU cores. Accordingly, the association includes the association between at least one target CPU core and all GPU cores.

[0042] If the relationship between CPU cores and GPU cores is dynamically configured based on the GPU core dimension, then the GPU core that processes the target task can be directly identified as the target GPU core.

[0043] If the relationship between CPU cores and GPU cores is dynamically configured based on the GPU core and its subsystems, then when the target task is processed through the target subsystem of the target GPU core, the target GPU core can be all of all GPU cores or only a part of them.

[0044] Based on the embodiments disclosed in this application, the front-end scheduling processor, leveraging the cross-die and intra-die transmission functions of the routing broadcast module, can not only call CPU and GPU cores within its own die, but also CPU and GPU cores in other dies, greatly expanding the scope of resource access. In task scheduling event processing, it can fully utilize multi-die resources to achieve efficient task allocation and parallel processing; during execution feedback event processing, it can also achieve cross-die information feedback and monitoring. Based on the dynamically configured CPU and GPU core relationships, it can better adapt to different task requirements. The overall solution improves the scheduling efficiency, processing speed, and resource utilization of the graphics processor, enhancing its overall performance.

[0045] In some embodiments, the scheduling control module may call CPU cores within the same chip bare band, or CPU cores within different chip bare bands. The at least one target CPU core includes one or more of the following: a first CPU core located in the first chip bare band; a second CPU core not located in the first chip bare band.

[0046] In some possible implementations, the at least one target CPU core includes a first CPU core located in the first chip bare tape. That is, the scheduling control module of the first chip bare tape (also referred to as the second chip bare tape) is configured to receive a task event corresponding to the target task and notify the first CPU core in the first chip bare tape to schedule the task event.

[0047] For example, please refer to Figure 2Assuming that chip bare band 21 is the first chip bare band used for scheduling the target task, and the target CPU core can be CPU core 2120 in chip bare band 21, it can be seen that the second chip bare band (chip bare band 21) where CPU core 2120 is located is the same as the first chip bare band (chip bare band 21). At this time, the scheduling control module in chip bare band 21 can receive the task event corresponding to the target task and directly notify CPU core 2120 in the same die.

[0048] In some other possible implementations, the at least one target CPU core includes a second CPU core not located in the first chip's bare bandgap. That is, the scheduling control module of the first chip's bare bandgap is configured to receive a task event corresponding to the target task and notify the second CPU core not located in the first chip's bare bandgap to schedule the task event.

[0049] For example, please refer to Figure 2 Assuming chip bare band 21 is the chip bare band used for scheduling the target task, i.e., the first chip bare band, and the target CPU core can be CPU core 2220 in chip bare band 22, it can be seen that the second chip bare band (chip bare band 22) where CPU core 2220 is located is different from the first chip bare band (chip bare band 21) used for scheduling the target task. At this time, the scheduling control module in chip bare band 21 can receive the task event corresponding to the target task and directly notify the CPU core 2220 in different dies.

[0050] In some other possible implementations, the at least one target CPU core simultaneously includes a first CPU core located in the first chip bare band and a second CPU core not located in the first chip bare band. That is, the scheduling control module of the first chip bare band is configured to receive the task event corresponding to the target task and notify the first CPU core located in the first chip bare band and the second CPU core not located in the first chip bare band.

[0051] For example, please refer to Figure 2 Assuming chip bare tape 21 is the chip bare tape used to process the target task, i.e., the first chip bare tape, the target CPU core may include CPU core 2120 in chip bare tape 21 and CPU core 2220 in chip bare tape 22. At this time, the scheduling control module in chip bare tape 21 can receive the task event corresponding to the target task and notify CPU core 2120 in the die and CPU core 2220 in different dies.

[0052] Based on the embodiments disclosed in this application, the design of calling CPU cores within the same chip bare band and within different chip bare bands through the scheduling control module enables more flexible allocation of task scheduling resources. When processing a target task, the appropriate CPU core (within the same die or different dies) can be selected to schedule the task according to the actual situation, improving the flexibility of resource utilization. Based on the embodiments provided in this application, the resource calling restrictions between chip bare bands can be broken, enabling cross-die CPU core calling, further tapping the resource potential of multi-chip bare bands in the graphics processor, and improving the overall task scheduling capability and processing efficiency.

[0053] In some embodiments, the front-end scheduling system can schedule GPU cores on the same die or GPU cores on different dies. The at least one target GPU core includes one or more of the following: a first GPU core in a second chip bareband; a second GPU core in a third chip bareband; wherein the third chip bareband is a chip bareband different from the second chip bareband among all the chip barebands of the graphics processor.

[0054] In some possible implementations, the at least one target GPU core includes a first GPU core within the second chip's bare bandgap. That is, the routing broadcast module of the second chip's bare bandgap is configured to route the task event to the first GPU core within the second chip's bare bandgap. In this case, since the routing broadcast module and the first GPU core are located within the same die, the task event can be routed to the first GPU core via intra-die transmission.

[0055] For example, please refer to Figure 2 Assuming the target CPU core is located in chip bare band 21, i.e. chip bare band 21 is the second chip bare band, the target GPU core can be GPU core 2110 and GPU core 2111 in chip bare band 21. It can be seen that the routing broadcast module of chip bare band 21 is configured to directly route the task event to GPU core 2110 and GPU core 2111 in chip bare band 21 through die transmission.

[0056] In some possible implementations, the at least one target GPU core includes a second GPU core within a third chip dies, wherein the third chip dies is a different chip dies from the second chip dies among all the chip dies of the graphics processor. That is, the routing broadcast module of the second chip dies is configured to route the task event to the second GPU core within the third chip dies. In this case, since the routing broadcast module and the second GPU core are located in different dies, the task event can be routed to the second GPU core via cross-die transmission.

[0057] In this embodiment, different chip bare bands can be interconnected through routing broadcast modules in each chip bare band. Therefore, the above-mentioned routing of task events to the second GPU core via cross-die transmission can include: the routing broadcast module in the second chip bare band routing the task events to the routing broadcast module in the third chip bare band via cross-die transmission; and the routing broadcast module in the third chip bare band routing the task events to the target GPU core via intra-die transmission.

[0058] For example, please refer to Figure 2 Assuming the target CPU core is located in chip bare band 21, i.e., chip bare band 21 is the second chip bare band, the target GPU core can be GPU core 2210 and GPU core 2211 in chip bare band 22. It can be seen that the routing broadcast module of chip bare band 21 is configured to route the task event to the routing broadcast module in chip bare band 22 through cross-die transmission; correspondingly, the routing broadcast module in chip bare band 22 is configured to directly route the task event to GPU core 2210 and GPU core 2211 in chip bare band 22 through intra-die transmission.

[0059] In some possible implementations, the at least one target GPU core includes the aforementioned first GPU core and second GPU core. That is, the routing broadcast module of the second chip bare band is configured to route the task event to both the first GPU core in the second chip bare band and the second GPU core in the third chip bare band. In this case, since the routing broadcast module and the first GPU core are in the same die, and the routing broadcast module and the second GPU core are in different dies, the task event can be routed to the first GPU core via intra-die transmission and to the second GPU core via cross-die transmission.

[0060] For example, please refer to Figure 2Assuming the target CPU core is located in chip bareband 21, i.e., chip bareband 21 is the second chip bareband, the target GPU core may include GPU core 2110 and GPU core 2111 in chip bareband 21 and GPU core 2210 and GPU core 2211 in chip bareband 22. It can be seen that the routing broadcast module of chip bareband 21 is configured to directly route the task event to GPU core 2110 and GPU core 2111 in chip bareband 21 via intra-die transmission; and the routing broadcast module of chip bareband 21 is configured to route the task event to the routing broadcast module in chip bareband 22 via cross-die transmission; correspondingly, the routing broadcast module in chip bareband 22 is configured to directly route the task event to GPU core 2210 and GPU core 2211 in chip bareband 22 via intra-die transmission.

[0061] Based on the embodiments disclosed in this application, the front-end scheduling system can schedule GPU cores on the same die and different dies, enabling more extensive allocation of graphics processing resources. It can flexibly select the appropriate GPU cores on the die to participate in processing according to task requirements, thereby improving the diversity of resource utilization. Based on the embodiments provided in this application, efficient scheduling and task allocation of GPU cores on multiple dies in a graphics processor can be achieved, giving full play to the computing power of multiple chip bare bands and improving the overall performance and efficiency of graphics processing.

[0062] In some embodiments, the task event includes a task scheduling event; wherein the routing broadcast module of the second chip bare band is configured to route the task scheduling event to a first GPU core in the second chip bare band; and / or, the routing broadcast module of the second chip bare band is configured to route the task scheduling event to the routing broadcast module of the third chip bare band; the routing broadcast module of the third chip bare band is configured to route the task scheduling event to a second GPU core in the third chip bare band.

[0063] Here, from the perspective of the second chip bare band, when the task event is a task scheduling event, the task scheduling event can be routed to the first GPU core in the second chip bare band by the routing broadcast module of the second chip bare band through intra-die transmission; the task scheduling event can also be routed to the second GPU core in the third chip bare band by the routing broadcast module of the second chip bare band through cross-die transmission.

[0064] For example, please continue to refer to Figure 2Assuming the second chip bare band is chip bare band 21, at least one target GPU includes GPU core 2110, GPU core 2111, GPU core 2210, and GPU core 2211. Here, the first GPU core includes GPU core 2110 and GPU core 2111; the second GPU core includes GPU core 2210 and GPU core 2211. Therefore, the routing broadcast module of chip bare band 21 is configured to route the task scheduling event to GPU core 2110 and GPU core 2111 of chip bare band 21; the routing broadcast module of chip bare band 21 is configured to route the task scheduling event to the routing broadcast module of chip bare band 22; the routing broadcast module of chip bare band 22 is configured to route the task scheduling event to GPU core 2210 and GPU core 2211 of chip bare band 22.

[0065] Based on the embodiments provided in this application, task scheduling events can be routed to appropriate GPU cores by flexibly selecting intra-die or cross-die transmission methods according to actual needs, which helps to improve the flexibility of task scheduling and the resource utilization of the graphics processor.

[0066] In some embodiments, the task event includes an execution feedback event; wherein, the routing broadcast module of the second chip bare band is configured to receive an execution feedback event reported by a first GPU core in the second chip bare band; and / or, the routing broadcast module of the second chip bare band is configured to receive an execution feedback event sent by the routing broadcast module of the third chip bare band; the routing broadcast module of the third chip bare band is configured to receive an execution feedback event reported by a second GPU core in the third chip bare band.

[0067] From the perspective of the second chip bare band, when the task event is an execution feedback event, the execution feedback event can be reported by the first GPU core in the second chip bare band to the routing broadcast module of the second chip bare band via intra-die transmission; the execution feedback event can also be reported by the second GPU core in the third chip bare band to the routing broadcast module of the third chip bare band via intra-die transmission, and the routing broadcast module of the third chip bare band will then report the execution feedback event to the routing broadcast module of the second chip bare band via cross-die transmission.

[0068] For example, please continue to refer to Figure 2Assuming the second bare chip is bare chip 21, at least one target GPU includes GPU core 2110, GPU core 2111, GPU core 2210, and GPU core 2211. Here, the first GPU core includes GPU core 2110 and GPU core 2111; the second GPU core includes GPU core 2210 and GPU core 2211. Therefore, the routing broadcast module of bare chip 21 is configured to receive execution feedback events reported by GPU cores 2110 and 2111 in bare chip 21; the routing broadcast module of bare chip 21 is configured to receive execution feedback events sent by the routing broadcast module of bare chip 22; the routing broadcast module of bare chip 22 is configured to receive execution feedback events reported by GPU cores 2210 and 2211 in bare chip 22.

[0069] Based on the embodiments provided in this application, execution feedback events of GPU cores on different chip bare bands can be collected comprehensively, which helps to monitor and manage the overall task execution status in a multi-chip bare band system and improve the collaborative working ability and task processing efficiency of the graphics processor.

[0070] In some embodiments, the routing broadcast module is provided with a first mapping configuration, which is used to determine the mapping relationship between the logical identifier of the GPU core and the physical identifier of the GPU core; wherein, the routing broadcast module of the second chip bare band is configured to, when the task event is a task scheduling event, determine the logical identifier of the target GPU core based on the physical identifier of the target GPU core carried in the task scheduling event and the first mapping configuration; and route the task scheduling event to the target GPU core based on the logical identifier of the target GPU core.

[0071] The physical identifier of a GPU core uniquely identifies its actual location and number at the hardware level. It is determined through hardware circuitry and address allocation, and in multi-die scenarios, it also includes the die's identifier information, ensuring uniqueness and determinism. The logical identifier of a GPU core is a software-defined identifier for easy management and task allocation. It corresponds to the physical identifier and is used in multi-die scenarios to uniformly manage and schedule GPU cores across different dies. The first mapping configuration establishes the correspondence between the physical and logical identifiers of the GPU cores. This configuration allows for accurate conversion between the logical and physical layers, enabling effective task allocation and management. In multi-die scenarios, it covers the mapping relationships of GPU cores across different dies.

[0072] In this embodiment, since the GPU cores of this graphics processor are uniformly managed and scheduled, when faced with GPU cores in at least two chip bare bands, this embodiment carries the physical identifier of the target GPU core in the task scheduling event and combines it with a pre-set first mapping configuration. The first mapping configuration clarifies the correspondence between the physical identifier and the logical identifier, so that the corresponding logical identifier can be found according to the physical identifier, and then the task scheduling event can be accurately routed to the target GPU core according to the logical identifier, thereby achieving precise task allocation.

[0073] In some embodiments, when the routing broadcast module of the second chip bare band receives a task scheduling event, it first extracts the physical identifier of the target GPU core carried in the event, then queries the pre-stored first mapping configuration, searches for the logical identifier corresponding to the physical identifier in the first mapping configuration, and after finding the logical identifier of the target GPU core, the routing broadcast module accurately sends the task scheduling event to the target GPU core with the logical identifier according to the pre-set routing rules and paths based on the logical identifier, thus completing the task allocation process.

[0074] For example, suppose Figure 2 Each chip in the process has 4 bare GPU cores. The first mapping configuration mentioned above can include: GPU core 2110 has a physical identifier of "Die0_PHY_001" and a corresponding logical identifier of "LOGIC_001", ...; GPU core 2113 has a physical identifier of "Die0_PHY_004" and a corresponding logical identifier of "LOGIC_004"; GPU core 2210 has a physical identifier of "Die1_PHY_001" and a corresponding logical identifier of "LOGIC_005", ...; GPU core 2213 has a physical identifier of "Die1_PHY_004" and a corresponding logical identifier of "LOGIC_008". When the routing broadcast module of the second chip receives a task scheduling event, the target GPU core physical identifier carried in the event is "Die0_PHY_001". After extracting the physical identifier, the routing broadcast module queries the first mapping configuration to find the corresponding logical identifier "LOGIC_001". Based on this logical identifier, it routes the task scheduling event to GPU core 2110 with the identifier "LOGIC_001", causing it to begin executing the corresponding task. When the target GPU core physical identifier carried in the task scheduling event is "Die1_PHY_001", the routing broadcast module extracts this physical identifier, queries the first mapping configuration to find the corresponding logical identifier "LOGIC_005", and then routes the task scheduling event to GPU core 2210 with the identifier "LOGIC_005", causing it to begin executing the corresponding task.

[0075] In some embodiments, the routing broadcast module of the second chip bare band is configured to, when the task event is an execution feedback event, determine the physical identifier of the target GPU core based on the logical identifier of the target GPU core carried in the execution feedback event and the first mapping configuration; and route the execution feedback event to a target CPU core that is associated with the target GPU core.

[0076] In this embodiment, since the GPU cores of this graphics processor are uniformly managed and scheduled, when facing GPU cores in at least two chip bare bands, this embodiment utilizes the logical identifier of the target GPU core carried in the execution feedback event, combined with a pre-set first mapping configuration. This first mapping configuration clarifies the correspondence between the logical identifier and the physical identifier, thereby enabling the corresponding physical identifier to be found based on the logical identifier. Then, the execution feedback event is routed to the target CPU core that is associated with the target GPU core, thus achieving accurate transmission of feedback information.

[0077] In some embodiments, when the routing broadcast module of the second chip bare band receives an execution feedback event, it first extracts the logical identifier of the target GPU core from the execution feedback event, then queries the pre-stored first mapping configuration, finds the physical identifier corresponding to the logical identifier in the first mapping configuration, determines the physical identifier of the target GPU core, determines the target CPU core that is associated with the target GPU core, and the routing broadcast module accurately sends the execution feedback event to the target CPU core according to the routing rules and path.

[0078] For example, continuing with the above example, assume that the GPU core of chip bare band 21 is associated with the CPU core 2120 of chip bare band 21, and the GPU core of chip bare band 22 is associated with the CPU core 2121 of chip bare band 21. When the GPU core 2212 of chip bare band 22 completes a computing task, it generates an execution feedback event, which carries the logical identifier "LOGIC_007" of GPU core 2212. After receiving this execution feedback event, the routing broadcast module of the second chip bare band extracts the logical identifier "LOGIC_007", queries the first mapping configuration to find the corresponding physical identifier "Die1_PHY_003", and then, based on the preset association relationship, determines that the target CPU core associated with GPU core 2212 is the CPU core 2121 of chip bare band 21. Finally, it routes the execution feedback event to the CPU core 2121 of chip bare band 21.

[0079] Based on the embodiments disclosed in this application, a mapping relationship between the logical identifier and the physical identifier of a GPU core is established by setting a first mapping configuration. In the case of a task scheduling event, the logical identifier can be determined by combining the physical identifier of the target GPU core carried in the task scheduling event with the configuration, thereby accurately routing the task scheduling event to the target GPU core. At the same time, in the case of an execution feedback event, the physical identifier is determined by combining the logical identifier of the target GPU core carried in the task scheduling event with the first mapping configuration, and then the execution feedback event is routed to the associated target CPU core. Based on the embodiments provided in this application, for GPU cores in at least two chip bare bands, accurate task allocation and accurate transmission of feedback information can be achieved, which helps to improve the performance and stability in multi-chip bare bands and GPU-CPU collaborative working mode, and can complete complex tasks more efficiently.

[0080] In multi-die scenarios, some GPU cores may be unavailable due to malfunctions or user commands being disabled. In some embodiments, the logical identifier in the first mapping configuration is the logical identifier of the available GPU cores in the graphics processor; the available GPU cores are some or all of all GPU cores in the graphics processor.

[0081] In this embodiment, in a graphics processor environment with multiple dies and dynamically changing available GPU cores, to achieve accurate task allocation and feedback information transmission, since available GPU cores may change due to malfunctions or user operations, leading to changes in the correspondence between their physical and logical identifiers, it is necessary to update the first mapping configuration to accurately reflect the correspondence between the logical and physical identifiers of the currently available GPU cores. This way, when receiving and scheduling tasks subsequently, the new first mapping configuration can accurately route tasks to available target GPU cores; and when transmitting feedback information, the first mapping configuration can accurately transmit execution feedback events to the associated available CPU cores, adapting to changes in available GPU cores.

[0082] The aforementioned logical identifier is a software-level identifier set for the available GPU cores in the graphics processing unit. This logical identifier facilitates the management and task allocation of GPU cores and has a one-to-one correspondence with the physical identifier of the GPU core.

[0083] In some embodiments, when the graphics processor initializes or detects a change in available GPU cores (such as a GPU core in a die malfunctioning or some GPU cores being disabled in response to a user command), the first mapping configuration is first updated. Specifically, all GPU cores in the graphics processor are traversed, and those in an available state are selected. A logical identifier-physical identifier mapping is then established for these available GPU cores, and this mapping is updated in the first mapping configuration. After the first mapping configuration is updated, when the routing broadcast module of the second chip's bare-chip receives a task event, if it is a task scheduling event, the physical identifier of the target GPU core carried in the task scheduling event is extracted, and the logical identifier corresponding to that physical identifier is searched in the updated first mapping configuration. The task scheduling event is then routed to the target GPU core based on the logical identifier. If it is an execution feedback event, the logical identifier of the target GPU core carried in the event is extracted, and the corresponding physical identifier is searched in the updated first mapping configuration to determine the target CPU core associated with that target GPU core. The execution feedback event is then routed to the target CPU core.

[0084] In some embodiments, the first mapping configuration satisfies at least one of the following conditions: the logical identifiers of the available GPU cores are consecutive, and it includes a preset minimum logical identifier. In some possible implementations, during the process of updating the first mapping configuration described above, the updated first mapping configuration needs to include P consecutive logical identifiers of GPU cores starting with the minimum logical identifier; where P is the number of available GPU cores.

[0085] For example, continue based on Figure 2 For example, each chip in the graphics processor originally has 4 GPU cores. After the graphics processor initializes, it detects a failure in one of the GPU cores in chip 21 (Die0), and updates the first mapping configuration. After the update, the logical identifiers of the remaining 3 available GPU cores in chip 21 are reassigned to consecutive "LOGIC_001", "LOGIC_002", and "LOGIC_003", while the physical identifiers remain unchanged; the logical identifiers of the 4 available GPU cores in chip 22 are updated to consecutive "LOGIC_004", "LOGIC_005", "LOGIC_006", and "LOGIC_007".

[0086] It should be noted that within the same chip bare tape, the mapping relationship between multiple logical identifiers and multiple physical identifiers can be arbitrarily set. For example, there may be "LOGIC_001", "LOGIC_002" and physical identifiers "Die1_PHY_003" and "Die1_PHY_004". "LOGIC_001" can be associated with "Die1_PHY_004", and "LOGIC_002" can be associated with "Die1_PHY_003". Alternatively, "LOGIC_001" can be associated with "Die1_PHY_003", and "LOGIC_002" can be associated with "Die1_PHY_004". Both of these mapping configurations can be applied to the embodiments of this application.

[0087] Based on the embodiments disclosed in this application, by traversing all GPU cores to filter out available GPU cores and establishing a logical identifier-physical identifier correspondence for them when the image processor initializes or detects a change in available GPU cores, and updating the first mapping configuration, the first mapping configuration can accurately reflect the identifier correspondence of the currently available GPU cores, providing an accurate basis for subsequent task allocation and feedback information transmission. Furthermore, by ensuring that the first mapping configuration meets conditions such as continuous logical identifiers of available GPU cores, including a preset minimum logical identifier, batch task allocation can be performed more efficiently based on continuous logical identifiers in task scheduling event scenarios, improving task allocation efficiency. In execution feedback event scenarios, continuous logical identifiers also make processing feedback information from multiple GPU cores more convenient, reducing feedback information transmission errors and improving the accuracy of information transmission. Based on the embodiments provided in this application, the efficiency and accuracy of task allocation and information transmission for the graphics processor in multi-die scenarios when the available GPU cores change dynamically can be improved.

[0088] In some embodiments, the routing broadcast module of any one of the at least two chip bare bands in the graphics processor is configured to receive the first mapping configuration and broadcast the first mapping configuration.

[0089] In this embodiment of the application, in order to achieve consistency in subsequent task allocation and feedback information transmission, it is necessary to ensure that each chip bare tape can obtain a unified and accurate first mapping configuration. Therefore, after any chip bare tape receives the first mapping configuration, the routing broadcast module of that chip bare tape broadcasts it to the routing broadcast module of each chip bare tape in the graphics processor, thereby achieving the unification of the first mapping configuration in the entire graphics processor.

[0090] In some embodiments, the main processor generates a first mapping configuration, which includes the correspondence between logical identifiers and physical identifiers of available GPU cores in the graphics processor. Then, the main processor sends this first mapping configuration to any one of the at least two chip bare bands in the graphics processor. After receiving the first mapping configuration, the routing broadcast module of any chip bare band sends the first mapping configuration to the routing broadcast module of each chip bare band in the graphics processor, so that the routing broadcast module of each chip bare band stores the same first mapping configuration.

[0091] In other embodiments, at least two bare-chip bands may have some GPU cores added or removed due to software-related reasons or malfunctions, thus updating the first mapping configuration to obtain a new first mapping configuration. The routing broadcast module of this bare-chip band sends the first mapping configuration to the routing broadcast module of each bare-chip band in the graphics processor, so that the routing broadcast module of each bare-chip band stores the same first mapping configuration.

[0092] Based on the above embodiments disclosed in this application, the first mapping configuration can be unified throughout the graphics processor, thereby improving the accuracy of task allocation and feedback information transmission of the graphics processor in a multi-chip bare-band environment.

[0093] In some embodiments, the scheduling control module in the second chip bare band is configured to receive a second mapping configuration issued by the main processor and determine at least one target CPU core corresponding to the target task; the second mapping configuration includes a logical identifier of the target GPU core that processes the target task; at least one target CPU core in the second chip bare band is configured to issue the second mapping configuration to each of the target GPU cores; the second mapping configuration is used to determine the sub-tasks that each of the target GPU cores needs to process in the target task.

[0094] In this context, a subtask is a task unit obtained by dividing the target task. When there are multiple target GPU cores, the target task is divided into multiple non-overlapping subtasks, and each target GPU core is responsible for processing one subtask to achieve parallel processing of tasks and improve task execution efficiency.

[0095] In some embodiments, after receiving a target task, each target GPU core may determine a subtask that it needs to process within the target task based on the second mapping configuration described above. The subtask may be part or all of the target task.

[0096] In some embodiments, when there are at least two target GPU cores, the subtasks of each target GPU core are obtained by dividing the target task, and the subtasks of different target GPU cores do not overlap. From the perspective of any target GPU core, after receiving the target task, any target GPU core can determine the subtasks that any target GPU core needs to process in the target task based on the logical identifiers of all target GPU cores processing the target task in the second mapping configuration, and the logical identifier of the target GPU core itself, according to a pre-agreed task division logic.

[0097] In some embodiments, the second configuration information may further include the association between the target GPU core and the target CPU core, i.e., configured through the main processor (software level). Of course, in other embodiments, the association between the target GPU core and the target CPU core is dynamically configured based on the dimensions of the GPU core and / or the dimensions of the subsystems within the GPU core.

[0098] In some possible implementations, the association between the target GPU cores and the target CPU cores is taken as an example by the main processor. The main processor first generates a second mapping configuration based on the requirements of the target task and the resources of the graphics processor. This configuration includes the logical identifiers of the target GPU cores processing the target task, and the associations between these target GPU cores and the target CPU cores. The scheduling control module in the second chip's bare-chip receives the second mapping configuration from the main processor and determines at least one target CPU core corresponding to the target task. The target CPU core in the second chip's bare-chip distributes the second mapping configuration to each target GPU core. After receiving the target task, each target GPU core determines the subtasks it needs to process within the target task based on the received second mapping configuration. When there are at least two target GPU cores, each target GPU core, according to a pre-agreed task partitioning logic, divides the target task into non-overlapping subtasks based on the logical identifiers of all target GPU cores processing the target task in the second mapping configuration and its own logical identifier. Each target GPU core is responsible for processing one of these subtasks.

[0099] For example, suppose the target task is to process 99 primitives. The main processor first evaluates the currently available GPU and CPU core resources of the graphics processor, and then generates a second mapping configuration. The second mapping configuration includes: (1) the target GPU cores for processing the target task of these 99 primitives are GPU core 1, GPU core 2 and GPU core 4, whose logical identifiers are “LOGIC_001”, “LOGIC_002” and “LOGIC_004”, respectively; (2) one GPU core A in the chip bare band 21 (Die0) is the target CPU core and is associated with all target GPU cores. After receiving this second mapping configuration from the main processor, the scheduling control module in the second chip bare band parses it to determine that the target CPU core corresponding to the target task is CPU core A. CPU core A sends the second mapping configuration to GPU core 1, GPU core 2 and GPU core 4. After receiving the target task, GPU cores 1, 2, and 4, according to the second mapping configuration, follow the pre-agreed task division logic (for example, dividing according to the primitive number, assigning primitives numbered 1+33(k-1) to 33k to GPU core k, where k is the logical identifier of the current target GPU core in the logical identifier order of all target GPU cores, and k for GPU core 4 is 3). GPU core 1 is responsible for processing the sub-tasks corresponding to primitives numbered 1-33, GPU core 2 is responsible for processing the sub-tasks corresponding to primitives numbered 34-66, and GPU core 4 is responsible for processing the sub-tasks corresponding to primitives numbered 67-99.

[0100] Based on the embodiments disclosed in this application, by sending a second mapping configuration from the target CPU core to each target GPU core, the target GPU core can understand the overall situation of the task and its own position in the task in a timely manner, avoiding processing chaos due to missing information. Furthermore, based on the second mapping configuration, each target GPU core can determine the subtasks it needs to process in the target task. When there are multiple target GPU cores, the target task can be divided into multiple non-overlapping subtasks and processed in parallel by different target GPU cores, which can improve task execution efficiency.

[0101] In some embodiments, at least one target CPU core of the second chip bare band is configured to send the second mapping configuration to the routing broadcast module of the second chip bare band; when the target GPU core is in the second chip bare band, the routing broadcast module of the second chip bare band is configured to send the second mapping configuration to the target GPU core; when the target GPU core is not in the second chip bare band, the routing broadcast module of the second chip bare band is configured to send the second mapping configuration to the routing broadcast module of the third chip bare band; the routing broadcast module of the third chip bare band is configured to send the second mapping configuration to the target GPU core.

[0102] In this current embodiment, considering cross-die scenarios, the aforementioned second mapping configuration needs to be sent not only to the target GPU core in the second chip's bare band but also to other chip bare bands (the third chip's bare band). If the target GPU core is located within the second chip's bare band, it is directly forwarded by the local routing broadcast module; if it is located in another chip's bare band (such as the third chip's bare band), the configuration is sent to the routing broadcast module of the target chip's bare band via the routing broadcast module of the second chip's bare band, and then forwarded to the target GPU core by that module. This reduces unnecessary cross-die communication and improves configuration transmission efficiency.

[0103] It should be noted that when the second mapping configuration indicates that at least one target GPU core is located in the second chip bare band, the routing broadcast module of the second chip bare band does not need to send the second mapping configuration to the routing broadcast module of the third chip bare band.

[0104] In some possible implementations, after the target CPU core generates the second mapping configuration, it first checks the location information of the target GPU core in the configuration. If all target GPU cores are located in the second chip's bare band, the target CPU core directly sends the configuration to the routing broadcast module of the second chip's bare band. This module parses the configuration and broadcasts it to the corresponding GPU core via the internal bus, without needing to transmit across dies. If a target GPU core is located in another chip's bare band (such as the third chip's bare band), the target CPU core sends the configuration to the routing broadcast module of the second chip's bare band. This routing broadcast module forwards the configuration to the routing broadcast module of the third chip's bare band, and the module of the third chip's bare band then sends the configuration to the target GPU core via the internal bus.

[0105] Based on the embodiments disclosed in this application, when the target GPU cores are located in the same chip bare band, cross-die communication overhead is reduced, and configuration transmission latency is lowered; when the target GPU cores are distributed in different chip bare bands, accurate configuration is achieved through the relay of the routing broadcast module, avoiding configuration loss or incorrect transmission. It can adapt to chip bare band deployments of different scales, improving the flexibility of task allocation and execution efficiency in complex multi-core environments.

[0106] The following describes the application of the embodiments provided in this application in a real-world scenario.

[0107] Please see Figure 3 It can be seen that, compared to Figure 1D In this embodiment, a routing broadcast module is added at the exit of the front-end scheduling processor, and the routing broadcast modules of each die are bidirectionally interconnected; unified address encoding is applied to all GPU cores in all dies. Please refer to [link to relevant documentation]. Figure 4 , Figure 4This is a schematic diagram of the mapping relationship between physical identifiers and logical identifiers provided in an embodiment of this application. Die0 and Die1 each have 4 GPU cores, and their physical identifiers (IDs) are 0, 1, 2, and 3, respectively. After being identified by the routing broadcast module, they are recognized as logical identifiers (IDs): 0, 1, 2, 3, 4, 5, 6, and 7. In this way, the front-end scheduling processing of both dies can access all GPU cores. At the same time, the feedback events of all GPU cores can also be sent to the front-end scheduling processor to be processed.

[0108] Please see Figure 5 Here is an example of configuring a front-end scheduler for a die to handle all GPU cores on two dies: In a scenario where the scheduling tasks of the graphics subsystem and the compute subsystem are unbalanced, assuming that the scheduling tasks of the graphics subsystem are much greater than those of the compute subsystem, the following configuration can be made, using one CPU core (e.g., Figure 5 CPU #2 in the system schedules all computing subsystem tasks, using two or more CPU cores (such as CPU #2). Figure 5 The CPUs #0 and #1 in the CPU schedule all graphics subsystem tasks, and other subsystem tasks can be configured similarly.

[0109] Please see Figure 6 Here is an example of configuring all GPU cores on two dies with a front-end scheduler: In this scenario, the tasks accessing the graphics subsystem and the compute subsystem are unbalanced and fluctuate greatly. In such a scenario, the following configuration can be made: one die's front-end scheduler schedules all graphics subsystems (e.g., Figure 6 In Die0), each scheduled task queue is assigned to a user program; while using another Die (such as...) Figure 6 The front-end scheduler (Die1) in the GPU schedules computing subsystem tasks across all GPU cores.

[0110] It is understood that there are no specific technical limitations in the implementation of this application, and the implementation details and solutions can be flexibly selected according to the actual system connection and implementation.

[0111] In some embodiments, regarding front-end scheduling processing, the configuration of the routing broadcast module in a multi-core CPU system should support high throughput configuration capabilities, and multiple CPU cores should be flexibly programmable and controlled.

[0112] In some embodiments, regarding the routing broadcast module, the data path should be bidirectional, including: (1) the scheduling configuration of each Die is sent to the GPU core; (2) the feedback events generated by the GPU core are reported to the front-end scheduling processor.

[0113] In some embodiments, the logic of the unified encoding of the multi-core physical identifier mapping logical identifier in this application is configurable.

[0114] In some embodiments, this application can broadcast the second mapping configuration described above. The routing broadcasting modules on the two dies should support broadcast routing. For example, Die0 broadcasts the configuration for writing to all GPU cores. On the data path, a cross-die path is added to the path of all GPU cores in this die. Automatic broadcasting is implemented across Die1, thereby reducing the data transmission bandwidth between dies.

[0115] Specific implementation plan steps example: Step 1: Implement a multi-core front-end scheduling processor system.

[0116] Step 2: Design the routing broadcast module. Configure the mapping between logical and physical addresses for the routing broadcast module, implement the broadcast function of the routing broadcast module, and realize the interconnection between dies. Note that the maximum bandwidth required for cross-die transmission tasks must be calculated.

[0117] Step 3: Write the firmware program for the front-end scheduling processor, implementing the scheduling configuration algorithm and event handling logic. The software can flexibly select the number of CPUs used and configure the mapping between the physical and logical identifiers of the GPUs, implementing scheduling according to the application scenario.

[0118] This application, in the design of a symmetric multi-core full-featured graphics processor (GPU) multi-die interconnect, uniformly manages all GPU cores through a global logical addressing mapping. The front-end scheduling processor can configure all GPU cores through routing broadcasts without program awareness. Furthermore, in this design, the scheduling processor is decoupled from the GPU cores, enabling dynamic configuration and optimizing hardware resource utilization. Compared to existing solutions, the binding between the front-end scheduling processor and the die is logically integrated. Configuration commands from the front-end scheduling processor can be routed to GPU cores in any die, and the front-end scheduling processor CPU can be bound to GPU cores in any die, improving configuration flexibility and overall scheduling performance.

[0119] This application provides a computer device including the graphics processor described in any of the above embodiments.

[0120] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0121] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0122] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0123] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0124] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0125] Furthermore, in the various embodiments of this application, all functional units can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units. Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0126] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0127] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A graphics processor, comprising: The graphics processor comprises at least two chip dies, the chip dies comprising a front-end scheduling system, a routing broadcast module and at least two GPU cores, the front-end scheduling system comprising a scheduling control module and at least two CPU cores, wherein: The scheduling control module of the first chip die is configured to receive a task event corresponding to a target task, and notify at least one target CPU core to schedule the task event; the first chip die is a chip die for scheduling the target task among the at least two chip dies; The routing broadcast module of the second chip die is configured to route the task event to at least one target GPU core, or route the task event to the at least one target CPU core; the second chip die is a chip die in which the target CPU core is located among the at least two chip dies; Wherein, the at least one target GPU core is a GPU core for processing the target task among all GPU cores of the graphics processor; the at least one target CPU core is a CPU core having an association relationship with the at least one target GPU core among all CPU cores of the graphics processor.

2. The graphics processor of claim 1, wherein, The at least one target CPU core comprises one or more of: A first CPU core located in the first chip die; A second CPU core not located in the first chip die.

3. The graphics processor of claim 1 or 2, wherein, The at least one target GPU core comprises one or more of: A first GPU core in the second chip die; A second GPU core in the third chip die; Wherein, the third chip die is a chip die different from the second chip die among all chip dies of the graphics processor.

4. The graphics processor of claim 3, wherein, The task event comprises a task scheduling event; wherein, The routing broadcast module of the second chip die is configured to route the task scheduling event to the first GPU core in the second chip die; and / or, The routing broadcast module of the second chip die is configured to route the task scheduling event to the routing broadcast module of the third chip die; the routing broadcast module of the third chip die is configured to route the task scheduling event to the second GPU core in the third chip die.

5. The graphics processor of claim 3, wherein, The task event comprises an execution feedback event; wherein, The routing broadcast module of the second chip die is configured to receive the execution feedback event reported by the first GPU core in the second chip die; and / or, The routing broadcast module of the second chip die is configured to receive the execution feedback event sent by the routing broadcast module of the third chip die; the routing broadcast module of the third chip die is configured to receive the execution feedback event reported by the second GPU core in the third chip die.

6. The graphics processor of claim 3, wherein, The routing broadcast module is provided with a first mapping configuration, the first mapping configuration being used to determine a mapping relationship between a logical identifier of a GPU core and a physical identifier of the GPU core; wherein, The first mapping configuration is used to determine a mapping relationship between a logical identifier of a GPU core and a physical identifier of the GPU core; wherein, The routing and broadcasting module of the second chip bare die is configured to, in a case where the task event is a task scheduling event, determine a logical identifier of a target GPU core based on a physical identifier of the target GPU core carried in the task scheduling event and the first mapping configuration; and route the task scheduling event to the target GPU core based on the logical identifier of the target GPU core. The routing and broadcasting module of the second chip bare die is configured to, in a case where the task event is an execution feedback event, determine a physical identifier of a target GPU core based on a logical identifier of the target GPU core carried in the execution feedback event and the first mapping configuration; and route the execution feedback event to a target CPU core associated with the target GPU core.

7. The graphics processor of claim 6, wherein, The logical identifiers in the first mapping configuration are logical identifiers of available GPU cores in the graphics processor; the available GPU cores are part or all of all GPU cores in the graphics processor.

8. The graphics processor of claim 6, wherein, The routing and broadcasting module of any chip bare die of the at least two chip bare dies in the graphics processor is configured to receive the first mapping configuration and broadcast the first mapping configuration.

9. The graphics processor of claim 6, wherein, The scheduling control module of the second chip bare die is configured to receive a second mapping configuration issued by a host processor and determine at least one target CPU core corresponding to the target task; the second mapping configuration includes a logical identifier of a target GPU core processing the target task and an association relationship between the target GPU core and the target CPU core. The at least one target CPU core of the second chip bare die is configured to issue the second mapping configuration to each target GPU core; the second mapping configuration is used to determine a subtask that needs to be processed by each target GPU core in the target task.

10. The graphics processor of claim 9, wherein The at least one target CPU core of the second chip bare die is configured to send the second mapping configuration to the routing and broadcasting module of the second chip bare die. In a case where the target GPU core is in the second chip bare die, the routing and broadcasting module of the second chip bare die is configured to send the second mapping configuration to the target GPU core. In a case where the target GPU core is not in the second chip bare die, the routing and broadcasting module of the second chip bare die is configured to send the second mapping configuration to the routing and broadcasting module of the third chip bare die; and the routing and broadcasting module of the third chip bare die is configured to send the second mapping configuration to the target GPU core.

11. A computer device, comprising: The graphics processor includes any one of the graphics processors of claims 1 to 10.

Images