Task processing method, device and storage medium of game frame cycle

Abstract

Embodiments of the present application provide a game frame cycle task processing method and device and a storage medium. After a task system in a game engine receives a first task submitted by a first worker thread and a dependency relationship of the first task to at least one dependent task, the task system can determine that the first task is in a waiting state when the at least one dependent task is not executed completely. When the at least one dependent task is executed completely, the first task is added to a ready task set, and the first task is read and executed by a second worker thread. In this implementation, the worker thread can suspend the task according to the dependency relationship of the task by the task system, and determine when to reactivate the task according to the dependency relationship of the task by the task system, so that the worker thread can realize the scheduling of the task, the dependence on the main thread is reduced, the interaction times between the main thread and other worker threads are reduced, the blocking condition of the main thread is reduced, and the processing efficiency of the task is improved.

Description

Technical Field

[0001] This application relates to the field of engine technology, and in particular to a task processing method, device and storage medium for game frame looping. Background Technology

[0002] During game execution, the game engine continuously runs according to the game's logic rules. The game program completes one full game logic cycle (or main loop) via the main thread. Within the frame loop, some parts can be executed in parallel, thus improving the game's running speed.

[0003] In existing technologies, game engine logic can be encapsulated into a series of tasks. At specific steps of each frame's logic, the main thread submits these tasks to a thread pool, synchronously waiting for completion in a blocking manner, or querying whether a task has finished executing in a non-blocking manner. This approach cannot efficiently implement task scheduling. Therefore, a new solution is needed. Summary of the Invention

[0004] This application provides a method, device, and storage medium for processing game frame loops to improve task processing efficiency.

[0005] This application provides a task processing method for game frame looping. In the game frame loop, the rendering logic of any frame of the game screen is encapsulated into multiple tasks. The game engine includes a task system for scheduling the multiple tasks. The method includes: during the game frame loop, receiving a first task submitted by a first worker thread and the dependency relationship of the first task on at least one dependent task; if the at least one dependent task has not been completed, updating the status of the first task to a waiting state; when all at least one dependent task has been completed, adding the first task to a ready task set; and reading and executing the first task through a second worker thread.

[0006] Further optionally, receiving a first task submitted by a first worker thread includes: receiving a particle effect calculation task, a skeletal animation processing task, a cloth calculation task, an occlusion culling task, a view frustum culling task, a skinning processing task, a static clipping task, or a rendering task submitted by the first worker thread.

[0007] Further optionally, after updating the state of the first task to a waiting state, the method further includes: generating a waiting count for the first task based on the number of the at least one dependent task; adding the first task to the ready task set when all at least one dependent task has been executed, including: sequentially decrementing the waiting count when the at least one dependent task has been executed in sequence; and adding the first task to the ready task set when the waiting count is zero.

[0008] Further optionally, after receiving the first task submitted by the first worker thread and the dependency relationship of the first task on at least one dependent task, the method further includes: for any second task among the at least one dependent task, adding the first task to the waiting task list of the second task; and decrementing the waiting count sequentially when the at least one dependent task is executed in sequence, including: when the second task is completed, traversing the waiting task list of the second task, determining the first task waiting for the second task to be completed, and decrementing the waiting count of the first task.

[0009] Further optionally, after receiving the first task submitted by the first worker thread, the method further includes: determining at least one waiting task for the first task; and adding the at least one waiting task to the waiting task list of the first task.

[0010] Further optionally, reading the first task and executing the first task through a second worker thread includes: determining an unterminated thread from the thread pool as the second worker thread, or activating an idle thread as the second worker thread; using the second worker thread to read the first task from the set of ready tasks and execute the first task.

[0011] Further optionally, in the process of using the second worker thread to read the first task from the ready task set and execute the first task, the method further includes: if it is necessary to adjust the dependency relationship of the first task, using the second worker thread to resubmit the first task and the new dependency relationship of the first task to the task system.

[0012] Further optionally, after the task system receives the first task submitted by the first worker thread, it further includes: generating a reference count for the first task; using a third thread to determine a third task to be submitted, wherein the third task depends on the first task; and when the reference count of the first task is not zero, using the third thread to submit the third task and the dependency relationship between the third task and the first task to the task system.

[0013] This application also provides an electronic device, including: a memory and a processor; the memory is used to store one or more computer instructions; the processor is used to execute the one or more computer instructions to perform the steps in the method provided in this application.

