Graphics processor, buffer blocking state processing method and electronic device

Abstract

The present disclosure relates to the field of graphics processor technology, and discloses a graphics processor, a method for processing a buffer blocking state, and an electronic device. The graphics processor includes: a buffer blocking manager and multiple task parsers; any task parser, in response to completing an existing processing task corresponding to the task parser in a target task stream, executes a task update query, and when all query results indicate that there is no task update in the target task stream and the number of consecutive queries meets a preset number threshold, sends buffer blocking information to the buffer blocking manager to indicate that it is in a buffer blocking state; the buffer blocking manager is used to report the buffer blocking state to the software driver corresponding to the graphics processor when all task parsers are in a buffer blocking state. The present disclosure can reduce the processing delay and cavitation of the buffer blocking state; and uniformly manage the buffer blocking states of all task parsers, thereby improving the working efficiency of the graphics processor.

Description

Technical Field

[0001] The present disclosure relates to the technical field of graphics processors, and in particular to a graphics processor, a method for processing a buffer blocking state, and an electronic device. Background Art

[0002] The Graphics Processing Unit (GPU) can parse and calculate the graphics processing task stream (control-stream) from the software driver through the task parser (Compute Frontend Engine, CFE) within its corresponding graphics processing core (GPU Core, GPC). When any CFE completes its corresponding existing processing task (kernel), it enters a buffer-stall state until the software driver sends a new kernel or switches to a new control-stream. Existing technologies typically rely entirely on the software driver to handle the CFE's buffer-stall, resulting in a long processing path, large delays, and cavitation. Furthermore, because the CFE within each GPC may have time differences in parsing the control-stream, the software driver must perform complex and distributed processing on different CFEs, increasing the complexity of the software driver and affecting GPU efficiency. Summary of the Invention

[0003] In view of this, the present disclosure proposes a technical solution for a graphics processor, a method for processing a buffer blocking state, and an electronic device.

[0004] According to one aspect of the present disclosure, a graphics processor is provided, comprising: a buffer blocking manager and multiple task parsers; any one of the task parsers, in response to executing a task update query after completing an existing processing task corresponding to the task parser in a target task flow, and sending buffer blocking information to the buffer blocking manager when all query results indicate that there is no task update in the target task flow and the number of consecutive queries meets a preset number threshold, wherein the buffer blocking information corresponding to the task parser is used to indicate that the task parser is in a buffer blocking state; the buffer blocking manager is used to report the buffer blocking state to a software driver corresponding to the graphics processor when all task parsers are in a buffer blocking state.

[0005] In a possible implementation, the preset number threshold and the first time interval between any two adjacent task update queries are determined based on the software driver settings.

[0006] In one possible implementation, any task parser is used to: determine a reference read offset corresponding to the task parser, wherein the reference read offset corresponding to the task parser is used to indicate the end position of the last processing task that the task parser has parsed in the target task stream; query the real-time write offset corresponding to the target task stream multiple times according to the first time interval, wherein the real-time write offset is used to indicate the end position of the current last processing task in the target task stream; for any task update status query, when it is determined that the real-time write offset is equal to the reference read offset corresponding to the task parser, determine that the query result indicates that there is no task update in the target task stream; for any task update status query, when it is determined that the real-time write offset is greater than the reference read offset corresponding to the task parser, determine that the query result indicates that there is a task update in the target task stream.

[0007] In one possible implementation, any task parser is used to: for any task update status query, if the query result indicates that there is a task update in the target task flow, determine the new processing task corresponding to the task parser based on the real-time write offset.

[0008] In one possible implementation, any task parser is used to: complete the parsing of the i-th processing task in the target task stream according to the i-th read offset corresponding to the task parser, where i is a positive integer greater than or equal to 1; when it is determined that the i-th read offset is less than the initial write offset corresponding to the target task stream, update the i-th read offset to the i+1-th read offset, and complete the parsing of the i+1-th processing task in the target task stream according to the i+1-th read offset, wherein the initial write offset is used to indicate the end position of the last processing task in the target task stream when the software driver sends the target task stream to the graphics processor.

[0009] In a possible implementation, any task parser is configured to: upon determining that the i-th read offset is equal to the initial write offset, determine the i-th read offset as a reference read offset corresponding to the task parser.

[0010] In a possible implementation, the buffer blocking manager manages all task resolvers in a unified manner in response to the buffer blocking status of at least one task resolver.

[0011] In a possible implementation, the buffer blocking manager is configured to: for any task resolver, store the reference read offset corresponding to the task resolver in a state record table corresponding to the graphics processor according to an identifier corresponding to the task resolver.

[0012] In one possible implementation, the buffer blocking manager is used to: when any task parser is in a buffer blocking state, query the real-time write offset multiple times according to a second time interval; determine the reference read offset corresponding to each task parser in the buffer blocking state according to the status record table; and report the buffer blocking status to the software driver when all task parsers are in a buffer blocking state and the reference read offset corresponding to each task parser is equal to the real-time write offset.

[0013] In one possible implementation, the buffer blocking manager is used to: send a task update instruction to any task parser in a buffer blocking state when the reference read offset corresponding to the task parser is smaller than the real-time write offset, wherein the task update instruction is used to instruct the task parser to exit the buffer blocking state.

