Method and system for distributing computing tasks between nodes of a cloud infrastructure

Abstract

Systems and methods for distributing computing tasks between nodes of a cloud infrastructure are disclosed. The method includes receiving, from a plurality of user devices executing a streamed software application, a set of application statuses, accessing a set of computing tasks, partitioning the set of computing tasks into shareable computing tasks and non-shareable computing tasks, distributing the shareable computing tasks between a first set of M nodes, distributing the non-shareable computing tasks between a second set of N nodes, merging computing outputs resulting from the execution of the shareable and non-shareable computing tasks and providing the merged computing outputs to the plurality of user devices, the merged computing outputs allowing the plurality of user devices to run the streamed software application, updated according to the application statuses specific to each user device.

Description

METHOD AND SYSTEM FOR DISTRIBUTING COMPUTING TASKS BETWEEN NODES OF A CLOUD INFRASTRUCTURETECHNICAL FIELD

[0001] The technical field relates to cloud-based computing, and more specifically to systems and methods for distributing computing tasks between nodes of a cloud infrastructure, in order to balance tasks between nodes and optimize computing resources, particularly for similar tasks that need to be performed for several devices.BACKGROUND

[0002] User devices such as mobile phones, laptops, and low-end computer systems often lack powerful graphics card or processors. Applications involving complex computing tasks (e.g. rendering) that need to be run on these devices with limited capabilities can use the additional computing resources of cloud-based architectures to achieve faster results. Examples of such applications are streamed applications such as large-scale games where a large number of players interact in a persistent online world.

[0003] In traditional cloud-based architectures, centralized servers handle game logic, manage player interactions, and synchronize game states. However, there are a few downsides, including latency issues based on server location, scalability challenges, and inefficiencies when player engagement changes.

[0004] In cloud-assisted architectures, multiplayer games leverage cloud services and globally distributed game servers to enhance the gaming experience and reduce latency for users.

[0005] Also, in a traditional cloud-based gaming scenario, each user in a multiplayer game is typically assigned a single computing node. This approach can lead to redundant rendering work and may not deliver the expected performance gains. To optimize resource utilization, reduce rendering and computation costs, and enhance scalability, there is a need to make better use of cloud architecture resources.

[0006] Therefore, a system for distributing computing tasks between nodes of a cloud infrastructure in an efficient manner in terms of computing resources may be desirable.SUMMARY

[0007] In accordance with an aspect, the present specification provides implementations of a method for distributing computing tasks between nodes of a cloud infrastructure. The method includes receiving, from a plurality of user devices executing a streamed software application, a set of application statuses of the streamed software application, accessing a set of computing tasks, the computing tasks having been generated based on the set of application statuses, partitioning the set of computing tasks into shareable computing tasks and non-shareable computing tasks, distributing the shareable computing tasks between a first set of M nodes of the cloud infrastructure, the M nodes operating in collaboration to execute the shareable computing tasks, distributing the non-shareable computing tasks between a second set of N nodes, each N node being configured to independently execute a given one of the non-shareable computing tasks, merging, by the N nodes, computing outputs resulting from the execution of the shareable and non-shareable computing tasks and providing the merged computing outputs to the plurality of user devices, the merged computing outputs allowing the plurality of user devices to run the streamed software application, updated according to the application statuses specific to each user device.

[0008] In some implementations, the computer-implemented method includes broadcasting the application statuses of the streamed software application to the M and N nodes, the M and N nodes using the application statuses in the execution of the shareable and non-shareable computing tasks.

[0009] In some implementations, the shareable computing tasks are, once executed by the M nodes, cached as computing outputs into a render cache server of the cloud infrastructure, the N nodes being configured to retrieve the computing outputs from the render cache server, the computing outputs from the M nodes being accessible by multiple ones of the N nodes.

[0010] In some implementations, the set of application statuses is indicative of a set of user commands from multiple users interacting in the streamed software application, each user using a given one of the plurality of processing devices, and at least one of the N nodes is configured to execute a first non-shareable computing task generated from an application status of a first user and a second first non-shareable computing task generated from an application status of a second user.

[0011] In some implementations, the computer-implemented method further includes, prior to distributing the sets of shareable and non-shareable computing tasks, instantiating a number of virtual machines as the M and N nodes, the number of virtual machines being decorrelated from the number of users.

[0012] In some implementations, partitioning the set of computing tasks between shareable and non-shareable computing tasks includes identifying a given computing task as a shareable computing task when said given computing task is required by several of the plurality of user devices.

[0013] In some implementations, partitioning the set of computing tasks between shareable and non-shareable computing tasks includes, for each computing task, determining whether the computing task is decomposable into a plurality of subtasks, the subtasks being executable in parallel, identifying the computing task as shareable computing task in response to determining that the computing task is decomposable, and identifying the computing as non-shareable otherwise.

[0014] In some implementations, the set of application statuses is received as a continuous stream of application statuses.

[0015] In some implementations, the streamed software application operates with a specific data format, the method including converting said specific data format into a generic data format, the computer-implemented method being usable with a variety of streamed software applications each operating with specific data formats.

[0016] In some implementations, the computer-implemented method further includes evaluating a computational weight associated with each of the shareable computing tasks, the distribution of the shareable computing tasks between the M nodes being performed according to the computational weight and available computing resources of each of the M nodes, for load balancing the computing task among the M nodes.

[0017] In some implementations, the computing tasks are rendering tasks, and wherein the streamed software application includes avatars of the users interacting in a common virtual environment.

[0018] In accordance with another aspect, the present specification provides implementations of a computer-implemented method for distributing rendering tasks between nodes of a cloud-based infrastructure for an execution of a streamed software application in which a plurality of users interact in a virtual environment. The method includes receiving, from a plurality of user devices, each associated with a given user, a set of application statuses indicative of a set of user commands, accessing a set of rendering tasks, the rendering tasks having been generated based on the set of application statuses, partitioning the set of rendering tasks into a subset of shareable rendering tasks and a subset of non-shareable rendering tasks, distributing the set of shareable rendering tasks between a first set of M nodes of the cloud infrastructure, the M nodes operating in collaboration to execute the shareable computing tasks, distributing the non-shareable rendering tasks between a second set of N nodes, each N node to independently execute a given one of the non-shareable computing tasks, merging the rendering outputs in video streams resulting from the execution of the shareable and non-shareable rendering tasks and providing individualized video streams to the respective user devices, each video stream reflecting a specific rendering of the virtual environment adapted for each of the users.

[0019] In some implementations, each of the M nodes is configured to compute rendering features based on the set of shareable rendering tasks, and each of the N nodes is configured to perform synchronization operations on the rendering features.

[0020] In some implementations, the rendering features are, once computed by the M nodes, cached into a render cache server, the N nodes being configured to retrieve the computed rendering features from the render cache server.

[0021] In some implementations, the method further includes, prior to distributing the sets of shareable and non-shareable rendering tasks, instantiating a number of virtual machines as the M and N nodes, the number of virtual machines being decorrelated from the number of users.

[0022] In some implementations, the method further includes employing a data conversion module to convert rendering features from an application-specific data format specific to the streamed software application in a generic data format understandable by the M and N nodes, and providing the rendering outputs includes employing the data conversion module to convert rendered features from the generic data format back to application-specific data format.

[0023] In some implementations, partitioning the set of rendering tasks between shareable and non-shareable rendering tasks includes identifying a given rendering task as a shareable computing task when computations relating to the rendering tasks are required by several of the plurality of user devices.