[0014] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the method provided in this application.

[0015] This application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, causes the processor to implement the steps in the method provided in this application.

[0016] In the game frame loop task processing method provided in this application embodiment, after the task system in the game engine receives the first task submitted by the first worker thread and the dependency relationship of the first task on at least one dependent task, it can determine that the first task is in a waiting state when the at least one dependent task has not been completed. When all at least one dependent task has been completed, the first task is added to the ready task set, and the first task is read and executed by the second worker thread. In this implementation, the worker thread can suspend the task according to the task dependency relationship through the task system, and determine when to reactivate the task according to the task dependency relationship through the task system. This realizes that the worker thread can perform task scheduling, reduces the dependence on the main thread, reduces the number of interactions between the main thread and other worker threads, reduces the blocking of the main thread, and improves the task processing efficiency. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 A flowchart illustrating a task processing method for game frame looping provided as an exemplary embodiment of this application;

[0019] Figure 2 A schematic diagram of task state update provided for another exemplary embodiment of this application;

[0020] Figure 3 A schematic diagram of the architecture of a task system provided in an exemplary embodiment of this application;

[0021] Figure 4 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] During game execution, the game engine continuously runs according to the game's logic rules. The game program completes one full iteration of the game logic via the main thread, which is called completing one frame loop. Within the frame loop, some parts can be executed in parallel, thereby improving the game's running speed.

[0024] In existing technologies, the relevant logic of a game engine can be encapsulated into a series of tasks. At specific steps of the logic in each frame, the main thread submits these tasks to the corresponding thread, and the threads either synchronously wait for the tasks to complete in a blocking manner or query whether the tasks have finished executing in a non-blocking manner. However, when the relationships between tasks are complex, task scheduling cannot be implemented efficiently.

[0025] To address the aforementioned technical problems, a solution is provided in some embodiments of this application. The technical solutions provided by each embodiment of this application are described in detail below with reference to the accompanying drawings.

[0026] Figure 1 A flowchart illustrating a task processing method for game frame looping provided as an exemplary embodiment of this application is shown below. Figure 1 As shown, the method includes:

[0027] Step 101: During the game frame loop, receive the first task submitted by the first worker thread and the dependency relationship of the first task on at least one dependent task; the first task is any one of multiple tasks encapsulated from the rendering logic of any frame of the game screen.

[0028] Step 102: If at least one dependent task has not been completed, the status of the first task is updated to a waiting state.

[0029] Step 103: When all at least one dependent task has been executed, add the first task to the ready task set.

[0030] Step 104: Read the first task through the second worker thread and execute the first task.

[0031] This embodiment is executed by the task system in the game engine. As a basic module in the game engine, the task system can be called by other components in the game engine to perform task synchronization and task scheduling related logic.

[0032] During game execution, the process of running a complete game logic sequence on the main thread is called completing one frame loop. Within each frame loop, the game engine performs a series of operations according to the game logic rules, including processing user input, handling timed events, and drawing. One loop can be viewed as the process of rendering one frame of game footage (drawing). Multiple loops can execute multiple drawing operations, thus keeping the game running until its end.

[0033] During the game frame loop, to execute the rendering logic of any given frame in parallel, the rendering logic of that frame can be encapsulated into multiple tasks. The rendering logic of a single frame may include multiple calculation steps. After encapsulating the execution logic corresponding to each calculation step into a task, multiple worker threads can be used to execute the task in parallel, thereby improving the rendering efficiency of a single frame.

[0034] In some optional embodiments, the rendering logic of any frame of game footage can be encapsulated into at least one of the following tasks according to frame loop logic: particle effect calculation task, skeletal animation processing task, cloth calculation task, occlusion culling task, frustum culling task, skinning processing task, static clipping task, or rendering task. This embodiment does not impose any limitations. The first task submitted in this embodiment can be any of the above-mentioned tasks.

[0035] Based on the task system provided in this embodiment, any worker thread can submit tasks and their dependencies. A worker thread refers to a thread other than the main thread that executes the actual work tasks. Worker threads may include sub-threads or threads with specific functions, such as rendering threads or the main thread. Upon receiving a task, the task system can determine whether to suspend the task based on its dependencies, and if the task meets the execution conditions, it can continue execution as a ready task. In this embodiment, the worker thread that submits the task to the task system and the worker thread that ultimately executes the task can be the same sub-thread or different sub-threads.