[0014] In a possible implementation, any task parser is configured to: upon receiving the task update instruction, determine a new processing task corresponding to the task parser according to the real-time write offset.

[0015] According to another aspect of the present disclosure, a method for processing a buffer blocking state is provided, which is applied to a graphics processor, wherein the graphics processor includes: a buffer blocking manager and multiple task parsers; the method includes: after any task parser completes an existing processing task corresponding to the task parser in a target task flow, using the task parser to perform a task update query, and when all query results indicate that there is no task update in the target task flow and the number of consecutive queries meets a preset number threshold, sending buffer blocking information to the buffer blocking manager, wherein the buffer blocking information corresponding to the task parser is used to indicate that the task parser is in a buffer blocking state; when all task parsers are in a buffer blocking state, using the buffer blocking manager to report the buffer blocking state to a software driver corresponding to the graphics processor.

[0016] According to another aspect of the present disclosure, an electronic device is provided, comprising the above-mentioned graphics processor.

[0017] The graphics processor of the disclosed embodiment includes multiple task parsers and a buffer blocking manager. Any task parser can automatically execute a task update query after completing the existing processing task corresponding to the task parser in the target task flow, and when all query results indicate that there is no task update in the target task flow and the number of consecutive queries meets a preset number threshold, send buffer blocking information to the buffer blocking manager to indicate that the task parser is in a buffer blocking state, thereby reducing the number of times the task parser enters the buffer blocking state and wakes up, and reducing the delay and cavitation caused by processing the buffer blocking state. The buffer blocking manager can uniformly record and report the buffer blocking state of all task parsers, shorten the processing path of the buffer blocking state, facilitate the software driver to batch control all task parsers, reduce the complexity of the software driver in processing the buffer blocking state, and improve the work efficiency of the software driver and the graphics processor.

[0018] Further features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate exemplary embodiments, features, and aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0020] Figure 1 A schematic structural diagram of a graphics processor in the prior art is shown.

[0021] Figure 2 A schematic diagram showing a processing task in the prior art.

[0022] Figure 3 A schematic diagram illustrating an analysis of a processing task in the prior art is shown.

[0023] Figure 4 A block diagram of a graphics processor according to an embodiment of the present disclosure is shown.

[0024] Figure 5 A schematic diagram of a status record table according to an embodiment of the present disclosure is shown.

[0025] Figure 6 A flowchart of a method for processing a buffer blocking state according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0026] Various exemplary embodiments, features, and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

[0027] As used herein, the terms "comprises," "comprising," "having," or variations thereof are open ended and include one or more stated features, integers, elements, steps, parts, or functions, but do not preclude the presence or addition of one or more other features, integers, elements, steps, parts, functions, or groups thereof.

[0028] When an element is referred to as being "connected," "coupled," "responsive" or variations thereof to another element, it can be directly connected, coupled or responsive to the other element or intervening elements may be present.

[0029] Although the terms first, second, third, etc. may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another element / operation. Therefore, without departing from the teachings of the present invention, the first element / operation in some embodiments may be referred to as the second element / operation in other embodiments.

[0030] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0031] The term "and / or" herein simply describes an association relationship between associated objects, indicating that three relationships can exist. For example, "A and / or B" can represent the existence of three situations: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" herein refers to any combination of at least two of any one or more of a plurality of items. For example, "at least one of A, B, and C" can represent any one or more elements selected from the set consisting of A, B, and C.

[0032] In addition, numerous specific details are provided in the following detailed description to better illustrate the present disclosure. Those skilled in the art will appreciate that the present disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art are not described in detail in order to highlight the main points of the present disclosure.

[0033] Figure 1 FIG. 1 is a schematic diagram showing the structure of a graphics processor in the prior art. Figure 1As shown in the figure, a graphics processing unit (GPU) consists of multiple graphics processing cores (GPU Cores, GPCs), and each GPC usually includes a task parser (Compute Frontend Engine, CFE) to parse and calculate the graphics processing task flow (control-stream) issued by the GPU's corresponding software driver; each GPC also includes multiple instruction execution units (Execute Units, EUs). All EUs in any GPC can execute processing tasks (kernels) under the scheduling of the CFE in the GPC.

[0034] Specifically, the control-stream consists of multiple consecutive kernels, each of which is defined by a general computing standard framework such as OpenCL / DirectX / Vulkan and can be executed on the GPU.

[0035] Figure 2 A schematic diagram showing a processing task in the prior art is shown. Figure 2 As shown, any processing task (processing task 1 ... processing task n) has a corresponding starting position (read point) and an ending position (write point).

[0036] Multiple kernels within the same control-stream are typically executed serially. Specifically, the end position of the first kernel in the control-stream is the start position of the second kernel in the control-stream, the end position of the second kernel in the control-stream is the start position of the third kernel in the control-stream, and so on. The end position of the last kernel in the control-stream is also the end position of the control-stream, and this position is also the start position of the new kernel in the control-stream.

[0037] After the GPU's software driver completes control stream preparation and configures the initial read offset (read-offset) and initial write offset (write-offset) for the control stream, it sends the control stream to the GPU. The initial read offset indicates the starting position of the first kernel when the software driver sends the control stream to the GPU, and the initial write offset indicates the ending position of the last kernel in the control stream. This is also the ending position of the control stream when the software driver sends the control stream to the GPU. When the software driver adds a new kernel to the control stream, the new kernel is added to the control stream starting at the initial read offset.