[0024] In some implementations, the shareable rendering tasks are user-independent and includes computations relating to probes, textures and / or physics of objects or characters in the virtual environment.

[0025] In some implementations, partitioning the set of rendering tasks includes, for each rendering task, determining whether the computing task is decomposable into a plurality of subtasks, the subtasks being executable in parallel, identifying the computing task as shareable computing task in response to determining that the computing task is decomposable, and identifying the computing as non-shareable otherwise.

[0026] In some implementations, distributing the set of shareable rendering tasks between M nodes includes determining available computer resources of each of the M nodes; and allocating the shareable rendering tasks to the set of M nodes based on computer resources thereof.

[0027] In some implementations, the set of application statuses is a stream of application statuses received in a continuous manner.

[0028] In accordance with yet another aspect, the present specification provides implementations of an apparatus including one or more processors and a memory storing instructions which, when executed by the one or more processors, cause the apparatus to perform the method.

[0029] In accordance with yet another aspect, the present specification provides implementations of a computer-readable storage medium having instructions stored thereon which, when executed by one or more processors, cause the one or more processors to perform the method.

[0030] In accordance with yet another aspect, the present specification provides implementations of a computer program product storing instructions which, when executed, cause an apparatus to perform the method.

[0031] In accordance with yet another aspect, the present specification provides implementations of a cloud-based architecture for providing rendering computing resources to a streamed software application in which a plurality of users interact in a virtual environment The cloud-based architecture includes a scheduler component in communication with a plurality of user devices associated with the plurality of users and a first set of M nodes and a second set of N nodes. The scheduler component includes a state synchronization module configured to receive a set of application statuses indicative of a set of user commands from the user devices and to broadcast the set of application statuses to the M and N nodes; and a task manager module configured to access a set of rendering tasks based on the set of application statuses, the rendering tasks having been generated based on the set of application statuses, partition the set of rendering tasks into a subset of shareable rendering tasks and a subset of non-shareable rendering tasks, distribute the set of shareable rendering tasks between the M nodes, the M nodes operating in collaboration to execute the shareable rendering tasks and distribute the set of non-shareable rendering tasks between the N nodes, each N node to independently execute a given one of the non-shareable rendering tasks. The N nodes are configured to merge rendered outputs resulting from the execution of the shareable and non-shareable rendering tasks and provide individualized video streams to the respective user devices, each video stream reflecting a specific rendering of the virtual environment adapted for each of the users.

[0032] In some implementations, each of the M nodes is configured to compute rendering features based on the set of shareable rendering tasks, and each of the N nodes is configured to perform synchronization operations on the rendering features.

[0033] In some implementations, the cloud-based architecture further includes a render cache server, the rendering features being, once computed by the M nodes, cached into the render cache server, the N nodes being configured to retrieve the computed rendering features from the render cache server.

[0034] In some implementations, the scheduler component is further configured to, prior to distributing the sets of shareable and non-shareable rendering tasks, instantiate virtual machines as the M and N nodes, a number of virtual machines being based on the rendering tasks and decorrelated from the number of users.

[0035] In some implementations, the cloud-based architecture further includes a data conversion module configured to convert rendering features from an application-specific data format specific to the streamed software application in a generic data format understandable by the M and N nodes.

[0036] In some implementations, the scheduler component is further configured to, upon distributing the set of shareable rendering tasks between M nodes, determine available computer resources of each of the M nodes and allocate the shareable rendering tasks to the set of M nodes based on computer resources thereof.

[0037] In some implementations, the cloud-based architecture further includes an extensible package including a set of Application Programming Interfaces (APIs) for interacting with the streamed software application, with the scheduler component and with the M and N nodes.BRIEF DESCRIPTION OF THE DRAWINGS

[0038] For a better understanding of the implementations described herein and to show more clearly how they may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings which show at least one exemplary implementation.

[0039] FIG. 1 is a schematic representation of a computing environment in accordance with some implementations of the present technology;

[0040] FIG. 2 is a block diagram of a streamed software application and a cloud-based architecture configured for distributing computing tasks to computing nodes thereof in accordance with some implementations of the present technology;

[0041] FIG. 3 is a representation of communications between computing nodes and a scheduler component of the cloud-based architecture of FIG. 2 in accordance with some implementations of the present technology;

[0042] FIG. 4 is a schematic representation of a pipeline for the generation of computing tasks in accordance with some implementations of the present technology;

[0043] FIG. 5 is a schematic representation of operations of the scheduler component of the cloud-based architecture of FIG. 2 in accordance with some implementations of the present technology;

[0044] FIG. 6 is a schematic representation of a pipeline for data format conversion in accordance with some implementations of the present technology;

[0045] FIG. 7 is a flow diagram showing operations of a method for distributing computing tasks between nodes of a cloud infrastructure in accordance with some implementations of the present technology;

[0046] FIG. 8 is a block diagram of a scheduler component in accordance with some implementations of the present technology; and

[0047] FIG. 9 is a schematic representation of interactions between components of the computing environment of FIG. 1 in accordance with some implementations of the present technology.DETAILED DESCRIPTION

[0048] It will be appreciated that, for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements or steps. In addition, numerous specific details are set forth in order to provide a thorough understanding of the exemplary implementations described herein. However, it will be understood by those of ordinary skill in the art that the implementations described herein may be practised without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the implementations described herein. Furthermore, this description is not to be considered as limiting the scope of the implementations described herein in any way but rather as merely describing the implementation of the various implementations described herein.

[0049] In the present specification, “at least one” means one or more, and “a plurality of” means two or more. The expression “and / or” describes an association relationship of associated objects, and indicates that there may be three relationships. For example, “A and / or B” includes “only A” , “both A and B” , and “only B” , where A and B may be singular or plural. The character “ / ” generally indicates that the associated objects are in an OR relationship. “At least one of the following items” or a similar expression thereof refers to any combination of these items, including any combination of a single item or a plurality of items. For example, all three of “at least one of a, b, or c” , “at least one of a, b, and c” and “at least one of a, b, and / or c” may represent “a” , “b” , “c” , “a and b” , “a and c” , “b and c” , or “a, b and c” , where a, b, and c may be a single or multiple form.

[0050] In the following description, an implementation is an example or a possible embodiment. The various appearances of "one implementation" , "an implementation" or "some implementations" do not necessarily all refer to the same implementations. Although various features may be described in the context of a single implementation, the features may also be provided separately or in any suitable combination. Conversely, although the invention may be described herein in the context of separate implementations for clarity, it may also be implemented in a single implementation. Reference in the specification to "some implementations" , "an implementation" , "one implementation" or "other implementations" means that a particular feature, structure, or characteristic described in connection with the implementations is included in at least some implementations, but not necessarily all implementations.

[0051] It is to be understood that the phraseology and terminology employed herein is not to be construed as limiting and are for descriptive purpose only. The principles and uses of the teachings of the present disclosure may be better understood with reference to the accompanying description, figures and examples. It is to be understood that the details set forth herein do not construe a limitation to an application of the disclosure.

[0052] Furthermore, it is to be understood that the disclosure can be carried out or practiced in various ways and that the disclosure can be implemented in implementations other than the ones outlined in the description above. It is to be understood that the terms "including" , "comprising" , and grammatical variants thereof do not preclude the addition of one or more components, features, steps, or integers or groups thereof and that the terms are to be construed as specifying components, features, steps or integers. If the specification or claims refer to "an additional" element, that does not preclude there being more than one of the additional element. It is to be understood that where the claims or specification refer to "a" or "an" element, such reference does not mean that there is only one of that element. It is to be understood that where the specification states that a component, feature, structure, or characteristic "may" , "might" , "can" or "could" be included, that particular component, feature, structure, or characteristic is not required to be included.