[0036] In a task system, dependencies between tasks are submitted along with the tasks themselves. A dependency means that some tasks must wait for other tasks to complete before they can execute. The former are the dependent tasks of the latter, and the latter are the waiting tasks of the former. For example, consider task C. If task C can only execute after tasks A and B have completed, then tasks A and B are dependent tasks of task C, and task C is a waiting task for tasks A and B.

[0037] For example, in game applications, the logic related to each frame of a game, such as object visibility culling, updating, and rendering, can form several sets of tasks with logical dependencies. For instance, the visibility culling task is a dependent task of the update task, and the update task is a waiting task for the visibility culling task; the update task is a dependent task of the rendering task, and the rendering task is a waiting task for the update task.

[0038] In this embodiment, to facilitate task scheduling and management, the task status is divided into multiple states: unsubmitted, waiting, ready, executing, and completed. This embodiment uses the first task received by the task system as an example for illustrative explanation. The first task refers to any task to be processed received by the task system. In this embodiment, the term "first" is used to define the task, solely for ease of description and distinction, and does not impose any restrictions on the order or number of tasks received.

[0039] When the first task is not submitted, it is in an unsubmitted state. When the first task is submitted to the task system, at least one of its dependent tasks is also submitted. The task system can determine whether these dependent tasks have been completed. If not, the first task must wait for other tasks to complete before it can execute. In this case, the task's state is updated to a waiting state. A task in the waiting state can be considered a suspended task. When all at least one dependent task has been completed, the first task can be added to the ready task set, and its state will be updated to a ready state. When in the ready state, worker threads in the thread pool can retrieve the first task from the ready task set and execute it.

[0040] In this embodiment, after the task system in the game engine receives the first task submitted by the first worker thread and the dependencies of the first task on at least one dependent task, it can determine that the first task is in a waiting state while at least one dependent task has not been completed. When all at least one dependent task has been completed, the first task is added to the ready task set, and the first task is read and executed by the second worker thread. In this implementation, the worker thread can suspend tasks according to their dependencies through the task system, and determine when to reactivate the task based on these dependencies. This enables the worker thread to schedule tasks, reduces dependence on the main thread, reduces the number of interactions between the main thread and other worker threads, reduces the blocking of the main thread, and improves task processing efficiency.

[0041] In some optional embodiments, to facilitate task management, the task system can generate a wait count for each task. This wait count describes the number of other tasks that each task needs to wait for to complete. This wait count can be generated when the task system receives the dependencies for each task. Continuing with the first task as an example, optionally, when the first task is submitted to the task system, at least one of its dependent tasks is also submitted. After the task system updates the status of the first task to a waiting state, it can determine the number of at least one dependent task corresponding to the first task from its dependencies, and generate a wait count for the first task based on the number of these dependent tasks.

[0042] For example, when task C is submitted to the task system, its dependencies are also submitted: task C depends on task A and task B. Based on this dependency, the wait count for the first task is set to 2. That is, task C can only be executed after both tasks have been completed.

[0043] Once at least one dependent task is identified as the first task, the task system can decrement the wait count of the first task as each of these dependent tasks completes its execution. Continuing with the previous example, when task A completes its execution, the wait count of task C can be decremented by 1, and when task B completes its execution, the wait count of task C can be decremented by 1.

[0044] When the wait count of the first task reaches zero, the task system can add the first task to the ready task set to await execution. The ready task set stores tasks in the ready state, which can be assigned to any idle sub-thread for execution.

[0045] In some exemplary embodiments, in addition to maintaining a wait count for each task, the task system can also maintain a list of waiting tasks for each task. This list of waiting tasks records other tasks waiting for the task to complete. When the task is completed, the list of waiting tasks for that task can be traversed, and the wait count for each task in the list can be decremented.

[0046] Based on this, in some embodiments, after receiving the first task submitted by the first worker thread and the dependency relationship of the first task on at least one dependent task, the first task is added to the waiting task list of the second task for any of the at least one dependent task. Here, the second task represents any dependent task of the first task. By performing this step, the task system can record the first task in the waiting list of any dependent task it needs to wait for.