[0038] The GPU broadcasts the control stream to all GPCs. After receiving the control stream, the CFE in each GPC reads the control stream starting from the initial read offset and parses each kernel in the control stream in sequence.

[0039] Figure 3 FIG. 1 shows a schematic diagram of an analytical processing task in the prior art. Figure 3 As shown, any kernel can be decomposed into multiple thread groups (work-groups) in sequence along the three dimensions of X, Y, and Z. Each work-group can also be decomposed into multiple independent and parallel threads (work-items) of equal size in sequence along the three dimensions of X, Y, and Z. On the other hand, a work-group can also be divided into multiple thread bundles (wavefronts). The number of work-items included in each wavefront is determined by the hardware conditions of the GPU. The wavefront can be used as the smallest unit of GPU scheduling, while the work-item is the smallest unit of program execution. The same work-group can only be executed on the same EU, and all work-items in the same work-group share internal memory.

[0040] For any kernel, each GPC is assigned a fixed number of work-groups included in the kernel, and the CFE within each GPC sends the assigned work-groups to each EU, thereby enabling the CFE to parse the kernel.

[0041] For any CFE, when the CFE completes parsing a kernel in the current control-stream and confirms that the current read-offset is not equal to the write-offset, the CFE will increase the current read-offset by 1 to instruct the CFE to parse the next kernel in the current control-stream. When the CFE completes parsing a kernel in the current control-stream and confirms that the current read-offset is equal to the write-offset, it indicates the end position of the kernel completed at this time, that is, the end position of the last kernel in the current control-stream. It can be determined that the CFE has completed parsing all kernels in the current control-stream.

[0042] After any CFE completes parsing all kernels within the current control-stream, it enters a buffer-stall state and reports this to the software driver until the software driver updates and delivers a new kernel within the current control-stream. This resumes the CFE and allows it to continue parsing the new kernel within the current control-stream. If no new kernel is updated within the current control-stream for an extended period, the software driver can switch to a new control-stream.

[0043] Existing technologies typically rely entirely on the software driver to handle buffer-stall for each CFE. This results in a long processing path, significant delays, and voids. For example, if a CFE enters buffer-stall while the software driver is delivering a new kernel, the software driver must resume the CFE before it can parse the new kernel, resulting in processing delays and voids. Furthermore, because each CFE may parse the control stream at varying speeds, the software driver must perform complex, distributed processing for each CFE, increasing its complexity and impacting GPU efficiency.

[0044] In light of this, the present disclosure provides a graphics processor that, on the one hand, utilizes the task resolver's auto-resume function to reduce buffer stall processing delays and cavitation. On the other hand, a newly added buffer stall manager (BSM) manages the buffer stall status of all task resolvers uniformly at the hardware level, reducing the processing burden on the software driver and thereby improving the graphics processor's operating efficiency. The following is a detailed description of the graphics processor provided by the present disclosure.

[0045] Figure 4 FIG. 1 is a block diagram of a graphics processor according to an embodiment of the present disclosure. Figure 4 As shown, the graphics processor 400 includes: a plurality of task parsers 401 and a buffer blocking manager 402 .

[0046] Any task parser 401, in response to executing a task update query after completing the existing processing task corresponding to the task parser 401 in the target task flow, and when all query results indicate that there is no task update in the target task flow and the number of consecutive queries meets the preset number threshold, sends buffer congestion information to the buffer congestion manager 402, wherein the buffer congestion information corresponding to the task parser 401 is used to indicate that the task parser 401 is in a buffer congestion state.

[0047] Specifically, any task parser 401 may represent a CFE corresponding to a GPC within the GPU 400. The specific form of the task parser 401 may be referred to in related art implementations and is not specifically limited in this disclosure. The specific number of task parsers 401 included in the GPU 400 may be flexibly set based on actual usage requirements and is not specifically limited in this disclosure.

[0048] For any task parser 401, after completing the existing processing task (kernel) corresponding to the task parser 401 in the target task stream, the task parser 401 can actively perform a task update query, obtain the corresponding query result, and confirm whether there is a task update in the target task stream (that is, whether a new processing task has been added to the target task stream) without directly entering the buffer blocking state. The target task stream here can represent any control-stream that the graphics processor 400 currently needs to execute, including at least one processing task. The specific form of the target task stream can refer to the implementation methods in the relevant technology, and this disclosure does not make specific limitations on this.

[0049] When any query result indicates that there is a task update in the target task flow, the task parser 401 can actively confirm the new processing task and parse it, realizing the Auto resume function, thereby avoiding the task parser 401 entering the buffer blocking state immediately after completing the existing tasks in the target task flow, and reducing the possibility of processing delays and bubbles after the target task flow is updated.

[0050] Only when all query results indicate that there are no task updates in the target task flow and the number of consecutive queries meets a preset threshold, will the task resolver 401 enter a buffer blocking state and send a buffer blocking message to the buffer blocking manager 402. The specific value of the preset threshold can be flexibly set according to actual usage requirements and is not specifically limited in this disclosure; the specific form and content of the buffer blocking message can be flexibly set according to actual usage requirements and is not specifically limited in this disclosure.