[0053] The descriptions, examples, methods and materials presented in the claims and the specification are not to be construed as limiting but rather as illustrative only. Meanings of technical and scientific terms used herein are to be commonly understood as by one of ordinary skill in the art to which the invention belongs, unless otherwise defined. It will be appreciated that the methods described herein may be performed in the described order, or in any suitable order.

[0054] It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected" or "directly coupled" to another element, there are no intervening elements present. Other words used to describe the relationship between elements should be interpreted in a like fashion (e.g., "between" versus "directly between, " "adjacent" versus "directly adjacent, " etc. ) .

[0055] The functions of the various elements shown in the figures, including any functional element labeled as a "processor" or “component” , may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. In some implementations of the present technology, the processor may be a general purpose processor, such as a central processing unit (CPU) or a processor dedicated to a specific purpose, such as a digital signal processor (DSP) . Moreover, explicit use of the term a "processor" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, application specific integrated circuit (ASIC) , field programmable gate array (FPGA) , read-only memory (ROM) for storing software, random access memory (RAM) , and non-volatile storage. Other hardware, conventional and / or custom, may also be included.

[0056] Software modules, or simply modules which are implied to be software, may be represented herein as any combination of flowchart elements or other elements indicating performance of process operations and / or textual description. Such modules may be executed as processor-executable instructions or commands, by hardware that is expressly or implicitly shown. Moreover, it should be understood that module may include for example, but without being limitative, computer program logic, computer program instructions, software, stack, firmware, hardware circuitry or a combination thereof which provides the required capabilities.

[0057] Software modules, or simply modules or units which are implied to be software, may be represented herein as any combination of flowchart elements or other elements indicating performance of process operations and / or textual description. Such modules may be executed by hardware that is expressly or implicitly shown, the hardware being adapted to (made to, designed to, or configured to) execute the modules. Moreover, it should be understood that module may include for example, but without being limitative, computer program logic, computer program instructions, software, stack, firmware, hardware circuitry or a combination thereof which provides the required capabilities.

[0058] With these fundamentals in place, we will now consider some examples to illustrate various implementations of aspects of the present technology.

[0059] In the realm of computing resources allocation and while cloud-based computing offers flexible and scalable solutions, the limitation of finite computing resources in multi-user scenarios presents ongoing challenges in terms of performance consistency, resource allocation fairness, and reliable capacity planning. In an aspect, the present technology aims at handling complex computations required by streamed applications, such as rendering scenes by low power edge devices, and provide reduced computing resource costs against the number of users.

[0060] It should be noted that, while the illustrative application of the present technology relates to rendering tasks in a multi-user cloud-based gaming scenario, other applications are envisioned in alternative implementations. Any system variation configured to distribute computing tasks across nodes in a cloud infrastructure can be adapted to execute embodiments of the present technology, once the teachings presented herein are appreciated.

[0061] In the context of the present disclosure, a computing node, or simply “node” , is a fundamental unit that serves as a computing endpoint within a distributed network of the cloud-based architecture. Each node typically consists of a physical or virtual machine (VM) implemented by processors (CPU and / or GPU) , memory, storage, and network connectivity. A given node may operate collaboratively with other nodes to execute computing tasks, process data, and run applications, contributing to the overall computational power of the cloud infrastructure. Nodes can be dynamically added, instantiated, or removed based on the current workload demands, providing scalability and flexibility. The nodes communicate with each other through network protocols to share data and distribute tasks, ensuring efficient load balancing and fault tolerance.

[0062] In the context of the present disclosure, a computing task is a discrete unit of work that may be performed by a node or a group of nodes. A computing task may include simple calculations and data processing to complex operations such as running algorithms, executing software applications, rendering graphics, or analyzing large datasets. A given computing task may include a series of instructions executable by one or more processors, often requiring input data, processing logic, and producing output results.

[0063] In the context of the present disclosure, a shareable computing task is a type of computing task that can be broken down into smaller, independent one or more subtasks, each of which can be executed simultaneously across multiple nodes. This parallelization may enable improvements in processing speed and efficiency, as it allows the workload to be divided and executed in parallel rather than sequentially. Nodes that can execute shareable tasks are referred to M nodes. For example, a given computing task may be identified as a shareable computing task when said given computing task is required by several of the plurality of user devices in parallel. For example, a shareable task may involve a calculation required to render an aspect of a game scene for several users at once.

[0064] In the context of the present disclosure, a non-shareable computing task refers to a type of computing task that cannot be efficiently divided into smaller, independent subtasks for simultaneous execution across multiple nodes within a distributed computing environment. These tasks typically involve sequential operations or dependencies that require specific order or coordination to produce correct results. Nodes that can execute shareable tasks are referred to N nodes. For example, a non-shareable task may involve a calculation required for a single user, requiring a customization unique to that user.

[0065] As will be shown in connection with the different implementations explained hereinafter, the proposed technology enables the use of a set of cloud-based nodes to better support large groups of users interacting in a common, typically streamed, software application. The technology aims to achieve a better distribution of tasks between nodes, depending on whether or not tasks can be shared between the nodes. This technology is particularly suited to graphics rendering tasks but can be easily adapted for any type of computing tasks. In particular, the technology makes it possible to decorrelate the number of nodes required relative  to the number of users (such as gamers) , and therefore enables the number of users to be scaled without necessarily having to proportionally increase the number of computing nodes.

[0066] With reference to FIG. 1, a computing environment 100 including a cloud-based architecture 120 for cloud native rendering of a virtual scene from a streamed software application is shown in accordance with an example implementation. Broadly described, the computing environment 100 includes one or more user devices 10 connected to the cloud-based architecture 120 over a communication network. Each user device 10 may be associated with a given user, such that the computing environment 100 may be referred to as a multi-user environment 100. Again, it should be noted that, while the illustrative application of the present technology is especially adapted to rendering tasks in a multi-user cloud-based streamed applications, such as multi-player gaming scenarios, and that the cloud-based architecture 120 is referred to as a “rendering” cloud-based architecture 120, other applications are envisioned in alternative implementations. As such, any system variation configured to distribute computing tasks between nodes of a cloud infrastructure for remote computing can be adapted to execute embodiments of the present technology, once teachings presented herein are appreciated.

[0067] How communication links between the user devices 10 and the cloud-based architecture 120 are implemented will depend inter alia on how the user devices 10 and the cloud-based architecture 120 are implemented. In the context of streamed multiplayer applications, user devices 10 may include laptops, smartphones, laptops, desktops, game consoles, tablets or virtual reality (VR) or augmented reality (AR) goggles / helmets. However, in other implementations, a user device 10 may be, for example and without being limitative, a network device, a camera, an enhanced general packet radio service (EGPRS) mobile phone, a network base station, a media player, a navigation device, an e-mail device, or a combination of two or more of these data processing devices or other data processing devices. Each device is equipped with one or more sensors and / or user input means to obtain sensor data and / or user input. As an example, a mobile phone can include one or more positioning sensors including one or more pose sensors such as combined gyroscope (s) and acceleration sensor (s) , and / or one or more input means such as a touchscreen configured to receive input data corresponding to positions on the screen being touched. As another example, a portable computer can include input means such as a keyboard, a mouse and / or a touchscreen. As a further example, an AR or VR device can comprise one or more positioning sensors including one or more, e.g., hand-held of head-mounted, pose sensor and / or input means, such as electromagnetic tracking device (s) , ultrasonic tracking device (s) , magnetometer (s) , gyroscope (s) and / or accelerometer (s) . Each user device 10 can include one or more memory and one or more processors to implement a number of applications which can be benefit from distributed real-time rendering. Additionally, each user device 10 can include a display, including for instance one or more monitors, a screen, a head-mounted display such as an optical see-through display or a video see-through display, a handheld display and / or a projector-based display. Advantageously, each user device 10 can include a networking device such as a Wi-FiTM adapter allowing applications to connect to a cloud-based architecture to leverage distributed real-time rendering. A given user device 10 may be, for example, a Pura 70 mobile phone from Huawei or any other mobile device whose features are similar or equivalent to the aforementioned features.