[0047] Accordingly, when the task system decrements the waiting count of the first task after at least one dependent task has been executed in sequence, it can traverse the waiting task list of the second task when the second task is completed, determine the first task waiting for the second task to be completed, and decrement the waiting count of the first task.

[0048] Continuing with the previous example, when task C is submitted to the task system, its dependencies are also specified: task C depends on both task A and task B. The task system can add task C to task A's waiting list and to task B's waiting list. After task A completes execution, task C can be identified by iterating through task A's waiting list, and its waiting count is decremented by 1. Similarly, after task B completes execution, task C can be identified by iterating through task B's waiting list, and its waiting count is decremented by 1.

[0049] In this implementation, the task system can schedule dependent tasks and notify the execution results by using a list of waiting tasks for the dependent tasks and a count of waiting tasks that depend on other tasks.

[0050] Regarding the first task, in some cases, there may be one or more other tasks that depend on the first task. In this embodiment, the other tasks that depend on the first task are described as waiting tasks of the first task.

[0051] In some exemplary embodiments, after receiving the first task submitted by the first worker thread, the task system can determine at least one waiting task for the first task. The dependency relationship between any of these waiting tasks and the first task can be obtained by the waiting task when it submits its task. That is, for task A, if task C submits its dependency relationship with task A along with task C, then task C can be determined as a waiting task for task A. After determining the at least one waiting task for the first task, it can be added to the waiting task list of the first task.

[0052] In some exemplary embodiments, after adding the first task to the ready task set to wait for execution, the task system may also traverse the at least one waiting task in the waiting task list of the first task when the first task is completed, and decrement the waiting count of each of the at least one waiting task.

[0053] For example, continuing the previous example, for task A, the waiting task list of task A includes task B and task C. When task A is completed, the task system can iterate through the waiting task list of task A, decrementing the waiting count of task B by 1, and decrementing the waiting count of task C by 1.

[0054] In some exemplary embodiments, when the first task is read and executed by the second worker thread, the task system may determine an unterminated thread from the thread pool as the second worker thread, or activate an idle thread as the second worker thread, and use the second worker thread to read the first task from the set of ready tasks and execute the first task.

[0055] It is worth noting that in this embodiment, if each thread needs to adjust the dependencies of the first task during task execution, it can resubmit the task to the task system. Continuing with the example of the second worker thread and the first task, optionally, after the second worker thread reads the first task from the ready task set and executes it, if it needs to adjust the dependencies of the first task based on the execution result of a certain stage, the second worker thread can resubmit the first task and its dependencies to the task system. The task system can then redetermine the state of the first task based on the first task and its dependencies submitted by the second worker thread; this will not be elaborated further.

[0056] It is also worth noting that in this embodiment, a reference count can be set for any task submitted to the task pool, and the lifecycle of the task can be controlled through the reference count. The reference count is used to store the number of times a task is referenced. When the task system submits any task to the task pool, it can increment the reference count of that task by 1, and decrement the reference count by 1 when the task is fully executed.

[0057] When a task's reference count reaches 0, the task can be released. For external systems (e.g., external modules using the task), the decision to release the task is based solely on its reference count, without needing to consider the specific execution stage the task is in. This further decouples task scheduling from external systems.

[0058] Based on the description of task reference counting, from the perspective of external systems, there is no need to consider the current state of the task. When the reference count of a task is not zero, it means that the task has not been released. Therefore, the task can be added as a dependent task to the set of dependent tasks when other tasks are submitted.

[0059] Continuing with the first task as an example, after the task system receives the first task submitted by the first worker thread, it can generate a reference count for the first task. When a third task needs to be submitted, a third thread can determine which third task needs to be submitted, and this third task depends on the first task. The third thread can submit the third task and its dependency on the first task to the task system when the reference count of the first task is not zero.

[0060] Optionally, in this embodiment, the type FrameTask can be defined as the base type for tasks related to game engine frame logic. The FrameTask base class encapsulates the logic related to task scheduling and provides the virtual function interface ExecuteImpl. For specific engine logic, the corresponding task type can be derived from the FrameTask type and then implemented in the ExecuteImpl member function of the derived type.