[0051] In a possible implementation, the preset number threshold and the first time interval between any two adjacent task update queries are determined based on software driver settings.

[0052] To increase the flexibility of task update queries for each task resolver and reduce the processing resources consumed by each task resolver when executing task update queries, the software driver corresponding to the graphics processor can be configured with a preset number threshold and a first time interval between any two adjacent task update queries, thereby flexibly setting the preset number threshold and the first time interval using the software driver. The specific method for setting the preset number threshold and the first time interval based on the software driver can refer to the method for configuring any operating parameter of the graphics processor based on the software driver in the related art, and this disclosure does not specifically limit this.

[0053] By actively executing task update queries, the number of times each task parser 401 enters the buffer blocking state and wakes up can be reduced, thereby reducing the delay and cavitation caused by the processing buffer blocking state, and comprehensively improving the working efficiency of the graphics processor 400.

[0054] The task parser 401 will be introduced in detail later in conjunction with possible implementation methods of the present disclosure, and will not be described in detail here.

[0055] The buffer blocking manager 402 is configured to report the buffer blocking status to the software driver corresponding to the graphics processor 400 when all task parsers 401 are in the buffer blocking status.

[0056] With the above Figure 4 For example, Figure 4 As shown, the buffer congestion manager 402 is in communication with all task parsers 401 within the graphics processor 400 and can receive buffer congestion information sent by any task parser 401. The specific structure and implementation of the buffer congestion manager 402 can be flexibly configured according to actual usage requirements and is not specifically limited in this disclosure.

[0057] If all task parsers 401 are in a buffer-blocked state, the buffer-blocking manager 402 can report the buffer-blocked state to the software driver corresponding to the graphics processor 400. The software driver can then perform tasks such as switching tasks based on the actual situation. The specific form of the software driver can be flexibly configured based on actual usage requirements and is not specifically limited in this disclosure.

[0058] Through the buffer blocking manager 402, the buffer blocking status of all task parsers 401 can be uniformly recorded and reported, so that the software driver can batch process all task parsers 401, avoiding the time difference in reporting the buffer blocking status due to the different parsing speeds of different task parsers 401, reducing the complexity of the software driver in processing the buffer blocking status, and improving the work efficiency of the software driver and the graphics processor 400.

[0059] The buffer blocking manager 402 will be described in detail later in conjunction with possible implementations of the present disclosure, and will not be elaborated here.

[0060] The graphics processor of the disclosed embodiment includes multiple task parsers and a buffer blocking manager. Any task parser can automatically execute a task update query after completing the existing processing task corresponding to the task parser in the target task flow, and when all query results indicate that there is no task update in the target task flow and the number of consecutive queries meets a preset number threshold, send buffer blocking information to the buffer blocking manager to indicate that the task parser is in a buffer blocking state, thereby reducing the number of times the task parser enters the buffer blocking state and wakes up, and reducing the delay and cavitation caused by processing the buffer blocking state. The buffer blocking manager can uniformly record and report the buffer blocking state of all task parsers, shorten the processing path of the buffer blocking state, facilitate the software driver to batch control all task parsers, reduce the complexity of the software driver in processing the buffer blocking state, and improve the work efficiency of the software driver and the graphics processor.

[0061] In one possible implementation, any task parser 401 is used to: complete the parsing of the i-th processing task in the target task stream according to the i-th read offset corresponding to the task parser 401, where i is a positive integer greater than or equal to 1; when it is determined that the i-th read offset is less than the initial write offset corresponding to the target task stream, update the i-th read offset to the i+1-th read offset, and complete the parsing of the i+1-th processing task in the target task stream according to the i+1-th read offset, wherein the initial write offset is used to indicate the end position of the last processing task in the target task stream when the software driver sends the target task stream to the graphics processor 400.

[0062] Specifically, for any task parser 401, when the software driver sends the target task stream to the graphics processor 400, the task parser 401 will receive the initial read offset and initial write offset broadcast by the GPC. The initial read offset is used to indicate the starting position of the first processing task when the software driver sends the target task stream to the graphics processor 400; the initial write offset is used to indicate the end position of the last processing task in the target task stream when the software driver sends the target task stream to the graphics processor 400. This position is also the starting position of the newly added processing task when there is a task update in the target task stream. The specific forms of the initial read offset and the initial write offset can be referred to the implementation methods in the relevant technology, and the present disclosure does not make specific limitations on this.

[0063] The i-th read offset is used to indicate the starting position of the i-th processing task. The specific method of updating the i-th read offset to the i+1-th read offset can be referred to the implementation in the related art, and this disclosure does not make any specific limitation on this.

[0064] In one example, for any task parser 401, the i=1th read offset corresponding to it is the initial read offset, which is used to indicate the starting position of the first processing task in the target task stream. The task parser 401 can parse the first processing task in the target task stream based on the first read offset, and after completing the parsing of the first processing task, add 1 to the first read offset to obtain a second read offset, which is used to indicate the end position of the first processing task in the target task stream and the starting position of the second processing task in the target task stream. According to the second read offset, the task parser 401 can parse the second processing task in the target task stream, and after completing the parsing of the second processing task, add 1 to the second read offset to obtain the third read offset, which is used to indicate the end position of the second processing task in the target task stream and the starting position of the third processing task in the target task stream, and so on, until the i-th read offset is equal to the initial write offset. The task parser 401 can determine the end position of the i-th processing task in the target task stream, which is the end position of the last processing task in the target task stream. At this time, the task parser 401 can confirm the completion of the existing processing tasks in the target task stream.