[0068] In use, the user devices 10 (101, 102, 103, 104, 105) are configured to run a streamed software application 20 (e.g. a gaming application) adapted for transmitting data to the cloud-based architecture 120 and receiving data therefrom. Broadly speaking, the streamed software application 20 is a software program designed to run at least partially on the user devices 10. The streamed software application 20 may include a wide range of functionalities, from the core gameplay mechanics and graphics rendering to user interfaces, online multiplayer support, and virtual reality integration. For example, the streamed software application 20 can provide high-quality cloud gaming leveraging distributed real-time rendering to offer high-quality, visually realistic games that run smoothly on various devices. The streamed software application may include avatars of the users interacting in a common virtual environment. As yet another example the streamed software application 20 can provide for interactive education and training using realistic, cloud-rendered simulations based on distributed real-time rendering. As yet a further example, the streamed software application 20 can provide cloud-rendered art and animation to create visually rich and complex artworks and animations without the need for expensive hardware. As yet another example, the streamed software application 20 can implement telemedicine and virtual healthcare, wherein distributed real-time rendering providing accurate lighting can facilitate remote surgery, medical training, and patient consultations, enhancing the quality of healthcare services. As yet a further example, the streamed software application 20 can provide environmental simulations, allowing researchers and policymakers to leverage distributed real-time rendering to simulate and visualize complex environmental scenarios, helping to better understand and address climate change and  conservation efforts. It can be appreciated that other applications are possible and that, in all cases, applications can be configured to transmit application statuses for remote computing (e.g. rendering) by the cloud-based architecture 120.

[0069] The cloud-based architecture 120 comprises a set or pool 150 of computer nodes 152 communicably connected to the scheduler component 110. How communication links between the computer nodes 152 and the scheduler component 110 are implemented will depend inter alia on how the computer nodes 152 and the scheduler component 110 are implemented. The computer nodes 152 may be implemented on computational devices such as servers connected by networking links and configured to operate for instance as a computational cluster or as a computational grid. The computer nodes 152 can be located in one location or distributed across different locations, but they are typically remotely located from the user devices The computer nodes can be provided by server farms which provides computer servers to provide capabilities that exceeds those of a single computer. The networking links can therefore include a combination of local and wide networks, for instance a number of local area networks connected together in a wide area network, or a number of local area networks connected together through, e.g., the Internet. The computational devices can have the same or different configurations. It can be said that the computer nodes form a computer grid of the computing environment 100 to perform computing or rendering tasks in the computing environment 100. In some implementations, the cloud-based architecture 120 may instantiate a given number of M and N nodes (whose respective functions are explained below) , which may be implemented as virtual machines. The number of M and N nodes may be decorrelated from the number of users (i.e. the number of user devices 10) . In other words, the number of N and M nodes can be different, and typically less than the number of users.

[0070] In use, the cloud-based architecture 120 receives incoming data from the user devices 10 including user instructions indicative of users’ commands on their respective user device 10. The incoming data from the user devices 10 may also include current application state of the streamed application, based on the user’s avatar’s position in a virtual environment, as an example only. The cloud-based architecture 120 may also utilize the pool 150 of nodes 152 to update the scene or virtual environment of the streamed application and / or execute user instructions, streaming the output (such as a video stream) from the nodes 152 to the end devices. Therefore, the user devices 10 leverage the computing resources of the pool 150 to perform the user instructions. Generation of the computing tasks, distribution thereof between the M and N nodes and execution thereof are described in greater detail herein after.

[0071] Broadly speaking, the M nodes are responsible for tasks whose results are shareable among users. Typically, these involve heavy computations such as rendering complex visual effects. Examples of shareable tasks include calculations related to reflection and global illumination for probe-based techniques and texture space shading and ambient occlusion for texture-based techniques. In general, a M node may be used to execute computing tasks that are relatively heavy on computational loads. The N nodes are responsible for non-shareable tasks and operations such as pre-processing, post-processing etc. In this implementation, the N nodes also take on the additional responsibilities of pulling and merging results of the M node computations and streaming the finished results to the user devices 10.

[0072] Interactions between the streamed software application 20 and the cloud-based architecture 120 is illustrated according to some implementations of the present technology on FIGS. 2 and 3. In this implementation, the streamed software application 20 may interact with an extensible package 22. An extensible package includes a set of functionalities that can be appended to a software application, so as to provide an interface to this application, enabling it to transfer the execution of tasks to the scheduler 110 and eventually to the M and N nodes 152 of the cloud infrastructure. The extensible package is designed to be used by different types of applications, without having to customize the extensible package for each application. In other words, the extensible package 22 provides seamless integration across various applications. It allows for flexible utilization, while catering to a broad array of use cases with efficiency and adaptability. The extensible package 22 encapsulates core functions, minimizing any dependencies on the application engine while also improving cross-engine compatibility. The extensible package 22 may provide encoding, decoding and engine data conversion interfaces for mainstream graphics APIs. The extensible package 22 may also handle the initialization of M and N nodes, based on the application needs.

[0073] In this implementation, the extensible package 22 includes a end-of-frame module 24, an application state collector 26, and a data conversion module 28. The end-of-frame module 24 is configured to detect an end of all the recordings of actions and changes on the corresponding user device 10 for each computing task. For example, in the example of a cloud-based gaming scenario, if an application is running at 30 frames per second, then each frame constitutes to about ～33 ms worth of actions and  changes on the user device 10. The application state collector 26 is configured to record changes related to the application’s statuses which can be any data such as, for example, position data or animation data to be transmitted over the network in a serialized manner for better efficiency. As will be explained in more detail with reference to FIG. 6, the data conversion module 28 is a module that allows converting data formats that are specific to the streamed application to generic data format that can be manipulated or processed by the components of the cloud-based architecture. For example, an online game may use a specific format to provide coordinates of the players within the game. The data conversion module 28 may be configured will translate these coordinates into a “generic” coordinate format, that will be usable by the scheduler component 110, task manager 114 and by the M and N nodes. The extensible module (which may also be referred to as an “extension module” ) , including the data conversion module, enables the proposed cloud-architecture to be used regardless of the application to support, without having to customize or adapt based on the streamed application.

[0074] In use, the streamed software application 20 transmits application statuses to a scheduler component 110 of the cloud-based architecture 120. In the context of the present application, an application status includes information about current operational state or condition of the software streamed software application 20 at a given time. In the illustrative example of gaming, the application status may be indicative of current conditions and actions performed by the user in a gaming environment provided through the corresponding user device 10, current values of characteristics (e.g. position, movements, etc. ) of the user within the gaming environment, etc. The application status may also provide information about whether the application is active, inactive, running, paused, stopped, or experiencing issues. In this implementation, the streamed software application 20 synchronizes the application statuses in the form of serialized data which can be byte data in order to increase a speed and robustness of the transmission to the scheduler component 110. This serialized data is then deserialized by the scheduler component 110 into its original form before being further processed.