[0061] The lifecycle control of FrameTask is handled using reference counting. Each FrameTask contains an internal RefCount counter, and provides AddRefCount and SubRefCount to increment and decrement the counter. When SubRefCount is called to reduce the reference count to 0, the Task instance is actually deleted. Instances of FrameTask and its subclasses are initially counted as 1. The task system increments the reference count by 1 each time a task is submitted, and decrements it by 1 when the task is fully executed.

[0062] The following will combine Figure 2 The above embodiments of this application will be further illustrated by example.

[0063] like Figure 2 As shown, in a task system, a task can include the following states: unsubmitted, waiting, ready, executing, and completed.

[0064] The uncommitted state is the initial state of a task, which is the state a task object is in when it is first created. After the task is completed, external modules can reset the task to the uncommitted state using a reset operation, allowing the task object to be reused to handle the next task of the same type.

[0065] For a task in an uncommitted state, any thread can submit it to the task system via a commit operation. In this embodiment, the static member function of the FrameTask base class includes a SubmitToSystem function. Therefore, a thread can submit a task to the task system by calling SubmitToSystem. It's important to note that task dependencies must be submitted along with the task; dependencies between a task and other tasks cannot be set separately. This avoids external modules directly adding new dependent tasks to an already executing task, which could lead to logical inconsistencies.

[0066] When submitting a task, the system first iterates through the list of dependent tasks for the current task. Tasks that have already been completed in the dependent task list are left unprocessed. For tasks that have not yet been completed, the current task is added to its waiting list, and its waiting count is incremented. After iteration, if the waiting count of the current task is 0, its status is updated to ready, and it is added to the ready task set of the task system. If the waiting count is not 0, its status is updated to waiting. For a waiting task, once the last task it is waiting for is completed, its waiting count will decrease to 0, at which point the task can enter the ready state.

[0067] Tasks that enter the ready state are added to the ready task set of the task system. The running threads in the thread pool can take turns retrieving ready tasks from the ready task set to execute. When a new ready task is generated, the task system can check if there are any idle threads. If so, it will activate the idle thread to execute the new ready task, thereby balancing the load.

[0068] When a ready task is retrieved from the thread pool and executed, the task enters the executing state. The thread can call the Execute member function of the base class FrameTask corresponding to the task. The Execute function can call the ExecuteImpl interface to handle task-related logic.

[0069] The ExecuteImpl interface is implemented by the inheriting classes according to the specific logic. When it returns true (false), it confirms that the task has been actually completed and the thread can continue to process other tasks in the ready list. If it returns false (true), the thread needs to resubmit the task to the task system, and the task system will decide whether the task will enter the ready state or the waiting state based on the new dependent tasks of the task.

[0070] In this embodiment, the task system allows task submission operations to be performed on any thread. Therefore, the task resubmission operation can be performed before the ExecuteImpl function returns false. This allows for the adjustment of the local structure of the entire task tree based on the execution result during task execution.

[0071] Once a task is completed, its state will reach the "completed" state, at which point the task system will release the reference count it holds for that task. If no longer an external entity holds a reference count for the task object, the task object will be destroyed. When a task is in the "completed" state, it can be reset to execute other tasks of the same type.

[0072] The task system is a global variable, and internally includes a set of ready tasks and a set of thread objects. The main interfaces of the task system may include:

[0073] BeginWork Start working; only called during program initialization. EndWork End the task; only invoked when the program is closed. CommitReadyTask Submit a ready task, which is invoked by the task object. FetchReadyTask Retrieve a ready task, which is invoked by the thread object.

[0074] The structure of a task system can be as follows: Figure 3 As shown, the thread object encapsulates the functions of thread control and task scheduling. In this embodiment, although the task system itself is globally unique, there is no globally unique task scheduling mechanism. Each thread object in the task system can serve as a unit for task scheduling. Based on this implementation, blocking that was originally concentrated on a specific thread is distributed to other threads, avoiding the drawback of frequent synchronization or mutual exclusion operations between worker threads and the main thread or a specific task scheduling thread, which could lead to excessive blocking of a particular thread.

[0075] The main interface of a thread object may include:

[0076]

[0077]

[0078] The thread object interface can be called by the thread object itself and the task system. This ensures that thread activation and suspension can be executed according to a fixed process, and the internal variables of the thread object, such as the activation flag, do not need to be accessed with locks, which can also improve the running efficiency to a certain extent.