[0065] Through the above process, each task parser 401 can complete the parsing of the existing processing tasks in the target task stream according to the initial read offset and the initial write offset.

[0066] In a possible implementation, any task parser 401 is configured to: upon determining that the i-th read offset is equal to the initial write offset, determine the i-th read offset as a reference read offset corresponding to the task parser 401 .

[0067] When any task parser 401 determines that its corresponding i-th read offset is equal to the initial write offset, it can be confirmed that the task parser 401 has completed the last processing task in the target task stream when the software driver sends the target task stream to the graphics processor 400. At this time, the i-th read offset can be determined as the reference read offset corresponding to the task parser 401 as the basis for task update status query.

[0068] In one possible implementation, any task parser 401 is used to: determine a reference read offset corresponding to the task parser 401, wherein the reference read offset corresponding to the task parser 401 is used to indicate the end position of the last processing task that has been parsed by the task parser 401 in the target task flow; query the real-time write offset corresponding to the target task flow multiple times according to a first time interval, wherein the real-time write offset is used to indicate the end position of the current last processing task in the target task flow; for any task update status query, when it is determined that the real-time write offset is equal to the reference read offset corresponding to the task parser 401, determine that the query result indicates that there is no task update in the target task flow; for any task update status query, when it is determined that the real-time write offset is greater than the reference read offset corresponding to the task parser, determine that the query result indicates that there is a task update in the target task flow.

[0069] Specifically, any task parser 401 can determine the reference read offset corresponding to the task parser 401 after completing the existing processing task corresponding to the task parser 401 in the target task flow, so as to confirm the end position of the last processing task that the task parser 401 has parsed and completed in the target task flow, and serve as a basis for judging whether there is a task update in the target task flow when executing a task update query. Among them, the specific form of the reference read offset can refer to the implementation method in the relevant technology, and the present disclosure does not make specific limitations on this. The specific method for any task parser 401 to determine its corresponding reference read offset can be flexibly set according to actual usage requirements, and the present disclosure does not make specific limitations on this.

[0070] Any task parser 401 can actively query the real-time write offset corresponding to the target task stream according to the preset first time interval to confirm the termination position of the current last processing task in the target task stream. Among them, the specific value of the first time interval can be flexibly set according to actual usage requirements, and this disclosure does not make specific limitations on this. The specific method for any task parser 401 to query the real-time write offset can be flexibly set according to actual usage requirements, and this disclosure does not make specific limitations on this.

[0071] In one example, the software driver stores the real-time write offset corresponding to the target task flow in a preset storage location, and any task parser 401 can poll the preset storage location multiple times according to the first time interval to determine the real-time write offset.

[0072] For any task update status query of any task parser 401, the task parser 401 can compare the queried real-time write offset with the reference read offset corresponding to the task parser 401 to determine whether the last processing task that the task parser 401 has parsed is the current last processing task in the target task stream, thereby determining whether there is a task update in the target task stream. When it is determined that the real-time write offset is equal to the reference read offset corresponding to the task parser 401, that is, when it is determined that the last processing task that the task parser 401 has parsed is the current last processing task in the target task stream, it can be determined that the query result indicates that there is no task update in the target task stream. When it is determined that the real-time write offset is greater than the reference read offset corresponding to the task parser 401, that is, when it is determined that the last processing task that the task parser 401 has parsed is not the current last processing task in the target task stream, it can be determined that the query result indicates that there is a task update in the target task stream.

[0073] Through the above process, each task resolver 401 can implement task update query by automatically polling the real-time write offset and comparing the real-time write offset with the corresponding reference read offset.

[0074] In one possible implementation, any task parser 401 is used to: for any task update status query, if the query result indicates that there is a task update in the target task flow, determine the new processing task corresponding to the task parser 401 based on the real-time write offset.

[0075] For any task update status query of any task parser 401, when it is determined that the query result indicates that there is a task update in the target task flow, the task parser 401 can automatically execute Auto resume in response to the query result, automatically determine the new processing task corresponding to the task parser 401 based on the real-time write offset, and perform analysis, thereby avoiding the task parser 401 from entering the buffer blocking state from the source, thereby eliminating the need for a lengthy processing path and improving the working efficiency of the graphics processor 400.

[0076] In a possible implementation, the buffer blocking manager 402 manages the task resolvers 401 in a unified manner in response to the buffer blocking status of at least one task resolver 401 .

[0077] In response to any task parser 401 being in a buffer blocking state, the buffer blocking manager 402 can uniformly manage all task parsers 401. For example, it can record when any task parser 401 is in a buffer blocking state, and does not report the buffer blocking state of the task parser 401 separately.

[0078] When all task parsers 401 are in a buffer blocking state, the buffer blocking manager 402 can uniformly report the buffer blocking states of all task parsers 401 to the software driver, thereby avoiding the impact of the buffer blocking state reporting time difference caused by the different parsing speeds of different task parsers 401, reducing the complexity of the software driver in handling the buffer blocking state, and improving the working efficiency of the graphics processor 400.