[0075] In this implementation, the scheduler component 110 acts as an intermediary for the M and N nodes. The scheduler component 110 employs a state synchronization module 112 to receive the set of application statuses from the user devices and to broadcast the application statuses to the M and N nodes. The M and N nodes rely on the application statuses for executing the computing tasks accurately and timely. For example, if the computing task is to render texture of an object in a scene of a game, the M and N nodes will use the application statuses including information about a current position of the player within the scene to adjust textures and lighting seen by the player based on his / her current position. In this implementation, the application statuses are continuously shared to the computing nodes 152, such that synchronization thereof may be executed continuously, irrespective of whether or not there is any computing task to execute. In some implementations, the application statuses are shared anytime there is content change in the application (i.e. any modification, addition, or removal of elements within the game) , such that the computing nodes 152 are synchronized with the latest relevant application statuses. Interactions between instances of nodes N and M, the scheduler component 110 and the task manager 114 will be described in more detail in connection with some of the subsequent figures.

[0076] As depicted on FIG. 3, an operation loop 200 is executed once connection has been made between the M nodes 152A and the scheduler component 110, and between the N nodes 152B and the scheduler component 110 at operation 205. The operation loop 200 may be iteratively executed while the streamed software application 20 is executed on the user devices 10. For operations of the loop to be executed, initialization of the N and M nodes first need to be performed. Broadly speaking, an initialization of a given node may include connection of said node to the scheduler component 110 and / or transmission of application information to the scheduler component 110 before the node can work on a given computing task. In this implementation, the M nodes provide “application information” to the scheduler component 110. In the illustrative example of a cloud-based gaming scenario, the application information may include task weights mapped to specific parts of the scene for rendering work purposes.

[0077] In this implementation, an iteration of the operation loop 200 begin with broadcasting the application statuses (or application states) by the state synchronization module 112 of the scheduler component 110, to the M and N nodes 152A, 152B at operation 210. A task manager module 114 of the scheduler component 110 may further generate task groups based on the computing tasks to be executed at operation 220. Tasks can be grouped according to whether they include similar computations to be carried out, and whether these operations can be shared between different M nodes. The groups of tasks targeted for parallel execution are transmitted to the M nodes in step 230. Computation and / or rendering tasks are executed by nodes M in step 240,  and the computing outputs (or results) are cached in step 250. The cached computing outputs (which may correspond to rendering outputs) are forwarded to the scheduler component 110 at step 260.

[0078] Some of the rendering outputs may be forwarded as “targeted results” to the N nodes at operation 270. In this implementation, not all of the rendering outputs are transmitted to the N nodes, which increase an efficiency of the cloud-based architecture 120. For example, only the rendering outputs that should be synchronized or merged are forwarded to the N nodes. The N nodes can process the forwarded rendering outputs by combining data from different M nodes to conjointly form frame data and then serializing the data before transmission to the user device 10 by the scheduler component 110. For example, the processed results may correspond to a personalized video stream for each of the user devices, adapted according to the user's specific application status.

[0079] FIG. 4 is a flow diagram of a pipeline 300 for the distribution of computing tasks according to a possible implementation of the present technology.

[0080] In this implementation, the streamed software application 20 is configured to receive user input 310. For example, the user input 310 may include the scene information as well as the information about the task (e.g. gaming commands) and its corresponding weight. The streamed software application 20 further updates the application statuses 320 accordingly. The streamed software application 20 further generates computing tasks 322 and associated task-weights 324. Generation of the computing tasks and task-weights 324 may be, for example, performed using known processes by the streamed software application 20. How the computing tasks and task-weights 324 are generated is, in this implementation, at the discretion of a developer of the streamed software application 20. For example, in the illustrative example of a cloud-based gaming scenario that involves special lighting effects, tasks can be created corresponding to the base texture of individual objects in a given scene. The computing task here may be computing a final look of the object using the lighting conditions and the texture data. In some implementations, the task weight of a given computing task corresponds to the texture size of an object of the computing size. The skilled person would readily understand that the larger the texture is, the heavier the task weight is (i.e., requires more computation power) . As will be described in greater details herein after, the scheduler component 110 may further generate subtasks from the received computer tasks.

[0081] For example, the streamed software application 20 may determine that, based on user’s commands, a user device requires computations related to shading, which can be computed by a Texture Space Shading (TSS) function of GPUs. A corresponding computing task is then generated by the application and transmitted from the user device 10 to the scheduler component 110. More specifically, the computing task may include information such as the scene space in question converted to a texture, with the size of the texture affecting the task-weight and the amount of work units required to achieve the desired effects.

[0082] The scheduler component 110 further accesses data 326 including information about availability of the nodes 152 (which may be implemented on GPUs) . In other words, current workloads of the nodes 152 are assessed by the scheduler component 110 to determine their availability, so as to assign computing tasks to the nodes based on their availability. At operation 330, the scheduler component 110 may group the computing tasks based on their corresponding task-weights to form a list of task groups 340. For example, scheduler component 110 may group the computing tasks based on a minimum cumulative weight criteria into a number of groups equalling the number of computing nodes available for task processing. This may be beneficial for load balancing, as it may help in reducing the difference in total task load assigned to any two nodes.

[0083] Referring back to FIG. 2 and 3, the task manager module 114 of the scheduler component 110 accesses the computing tasks and the list of task groups 340, and distribute the computing tasks to the computer nodes 152. As depicted on FIG. 3, the scheduler component 110 distribute the task groups including the computing tasks to the M nodes 152A at operation 230.

[0084] In the illustrative example of rendering a multi-user cloud-based gaming scenario, the M nodes 152A are configured to process bytes data that will be used to construct the final frame / rendered object, while the N nodes are configured to generate a final output frame / rendered object. As depicted on FIG. 3, the M nodes 152A execute the computing tasks at operation 240 and may further cache outputs of the execution at operation 250.

[0085] In this implementation, the scheduler component 110 identifies shareable tasks and distribute them to the M nodes 152A. The scheduler component 110 may evaluate a computational weight associated with each of the shareable computing tasks, the distribution of the shareable computing tasks between the M nodes 152A being performed according to available computing resources of each of the M nodes 152A, for load balancing the computing task among the M nodes 152A.

[0086] Examples of computing tasks in the illustrative example of a multi-user cloud-based gaming scenario may include rasterization, ray tracing, texture mapping, collision detection, body dynamics, etc. The M nodes 152A may use the application statuses to accurately execute the computing tasks. In this implementation, the scheduler component 110 determines whether the computing task is decomposable into a plurality of subtasks, the subtasks being executable in parallel. The scheduler component 110 identifies the computing task as shareable computing task in response to determining that the computing task is decomposable, and identifies the computing as non-shareable otherwise.

[0087] The scheduler component 110 thus handles connections, load balancing, task scheduling, and disconnections, optimizing communication for maximum efficiency. The computing work allocation to various computing nodes is done to ensure an equitable distribution. This ensures efficient synchronization and distribution of computation results to the user devices 10.