[0079] In this embodiment, the thread pool-based task scheduling system enables asynchronous task scheduling, reducing the coupling between the upper-level logic module and the task system. The upper-level logic module only needs to perform task creation and termination operations, without directly handling thread and task scheduling. Each thread in the thread pool can submit tasks, and threads can also submit other tasks during task execution, supporting more complex upper-level logic. When a thread submits a task, it submits both the task itself and its dependencies simultaneously. Task execution and dependency handling can both be performed within the worker thread, reducing the number of interactions with the main thread and other threads. Furthermore, the task system allows each task to specify its running thread in the interface parameters, or it can leave it unspecified and have the system automatically assign a thread, ensuring correct access to thread-local variables while flexibly scheduling tasks.

[0080] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 101 to 104 can be device A; or the execution subject of steps 101 and 102 can be device A, and the execution subject of step 103 can be device B; and so on.

[0081] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0082] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application. This electronic device is suitable for executing the task processing method provided in the foregoing embodiments. The electronic device runs a game engine. In the game frame loop, the rendering logic of any frame of the game screen is encapsulated into multiple tasks. The game engine includes a task system for scheduling these multiple tasks. For example... Figure 4 As shown, the electronic device includes: a memory 401, a processor 402, and a communication component 403.

[0083] Memory 401 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, contact data, phone book data, messages, pictures, videos, etc.

[0084] The memory 401 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0085] The processor 402, coupled to the memory 401, is used to execute a computer program in the memory 401 for: during a game frame loop, receiving a first task submitted by a first worker thread and the dependency relationship of the first task on at least one dependent task; if the at least one dependent task has not been completed, updating the state of the first task to a waiting state; when all at least one dependent task has been completed, adding the first task to a ready task set; and reading and executing the first task through a second worker thread.

[0086] Further optionally, the processor 402 receives a first task submitted by the first worker thread, including: receiving a particle effect calculation task, a skeletal animation processing task, a cloth calculation task, an occlusion culling task, a frustum culling task, a skinning processing task, a static clipping task, or a rendering task submitted by the first worker thread.

[0087] Further optionally, after updating the state of the first task to a waiting state, the processor 402 is further configured to: generate a waiting count for the first task based on the number of the at least one dependent task.

[0088] Further optionally, when the processor 402 adds the first task to the ready task set after all at least one dependent task has been executed, it is specifically configured to: decrement the waiting count sequentially when the at least one dependent task has been executed in sequence; and add the first task to the ready task set when the waiting count is zero.

[0089] Further optionally, after receiving the first task submitted by the first worker thread and the dependency relationship between the first task and at least one dependent task, the processor 402 is further configured to: add the first task to the waiting task list of the second task for any second task among the at least one dependent task; and sequentially decrement the waiting count when the at least one dependent task is executed in sequence, including: when the second task is completed, traversing the waiting task list of the second task, determining the first task waiting for the second task to be completed, and decrementing the waiting count of the first task.

[0090] Further optionally, after receiving the first task submitted by the first worker thread, the processor 402 is further configured to: determine at least one waiting task for the first task; and add the at least one waiting task to the waiting task list of the first task.

[0091] Further optionally, when the processor 402 reads the first task through the second worker thread and executes the first task, it is specifically configured to: determine an unterminated thread from the thread pool as the second worker thread, or activate an idle thread as the second worker thread; and use the second worker thread to read the first task from the set of ready tasks and execute the first task.

[0092] Further optionally, during the process of the processor 402 reading the first task from the ready task set and executing the first task using the second working thread, it is also used to: if it is necessary to adjust the dependency relationship of the first task, use the second working thread to resubmit the first task and the new dependency relationship of the first task to the task system.

[0093] Further optionally, after receiving the first task submitted by the first worker thread, the processor 402 task system is further configured to: generate a reference count for the first task; use a third thread to determine a third task to be submitted, wherein the third task depends on the first task; and when the reference count of the first task is not zero, use the third thread to submit the third task and the dependency relationship between the third task and the first task to the task system.

[0094] Furthermore, such as Figure 4 As shown, the electronic device also includes other components such as a display component 404, a power supply component 405, and an audio component 406. Figure 4 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 4 The components shown.

[0095] The communication component 403 is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G, or 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component may be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), Bluetooth (BT), and other technologies.

[0096] The display component 404 includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of the touch or swipe action, but also the duration and pressure associated with the touch or swipe operation.