[0079] The specific method by which the buffer blocking manager 402 uniformly manages all task parsers 401 can be flexibly set according to actual usage requirements, and this disclosure does not make any specific limitation on this.

[0080] In one possible implementation, the buffer blocking manager 402 is configured to: for any task parser 401 , store the reference read offset corresponding to the task parser 401 in a state record table corresponding to the graphics processor 400 according to the identifier corresponding to the task parser 401 .

[0081] Specifically, any task resolver 401 sends buffer congestion information to the buffer congestion manager 402, which may include an identifier corresponding to the task resolver 401, a reference read offset, and information indicating that the task resolver 401 is in a buffer congestion state. The specific form of the identifier corresponding to any task resolver 401 can be flexibly set according to actual usage requirements and is not specifically limited in this disclosure.

[0082] In one example, each GPC within the graphics processor 400 has a corresponding image processing core identifier (GPCID). Therefore, the identifier corresponding to any task resolver 401 can be directly set to the GPC ID corresponding to the GPC where the task resolver 401 is located. The specific form of the GPC ID corresponding to any GPC can be referred to the implementation methods in the relevant technology, and this disclosure does not specifically limit this.

[0083] After receiving buffer congestion information from any task resolver 401, the buffer congestion manager 402 can store the reference read offset corresponding to the task resolver 401 in the state record table corresponding to the graphics processor 400 based on the identifier corresponding to the task resolver 401, and record the state corresponding to the task resolver 401 in the state record table as the buffer congestion state. The specific format of the state record table corresponding to the graphics processor 400 can be flexibly configured according to actual usage requirements and is not specifically limited in this disclosure.

[0084] Figure 5 FIG. 1 is a schematic diagram showing a state record table according to an embodiment of the present disclosure. Figure 5 As shown, the identifier corresponding to any task resolver 401 is the GPC ID corresponding to the GPC where the task resolver 401 is located, namely image processing core 1, image processing core 2, ..., image processing core n. The first column of the status record table is used to record the buffer blocking status corresponding to each task resolver 401, and the second column is used to store the reference read offset corresponding to each task resolver 401.

[0085] By using the status record table, the buffer blocking manager 402 can realize the unified recording and storage of the buffer blocking status and reference read offset of all task parsers 401, and facilitate access in subsequent management processes, thereby improving management efficiency.

[0086] In one possible implementation, the buffer blocking manager 402 is used to: when any task parser 401 is in a buffer blocking state, query the real-time write offset multiple times according to a second time interval; determine the reference read offset corresponding to each task parser 401 in a buffer blocking state according to a status record table; and report the buffer blocking state to the software driver when all task parsers 401 are in a buffer blocking state and the reference read offset corresponding to each task parser 401 is equal to the real-time write offset.

[0087] When any task resolver 401 is in a buffer-blocked state, the buffer-blocking manager 402 may query the real-time write offset multiple times based on a second time interval to confirm the termination position of the last currently processed task in the target task stream and determine whether there are any task updates in the target task stream after the task resolver 401 entered the buffer-blocked state. The specific value of the second time interval can be flexibly set based on actual usage requirements and is not specifically limited in this disclosure.

[0088] According to the status record table, the buffer blocking manager 402 can respectively determine the reference read offset corresponding to each task parser 401 in the buffer blocking state, and compare it with the real-time write offset queried by the buffer blocking manager 402. When all task parsers 401 are in the buffer blocking state, and the reference read offset corresponding to each task parser 401 is equal to the real-time write offset, the buffer blocking manager 402 can report the buffer blocking state to the software driver to achieve unified management of all task parsers 401. On the one hand, it can avoid the time difference in reporting the buffer blocking state caused by the different parsing speeds of different task parsers 401, and can reduce the complexity of the software driver in processing the buffer blocking state; on the other hand, using the independent hardware structure of the buffer blocking manager 402 to manage the buffer blocking state can further improve the working efficiency of the graphics processor 400 compared with the processing method in the prior art that completely relies on the software driver.

[0089] In one possible implementation, the buffer blocking manager 402 is used to: when the reference read offset corresponding to any task parser 401 in the buffer blocking state is less than the real-time write offset, send a task update instruction to the task parser 401, wherein the task update instruction is used to instruct the task parser 401 to exit the buffer blocking state.

[0090] If the reference read offset corresponding to any task resolver 401 in the buffer blocking state is less than the real-time write offset, the buffer blocking manager 402 can determine that a task update occurred in the target task flow after the task resolver 401 entered the buffer blocking state, that is, there is a new processing task in the target task flow that has not been resolved by the task resolver 401. In this case, the buffer blocking manager 402 can directly resume the task resolver 401 without going through the software driver processing, thereby shortening the buffer blocking state processing path and improving the buffer blocking state processing efficiency.

[0091] Specifically, the buffer blocking manager 402 may send a task update instruction to the task resolver 401 to instruct the task resolver 401 to exit the buffer blocking state and resume the task resolver 401. The specific content and form of the task update instruction can be flexibly set according to actual usage requirements and are not specifically limited in this disclosure.

[0092] In a possible implementation, any task parser 401 is configured to, upon receiving a task update instruction, determine a new processing task corresponding to the task parser 401 according to a real-time write offset.