[0088] With additional reference to FIG. 5, each of the M node 152 includes a render module 154 and a render cache 156 configured to store data computed by the M node 152A. In some implementation, the M nodes 152A may be communicably connected to a common a render cache server 157, such that cache resources thereof may be shared by the plurality of M nodes 152A. In this implementation, the shareable computing tasks are, once executed by the M nodes, cached as computing outputs into a render cache server 157 of the cloud infrastructure.

[0089] In some implementation, a given M nodes 152A may employ its corresponding render cache 156 to perform similar computing tasks by re-using data stored within the render cache 156. The present technology thus implements single-render caching to minimize overhead calculation by caching the rendered output so that it can be reused for subsequent requests (e.g. subsequent similar computing tasks) . Data stored within a render cache of a first M node may be shared to a second M node to perform a computing task based on said data.

[0090] Referring back to FIGS. 2 and 3, the scheduler component 110 further accesses the cached outputs at operation 260 and transmits the cached outputs of the M nodes 152A to the N nodes 152B at operation 270. In some implementations, the N nodes 152B are configured to retrieve the computing outputs from the render cache server 157 as shown on FIG. 2, the computing outputs from the M nodes 152A being accessible by multiple ones of the N nodes 152B.

[0091] The N nodes 152B are configured to independently execute a given one of the non-shareable computing tasks. In this implementation, at least one of the N nodes is configured to execute a first non-shareable computing task generated from an application status of a first user and a second first non-shareable computing task generated from an application status of a second user. Information of computation and rendering may thus be shared between multiple users by the N nodes 152B.

[0092] Deviating from the conventional one-to-one mapping of client and server relation, the present technology thus optimizes computational resources by enabling a single computing node (e.g. a server) to proficiently serve multiple users. The direct effect of this aspect is the efficient utilization of resources and as a result, substantial cost savings. The streamed software application 20 and, on a larger scale, the computing environment 100, are able to service more users without compromising on the user experience. Additionally, results produced by any single computing node may be relevant to more than one user, thus cutting out costly redundant computations.

[0093] In use, the N nodes 152B merge, or “synchronize” , the outputs of the M nodes 152A, thereby generating merged computing outputs at operation 280 of the operation loop 200 (see FIG. 3) . FIG. 9 illustrates the operation loop 200 in a more detailed manner. Notably, the extensible package 22 may function similarly to a Software Development Kit (SDK) on the user devices 10 in some implementations. The user devices only interacts with the extensible package when it needs to send application status or data, or when a rendered image is received from the cloud-based architecture. The extensible package may include Application Programming Interface (API) instances, such as API_Implementation, which is the entry point of the user device 10 to the cloud-based architecture 120. This API instance further establish a connection with the scheduler component 100 before an execution of the loop 200.

[0094] As previously described, the rendering task are sent from the scheduler component to the M nodes, which, in this implementation, further transmit the rendered data to a core API, responsible of forwarding the rendered data to the API instance. The rendered data are further enqueued to be encoded by the extensible package 22. The encoded rendered data are called back to the M nodes and further cached in the render cache server 157 and transmitted to the scheduler component 110. The scheduler component further transmits the rendering outputs to the core API which may further forward some of the rendering outputs to the N nodes for further processing. Outputs of the N nodes may further be transmitted to the core API and further forwarded to the API  instance. In this implementation, the extensible package 22 may also request the rendering outputs to the render cache server 157, and, in response to receiving the rendering outputs therefrom, enqueue the rendering outputs for decoding, and transmits the decoded data to the N nodes, which unpack the received data.

[0095] The cloud-based architecture 120 further provides the merged computing outputs to the user devices 10, thereby allowing the user devices 10 to run the streamed software application 20, updated according to the application statuses specific to each user device 10. The merged computing outputs may be for example video streams.

[0096] Therefore, the cloud-based architecture 120 implements centralized scheduling and task allocation for rendering load balancing. The cloud-based architecture 120 may provide maximization of the utilization of cloud-side computing power in order to foster shared rendering among multiple user devices. Overall, the architecture of cloud-based architecture 120 is designed to enable the creation of enhanced user experiences, across a variety of user devices 10, irrespective of their individual capabilities –through a many-to-many cloud native rendering solution.

[0097] FIG. 6 illustrates a data conversion pipeline 600 according to some implementations of the present technology. The data conversion pipeline 600 enables the present technology to be applicable across different streamed software applications without the need for extensive changes.

[0098] The data conversion pipeline may be used for different applications having their own standards in terms of data format. First, data 610 from the user device 10 are accessed, the data 610 having a specific data format. In this illustrative example, data 610 are related to a texture of a scene of a given user in a multi-user cloud-based gaming scenario. The streamed software application 20 further executes a data conversion module 620 to convert a data format of the data 610 from the specific data format into a generic data format. The converted data 630 are further transmitted to the cloud-based architecture 120 for remote computing. An output 640 of said computing is further provided back from the cloud-based architecture 120 to the user device 10, where the streamed software application 20 further executes the data conversion module to convert a data format of the output 640 from the generic data format into the specific data format for further use by the user device 10.

[0099] The barrier of inter-application data transmission may be alleviated using the data conversion pipeline 600. The data conversion pipeline 600 may thus be used ensures the correct and effective data transfer between various applications. In this implementation, the data conversion pipeline 600 manages all the intricate processes such as input data gathering as well as segmentation and condensation of data, through a set of user-friendly APIs. This gives a universal behavior and ensures compatibility across different software streamed applications while also avoiding extensive changes. It helps the solution to remain agnostic of local standards observed by different applications in their implementations, thus alleviating the barrier of inter-application data transmission. The cloud-based architecture 120 is thus usable with a variety of streamed software applications each operating with specific data form.

[0100] FIG. 7 is a flow diagram of a method 700 for distributing computing tasks between nodes of a cloud infrastructure according to some implementations of the present technology. In one or more aspects, the method 1100 or one or more steps thereof may be performed by a processor or a computer system, such as the cloud-based architecture 120. The method 700 or one or more steps thereof may be embodied in computer-executable instructions that are stored in a computer-readable medium, such as a non-transitory mass storage device, loaded into memory and executed by a CPU. Some steps or portions of steps in the flow diagram may be omitted or changed in order.

[0101] In this example, the computing tasks are rendering tasks, and the streamed software application includes avatars of the users interacting in a common virtual environment. Other types of computing tasks and streamed software applications are contemplated in alternative implementations.

[0102] The method 700 starts with receiving, at operation 710, a set of application statuses of the streamed software application from a plurality of user devices executing a streamed software application. The set of application statuses is indicative of a set of user commands from multiple users interacting in the streamed software application, each user using a given one of the plurality of processing devices. The application statuses may be received as a continuous stream of application statuses.

[0103] The method 700 continues with accessing, at operation 720, a set of computing tasks, the computing tasks having been generated based on the set of application statuses (e.g. by the streamed software application) .

[0104] In some implementations, the streamed software application operates with a specific data format, the method inlcuding converting said specific data format into a generic data format, the computer-implemented method being usable with a variety of streamed software applications each operating with specific data formats.

[0105] The method 700 continues with partitioning, at operation 730, the set of computing tasks into shareable computing tasks and non-shareable computing tasks. In some implementations, a number of virtual machines as the M and N nodes are instantiated, the number of virtual machines being decorrelated from the number of user devices.