[0097] The power supply component 405 provides power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0098] The audio component 406 can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0099] In this embodiment, after the task system in the game engine receives the first task submitted by the first worker thread and the dependencies of the first task on at least one dependent task, it can determine that the first task is in a waiting state while at least one dependent task has not been completed. When all at least one dependent task has been completed, the first task is added to the ready task set, and the second worker thread reads and executes the first task. In this implementation, the worker thread can suspend tasks based on their dependencies through the task system, and determine when to reactivate the task based on these dependencies. This enables the worker thread to schedule tasks, reduces dependence on the main thread, reduces the number of interactions between the main thread and other worker threads, reduces the blocking of the main thread, and improves task processing efficiency.

[0100] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can implement the steps that can be performed by an electronic device in the above method embodiments.

[0101] Accordingly, this application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, causes the processor to implement the steps in the method provided in this application.

[0102] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0103] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0104] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0105] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0106] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0107] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0108] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0109] It should also be noted that 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. Without further limitation, 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 said element.

[0110] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method of task processing for a game frame loop, the method comprising: In the game frame cycle, rendering logic of any frame of game picture is encapsulated as a plurality of tasks; the game engine comprises a task system for scheduling the plurality of tasks; the task system schedules the tasks by deriving corresponding tasks from a base class and implementing task scheduling related logic in a virtual function interface of the tasks; wherein the base class encapsulates task scheduling related logic and provides a virtual function interface; each base class internally comprises a reference count and provides an increase reference count function and a decrease reference count function to increase and decrease the reference count; when the task is submitted, the reference count of the task is increased by 1; when the task is completely executed, the reference count of the task is decreased by 1; the method comprises: In the game frame cycle, receiving a first task submitted by a first worker thread and a dependency relationship of the first task to at least one dependent task; If the at least one dependent task has not been executed, updating a state of the first task to a waiting state; After updating the state of the first task to the waiting state, generating a waiting count for the first task according to a number of the at least one dependent task; When the at least one dependent task is completely executed, sequentially decreasing the waiting count; when the waiting count is zero, adding the first task to a ready task set; From a thread pool, determining an un-terminated thread as a second worker thread or activating a thread in an idle state as the second worker thread; reading the first task from the ready task set by the second worker thread and executing the first task.

2. The method of claim 1, wherein, Receiving a first task submitted by a first worker thread comprises: Receiving a particle effect calculation task, a skeletal animation processing task, a cloth calculation task, an occlusion culling task, a view frustum culling task, a skinning processing task, a static clipping task, or a rendering task submitted by the first worker thread.

3. The method of claim 1, wherein, After receiving the first task submitted by the first worker thread and the dependency relationship of the first task to at least one dependent task, further comprising: For any second task in the at least one dependent task, adding the first task to a waiting task list of the second task; When the at least one dependent task is sequentially executed, sequentially decreasing the waiting count comprises: When the second task is executed, traversing the waiting task list of the second task, determining the first task waiting for the execution of the second task, and decreasing the waiting count of the first task.

4. The method of claim 1, wherein, After receiving the first task submitted by the first worker thread, further comprising: Determining at least one waiting task of the first task; Adding the at least one waiting task to a waiting task list of the first task.

5. The method of claim 1, wherein, In the process of reading the first task from the ready task set by the second worker thread and executing the first task, further comprising: If the dependency relationship of the first task needs to be adjusted, re-submitting the first task and a new dependency relationship of the first task to the task system by the second worker thread.

6. The method according to any one of claims 1 to 5, characterized in that, The task system further comprises, after receiving the first task submitted by the first worker thread: generating a reference count of the first task; determining, by a third thread, a third task to be submitted, the third task depending on the first task; submitting, by the third thread, the third task and a dependency of the third task on the first task to the task system, when the reference count of the first task is not zero.

7. An electronic device, comprising: comprising: a memory and a processor; the memory configured to store one or more computer instructions; the processor configured to execute the one or more computer instructions to perform the steps of the method of any one of claims 1-6.

8. A computer readable storage medium storing a computer program, characterized in that, A computer program that, when executed by a processor, is capable of implementing the steps of the method of any one of claims 1-6.

9. A computer program product comprising computer programs / instructions, characterized in that, A computer program that, when executed by a processor, causes the processor to implement the steps of the method of any one of claims 1-6.

Images