[0093] The task update instruction sent by the buffer blocking manager 402 to any task resolver 401 may include the real-time write offset obtained by the buffer blocking manager 402. When receiving the task update instruction, the task resolver 401 may determine the new processing task corresponding to the task resolver 401 based on the real-time write offset and automatically perform the resolution.

[0094] The graphics processor of the disclosed embodiment includes multiple task parsers and a buffer blocking manager. Any task parser can automatically execute a task update query after completing the existing processing task corresponding to the task parser in the target task flow, and when all query results indicate that there is no task update in the target task flow and the number of consecutive queries meets a preset number threshold, send buffer blocking information to the buffer blocking manager to indicate that the task parser is in a buffer blocking state, thereby reducing the number of times the task parser enters the buffer blocking state and wakes up, and reducing the delay and cavitation caused by processing the buffer blocking state. The buffer blocking manager can uniformly record and report the buffer blocking state of all task parsers, shorten the processing path of the buffer blocking state, facilitate the software driver to batch control all task parsers, reduce the complexity of the software driver in processing the buffer blocking state, and improve the work efficiency of the software driver and the graphics processor.

[0095] In addition, according to another aspect of an embodiment of the present disclosure, a method for processing a buffer blocking state is also provided, which can be applied to a graphics processor including a buffer blocking manager and multiple task parsers. The corresponding technical solutions and descriptions can be found in the corresponding records of the graphics processor part and will not be repeated here.

[0096] Figure 6 A flowchart showing a method for processing a buffer blocking state according to an embodiment of the present disclosure is shown. Figure 4 The graphics processor shown in the figure includes a buffer blocking manager and multiple task parsers. Figure 6 For example, Figure 6 As shown, the method includes:

[0097] In step S601, after any task resolver completes the existing processing task corresponding to the task resolver in the target task flow, the task resolver is used to perform a task update query, and when all query results indicate that there is no task update in the target task flow and the number of consecutive queries meets the preset number threshold, buffer blocking information is sent to the buffer blocking manager, wherein the buffer blocking information corresponding to the task resolver is used to indicate that the task resolver is in a buffer blocking state.

[0098] In step S602, when all task parsers are in a buffer blocking state, the buffer blocking manager is used to report the buffer blocking state to a software driver corresponding to the graphics processor.

[0099] In a possible implementation, the preset number threshold and the first time interval between any two adjacent task update queries are determined based on software driver settings.

[0100] In one possible implementation, after any task resolver completes an existing processing task corresponding to the task resolver in the target task stream, the task resolver is used to perform a task update query, including: determining a reference read offset corresponding to the task resolver, wherein the reference read offset corresponding to the task resolver is used to indicate the end position of the last processing task that the task resolver has resolved in the target task stream; according to a first time interval, using the task resolver to query the real-time write offset corresponding to the target task stream multiple times, wherein the real-time write offset is used to indicate the end position of the current last processing task in the target task stream; for any task update status query, when it is determined that the real-time write offset is equal to the reference read offset corresponding to the task resolver, it is determined that the query result indicates that there is no task update in the target task stream; for any task update status query, when it is determined that the real-time write offset is greater than the reference read offset corresponding to the task resolver, it is determined that the query result indicates that there is a task update in the target task stream.

[0101] In a possible implementation, the method further includes: for any task update status query, when the query result indicates that there is a task update in the target task flow, determining the new processing task corresponding to the task parser based on the real-time write offset.

[0102] In one possible implementation, the method further includes: for any task parser, completing the parsing of the i-th processing task in the target task stream according to the i-th read offset corresponding to the task parser, where i is a positive integer greater than or equal to 1; when it is determined that the i-th read offset is less than the initial write offset corresponding to the target task stream, updating the i-th read offset to the i+1-th read offset, and completing the parsing of the i+1-th processing task in the target task stream according to the i+1-th read offset, wherein the initial write offset is used to indicate the end position of the last processing task in the target task stream when the software driver sends the target task stream to the graphics processor.

[0103] In one possible implementation, the method further includes: for any task parser, when it is determined that the i-th read offset of the task parser is equal to the initial write offset, determining the i-th read offset as the reference read offset corresponding to the task parser.

[0104] In a possible implementation, the buffer blocking manager manages all task resolvers in a unified manner in response to the buffer blocking status of at least one task resolver.

[0105] In a possible implementation, the method further includes: for any task resolver, according to an identifier corresponding to the task resolver, using a buffer blocking manager, storing a reference read offset corresponding to the task resolver in a state record table corresponding to the graphics processor.

[0106] In one possible implementation, when all task resolvers are in a buffer blocking state, the buffer blocking manager is used to report the buffer blocking state to the software driver corresponding to the graphics processor, including: when any task resolver is in a buffer blocking state, the buffer blocking manager is used to query the real-time write offset multiple times according to the second time interval; according to the status record table, the buffer blocking manager is used to determine the reference read offset corresponding to each task resolver in the buffer blocking state; when all task resolvers are in a buffer blocking state and the reference read offset corresponding to each task resolver is equal to the real-time write offset, the buffer blocking manager is used to report the buffer blocking state to the software driver.

[0107] In one possible implementation, the method further includes: when the reference read offset corresponding to any task parser in a buffer blocking state is smaller than the real-time write offset, using the buffer blocking manager to send a task update instruction to the task parser, wherein the task update instruction is used to instruct the task parser to exit the buffer blocking state.