[0106] The method 700 continues with distributing, at operation 740, the shareable computing tasks between a first set of M nodes of the cloud infrastructure, the M nodes operating in collaboration to execute the shareable computing tasks. In this implementation, the shareable computing tasks are, once executed by the M nodes, cached as computing outputs into a render cache server of the cloud infrastructure, the N nodes being configured to retrieve the computing outputs from the render cache server, the computing outputs from the M nodes being accessible by multiple ones of the N nodes.

[0107] In some implementations, partitioning the set of computing tasks between shareable and non-shareable computing tasks may be performed identifying a given computing task as a shareable computing task when said given computing task is required by several of the plurality of user devices. In the same or other implementations, the partitioning may be performed by, for each computing task, determining whether the computing task is decomposable into a plurality of subtasks, the subtasks being executable in parallel, identifying the computing task as shareable computing task in response to determining that the computing task is decomposable and identifying the computing as non-shareable otherwise.

[0108] The method 700 continues with distributing, at operation 750, the non-shareable computing tasks between a second set of N nodes, each N node being configured to independently execute a given one of the non-shareable computing tasks.

[0109] In this implementation, the application statuses of the streamed software application are also broadcasted to the M and N nodes, the M and N nodes using the application statuses in the execution of the shareable and non-shareable computing tasks.

[0110] In the same or another implementation, at least one of the N nodes is configured to execute a first non-shareable computing task generated from an application status of a first user and a second first non-shareable computing task generated from an application status of a second user.

[0111] The method 700 continues with merging, at operation 760, computing outputs resulting from the execution of the shareable and non-shareable computing tasks by the N nodes.

[0112] The method 700 continues with providing, at operation 770, the merged computing outputs to the plurality of user devices, the merged computing outputs allowing the plurality of user devices to run the streamed software application, updated according to the application statuses specific to each user device.

[0113] As an example, the method 700 may be used to provide rendering computing resources to streamed software application in which a plurality of users interact in a virtual environment, such as a video game. In this example, a number X of users, or “players” , are able to control their character’s position, animation and other game features, which correspond to the aforementioned application status. At the end of each frame of the video game, this data is collected, serialized and sent over the network to the cloud-based architecture 120 where it will be transmitted on the M and N nodes and synchronized with the users’ devices. In this example, a subset of Y users may require an effect within the video game, for example a light reflection on an item within the video game. The determination of the light reflection corresponds, in this example, to an aforementioned computing task. For this required effect, the user devices will make a request for the reflection effect, and provide information about the current position / scene and weights. Using this data, the scheduler may divide the task based on the total number of M nodes available in such a way to execute the task in an optimal manner, which correspond to the aforementioned partitioning and distribution of the computing tasks. Once the M nodes have performed the tasks and transmitted the outputs to the scheduler component 110, the scheduler component 110 may forward the results to the N nodes that will be responsible to generating the final frame that will be provided to the user device with the light reflection, which corresponds to the aforementioned merging of the computing outputs. The N nodes will then forward the final frame back to the user devices.

[0114] It will be appreciated that at least some of the operations of the method 700 may also be performed by computer programs, which may exist in a variety of forms, both active and inactive. Such as, the computer programs may exist as software program (s) comprised of program instructions in source code, object code, executable code or other formats. Any of the above may be embodied on a computer readable medium, which include storage devices and signals, in compressed or uncompressed form.  Representative computer readable storage devices include conventional computer system RAM (random access memory) , ROM (read only memory) , EPROM (erasable, programmable ROM) , EEPROM (electrically erasable, programmable ROM) , and magnetic or optical disks or tapes. Representative computer readable signals, whether modulated using a carrier or not, are signals that a computer system hosting or running the computer program may be configured to access, including signals downloaded through the Internet or other networks. Concrete examples of the foregoing include distribution of the programs on a CD ROM or via Internet download. In a sense, the Internet itself, as an abstract entity, is a computer readable medium. The same is true of computer networks in general.

[0115] The present technology may be applied across any cloud-based system that makes use of multiple GPUs to provide high fidelity graphics and fast calculations across a variety of end users’ devices. Products such as Cloud GPU products, multiple GPU Game Engines, and many more.

[0116] As an example, FIG. 8 is a schematic block diagram of the scheduler component 110 of the cloud-based architecture 120 according to an implementation of the present technology. The scheduler component 110 includes a processor or a plurality of cooperating processors (represented as a processor 820 for simplicity) , a memory device or a plurality of memory devices (represented as a memory device 822 for simplicity) , and an input / output interface 830 allowing the scheduler component 110 to communicate with other components of the cloud-based architecture 120 and / or other components in remote communication with the cloud-based architecture 120. The processor 820 is operatively connected to the memory device 822 and to the input / output interface 830. The memory device 822 includes a storage for storing parameters 824. The memory device 822 may include a non-transitory computer-readable medium for storing code instructions 826 that are executable by the processor 820 to allow the scheduler component 110 to perform the various tasks allocated to the scheduler component 110 in the methods disclosed therein.

[0117] It is to be understood that the operations and functionality of the described scheduler component 110 and the cloud-based architecture 120, their constituent components, and associated processes may be achieved by any one or more of hardware-based, software-based, and firmware-based elements. Such operational alternatives do not, in any way, limit the scope of the present disclosure.

[0118] Several alternative implementations and examples have been described and illustrated herein. The implementations described above are intended to be exemplary only. It will be appreciated that the methods described herein can be performed in the described order, or in any suitable order. A person with common technical knowledge would appreciate the features of the individual implementations, and the possible combinations and variations of the components. A person of common technical knowledge would further appreciate that any of the implementations could be provided in any combination with the other implementations disclosed herein. It is understood that the product can have other specific forms without departing from the central characteristics thereof. The present examples and implementations, therefore, are to be considered in all respects as illustrative and not restrictive, and the product is not to be limited to the details given herein. Accordingly, while the specific implementations have been illustrated and described, numerous modifications come to mind. The scope of the product is therefore intended to be limited solely by the scope of the appended claims.

Claims

1.A computer-implemented method for distributing computing tasks between nodes of a cloud infrastructure, the method comprising:receiving, from a plurality of user devices executing a streamed software application, a set of application statuses of the streamed software application;accessing a set of computing tasks, the computing tasks having been generated based on the set of application statuses;partitioning the set of computing tasks into shareable computing tasks and non-shareable computing tasks;distributing the shareable computing tasks between a first set of M nodes of the cloud infrastructure, the M nodes operating in collaboration to execute the shareable computing tasks;distributing the non-shareable computing tasks between a second set of N nodes, each N node being configured to independently execute a given one of the non-shareable computing tasks;merging, by the N nodes, computing outputs resulting from the execution of the shareable and non-shareable computing tasks; andproviding the merged computing outputs to the plurality of user devices, the merged computing outputs allowing the plurality of user devices to run the streamed software application, updated according to the application statuses specific to each user device.2.The computer-implemented method of claim 1, further comprising broadcasting the application statuses of the streamed software application to the M and N nodes, the M and N nodes using the application statuses in the execution of the shareable and non-shareable computing tasks.3.The computer-implemented method of claim 1 or 2, wherein the shareable computing tasks are, once executed by the M nodes, cached as computing outputs into a render cache server of the cloud infrastructure, the N nodes being configured to retrieve the computing outputs from the render cache server, the computing outputs from the M nodes being accessible by multiple ones of the N nodes.4.The computer-implemented method of any one of claims 1 to 3, wherein:the set of application statuses is indicative of a set of user commands from multiple users interacting in the streamed software application, each user using a given one of the plurality of processing devices, andat least one of the N nodes is configured to execute a first non-shareable computing task generated from an application status of a first user and a second first non-shareable computing task generated from an application status of a second user.5.The computer-implemented method of claim 4, further comprising, prior to distributing the sets of shareable and non-shareable computing tasks:instantiating a number of virtual machines as the M and N nodes, the number of virtual machines being decorrelated from the number of users.6.The computer-implemented method of any one of claims 1 to 5, wherein partitioning the set of computing tasks between shareable and non-shareable computing tasks comprises identifying a given computing task as a shareable computing task when said given computing task is required by several of the plurality of user devices.7.The computer-implemented method of any one of claims 1 to 6, wherein partitioning the set of computing tasks between shareable and non-shareable computing tasks comprises, for each computing task:determining whether the computing task is decomposable into a plurality of subtasks, the subtasks being executable in parallel;identifying the computing task as shareable computing task in response to determining that the computing task is decomposable;identifying the computing as non-shareable otherwise.8.The computer-implemented method of any one of claims 1 to 7, wherein the set of application statuses is received as a continuous stream of application statuses.9.The computer-implemented method of any one of claims 1 to 8, wherein the streamed software application operates with a specific data format, the method further comprising converting said specific data format into a generic data format, the computer-implemented method being usable with a variety of streamed software applications each operating with specific data formats.10.The computer-implemented method of any one of claims 1 to 9, further comprising evaluating a computational weight associated with each of the shareable computing tasks, the distribution of the shareable computing tasks between the M nodes being performed according to the computational weight and available computing resources of each of the M nodes, for load balancing the computing task among the M nodes.11.The computer-implemented method of claim 4, wherein the computing tasks are rendering tasks, and wherein the streamed software application comprises avatars of the users interacting in a common virtual environment.12.A computer-implemented method for distributing rendering tasks between nodes of a cloud-based infrastructure for an execution of a streamed software application in which a plurality of users interact in a virtual environment, the method comprising:receiving, from a plurality of user devices, each associated with a given user, a set of application statuses indicative of a set of user commands;accessing a set of rendering tasks, the rendering tasks having been generated based on the set of application statuses;partitioning the set of rendering tasks into a subset of shareable rendering tasks and a subset of non-shareable rendering tasks;distributing the set of shareable rendering tasks between a first set of M nodes of the cloud infrastructure, the M nodes operating in collaboration to execute the shareable computing tasks;distributing the non-shareable rendering tasks between a second set of N nodes, each N node to independently execute a given one of the non-shareable computing tasks;merging the rendering outputs in video streams resulting from the execution of the shareable and non-shareable rendering tasks; andproviding individualized video streams to the respective user devices, each video stream reflecting a specific rendering of the virtual environment adapted for each of the users.13.The computer-implemented method of claim 12, wherein:each of the M nodes is configured to compute rendering features based on the set of shareable rendering tasks, andeach of the N nodes is configured to perform synchronization operations on the rendering features.14.The computer-implemented method of claim 13, wherein the rendering features are, once computed by the M nodes, cached into a render cache server, the N nodes being configured to retrieve the computed rendering features from the render cache server.15.The computer-implemented method of any one of claims 12 to 14, further comprising, prior to distributing the sets of shareable and non-shareable rendering tasks:instantiating a number of virtual machines as the M and N nodes, the number of virtual machines being decorrelated from the number of users.16.The computer-implemented method of any one of claims 12 to 15, further comprising:employing a data conversion module to convert rendering features from an application-specific data format specific to the streamed software application in a generic data format understandable by the M and N nodes, andproviding the rendering outputs comprises employing the data conversion module to convert rendered features from the generic data format back to application-specific data format.17.The computer-implemented method of any one of claims 12 to 16, wherein partitioning the set of rendering tasks between shareable and non-shareable rendering tasks comprises identifying a given rendering task as a shareable computing task when computations relating to the rendering tasks are required by several of the plurality of user devices.18.The computer-implemented method according to claim 17, wherein the shareable rendering tasks are user-independent and comprises computations relating to probes, textures and / or physics of objects or characters in the virtual environment.19.The computer-implemented method of any one of claims 12 to 18, wherein partitioning the set of rendering tasks comprises, for each rendering task:determining whether the computing task is decomposable into a plurality of subtasks, the subtasks being executable in parallel;identifying the computing task as shareable computing task in response to determining that the computing task is decomposable;identifying the computing as non-shareable otherwise.20.The computer-implemented method of any one of claims 12 to 19, wherein distributing the set of shareable rendering tasks between M nodes comprises:determining available computer resources of each of the M nodes; andallocating the shareable rendering tasks to the set of M nodes based on computer resources thereof.21.The computer-implemented method of any one of claims 12 to 18, wherein the set of application statuses is a stream of application statuses received in a continuous manner.22.An apparatus comprising one or more processors and a memory storing instructions which, when executed by the one or more processors, cause the apparatus to perform the method according to any one of claims 1-11 or 12-21.23.A computer-readable storage medium having instructions stored thereon which, when executed by one or more processors, cause the one or more processors to perform the method of any one of 1-11 or 12-21.24.A cloud-based architecture for providing rendering computing resources to a streamed software application in which a plurality of users interact in a virtual environment, the cloud-based architecture comprising:a scheduler component in communication with a plurality of user devices associated with the plurality of users; anda first set of M nodes and a second set of N nodes;the scheduler component comprising:a state synchronization module configured to receive a set of application statuses indicative of a set of user commands from the user devices and to broadcast the set of application statuses to the M and N nodes; anda task manager module configured to:access a set of rendering tasks based on the set of application statuses, the rendering tasks having been generated based on the set of application statuses,partition the set of rendering tasks into a subset of shareable rendering tasks and a subset of non-shareable rendering tasks;distribute the set of shareable rendering tasks between the M nodes, the M nodes operating in collaboration to execute the shareable rendering tasks; anddistribute the set of non-shareable rendering tasks between the N nodes, each N node to independently execute a given one of the non-shareable rendering tasks,the N nodes being configured to:merge rendered outputs resulting from the execution of the shareable and non-shareable rendering tasks; andprovide individualized video streams to the respective user devices, each video stream reflecting a specific rendering of the virtual environment adapted for each of the users.25.The cloud-based architecture of claim 24, wherein:each of the M nodes is configured to compute rendering features based on the set of shareable rendering tasks, andeach of the N nodes is configured to perform synchronization operations on the rendering features.26.The cloud-based architecture of claim 25, further comprising a render cache server, the rendering features being, once computed by the M nodes, cached into the render cache server, the N nodes being configured to retrieve the computed rendering features from the render cache server.27.The cloud-based architecture of any one of claims 24 to 26, wherein the scheduler component is further configured to, prior to distributing the sets of shareable and non-shareable rendering tasks:instantiate virtual machines as the M and N nodes, a number of virtual machines being based on the rendering tasks and decorrelated from the number of users.28.The cloud-based architecture of any one of claims 24 to 27, comprising a data conversion module configured to convert rendering features from an application-specific data format specific to the streamed software application in a generic data format understandable by the M and N nodes.29.The cloud-based architecture of any one of claims 24 to 28, wherein the scheduler component is further configured to, upon distributing the set of shareable rendering tasks between M nodes:determine available computer resources of each of the M nodes; andallocate the shareable rendering tasks to the set of M nodes based on computer resources thereof.30.The cloud-based architecture of any one of claims 24 to 29, comprising an extensible package including a set of Application Programming Interfaces (APIs) for interacting with the streamed software application, with the scheduler component and with the M and N nodes.

Images