[0108] In a possible implementation, the method further includes: when any task parser in a buffer blocking state receives a task update instruction, controlling the task parser to determine a new processing task corresponding to the task parser based on a real-time write offset.

[0109] It is understood that the above-mentioned various method embodiments mentioned in this disclosure can be combined with each other to form combined embodiments without violating the principle logic. Due to space limitations, this disclosure will not go into details. It is understood by those skilled in the art that in the above-mentioned methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0110] According to another aspect of the present disclosure, an electronic device is provided, including the above-mentioned graphics processor.

[0111] While various embodiments of the present disclosure have been described above, the foregoing description is intended to be illustrative, non-exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or technological improvements in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A graphics processor, characterized in that: The graphics processor includes: a buffer blocking manager and a plurality of task parsers; Any task resolver, in response to executing a task update query after completing an existing processing task corresponding to the task resolver in a target task flow, and when all query results indicate that there is no task update in the target task flow and the number of consecutive queries meets a preset number threshold, sends buffer blocking information to the buffer blocking manager, wherein the buffer blocking information corresponding to the task resolver is used to indicate that the task resolver is in a buffer blocking state; The buffer blocking manager is configured to report the buffer blocking status to the software driver corresponding to the graphics processor when all task parsers are in the buffer blocking state; The buffer blocking manager manages all task resolvers in a unified manner in response to the buffer blocking status of at least one task resolver.

2. The graphics processor according to claim 1, wherein: The preset number threshold and the first time interval between any two adjacent task update queries are determined based on the software driver settings.

3. The graphics processor according to claim 2, wherein: Any task parser, used to: Determine a reference read offset corresponding to the task parser, wherein the reference read offset corresponding to the task parser is used to indicate the end position of the last processing task that has been parsed by the task parser in the target task stream; querying the real-time write offset corresponding to the target task stream multiple times according to the first time interval, wherein the real-time write offset is used to indicate the termination position of the last currently processed task in the target task stream; For any task update status query, when it is determined that the real-time write offset is equal to the reference read offset corresponding to the task resolver, it is determined that the query result indicates that there is no task update for the target task flow; For any task update status query, when it is determined that the real-time write offset is greater than the reference read offset corresponding to the task resolver, it is determined that the query result indicates that there is a task update in the target task flow.

4. The graphics processor according to claim 3, wherein: Any task parser, used to: For any task update status query, when the query result indicates that there is a task update in the target task stream, the new processing task corresponding to the task parser is determined according to the real-time write offset.

5. The graphics processor according to any one of claims 1 to 4, wherein: Any task parser, used to: According to the i-th read offset corresponding to the task parser, complete the parsing of the i-th processing task in the target task stream, where i is a positive integer greater than or equal to 1; If it is determined that the i-th read offset is less than the initial write offset corresponding to the target task stream, the i-th read offset is updated to the i+1-th read offset, and the i+1-th processing task in the target task stream is parsed based on the i+1-th read offset, wherein the initial write offset is used to indicate the end position of the last processing task in the target task stream when the software driver sends the target task stream to the graphics processor.

6. The graphics processor according to claim 5, wherein: Any task parser, used to: When it is determined that the i-th read offset is equal to the initial write offset, the i-th read offset is determined as the reference read offset corresponding to the task resolver.

7. The graphics processor according to claim 3 or 4, characterized in that: The buffer blocking manager is used to: For any task parser, according to the identifier corresponding to the task parser, the reference read offset corresponding to the task parser is stored in the state record table corresponding to the graphics processor.

8. The graphics processor according to claim 7, wherein: The buffer blocking manager is used to: When any one of the task resolvers is in a buffer blocking state, querying the real-time write offset multiple times according to a second time interval; Determine, according to the state record table, a reference read offset corresponding to each task parser in a buffer blocking state; When all task resolvers are in a buffer blocking state and the reference read offset corresponding to each task resolver is equal to the real-time write offset, the buffer blocking state is reported to the software driver.

9. The graphics processor according to claim 8, wherein: The buffer blocking manager is used to: When the reference read offset corresponding to any task resolver in the buffer blocking state is smaller than the real-time write offset, a task update instruction is sent to the task resolver, wherein the task update instruction is used to instruct the task resolver to leave the buffer blocking state.

10. The graphics processor according to claim 9, wherein: Any task parser, used to: When the task update instruction is received, a new processing task corresponding to the task parser is determined according to the real-time write offset.

11. A method for processing a buffer blocking state, characterized in that: The method is applied to a graphics processor, the graphics processor comprising: a buffer blocking manager and a plurality of task parsers; the method comprising: After any task resolver completes an existing processing task corresponding to the task resolver in the target task flow, the task resolver is used to perform a task update query, and when all query results indicate that there is no task update in the target task flow and the number of consecutive queries meets a preset number threshold, buffer blocking information is sent to the buffer blocking manager, wherein the buffer blocking information corresponding to the task resolver is used to indicate that the task resolver is in a buffer blocking state; When all task parsers are in a buffer blocking state, using the buffer blocking manager to report the buffer blocking state to a software driver corresponding to the graphics processor; The buffer blocking manager manages all task resolvers in a unified manner in response to the buffer blocking status of at least one task resolver.

12. An electronic device, characterized in that: A graphics processor comprising the graphics processor according to any one of claims 1 to 10.

Images