A method for starting a large number of game instances at different levels on a cloud platform

Abstract

A system and method for efficiently sharing memory space in cloud-based applications are described. Data that can be shared among multiple instances of an application is identified, and dedicated memory space is allocated to this data. Whether data is shareable is determined based on its content to avoid corruption and irregular allocation. When data sharing is required, processing circuitry determines whether the data is already in use by another application instance. If so, a shared memory containing the data is identified, and the shared memory's reference counter is updated. If no other application instance is currently using the data, the selected shared memory is assigned to the data, and the data is copied from its dedicated memory space to the selected shared memory. In either case, the original memory space is released, thus ensuring efficient memory usage.

Description

Background Technology

[0001] Description of related technologies In cloud application setups, users can establish connections to applications (such as video game servers) via the internet using devices with regular internet connectivity (such as smartphones or tablets). The application initiates an instance for that user, and this can also be applied to multiple users. For example, the video game server can generate visual frames of content and produce audio in response to player actions (such as movement and selection) and other game-related attributes. The encoded video and audio are then sent via the internet to the player's device, where they are displayed as visible images and audible sounds. Because of this method, players from anywhere in the world can participate in video games without the need for dedicated video game consoles, specific software, or dedicated graphics processing hardware.

[0002] In some cloud-based applications, it may be necessary to use, for example, a single GPU to concurrently launch more than a hundred instances of the application for different users. Each such instance can consume major blocks of GPU memory, causing a rapid performance degradation, for example, as the SDMA engine may become extremely busy allocating pages from system memory to GPU memory to access relevant data. To make the system more efficient, for example, when using the same image to run the same scene, GPU memory can be shared among different instances of the application to reduce memory footprint. However, this memory sharing can cause corruption, especially when application instances are running at different levels (e.g., different levels in a video game).

[0003] In light of the above, there is a need for improved systems and methods to provide memory sharing for different application instances. Attached Figure Description

[0004] The advantages of the methods and mechanisms described herein can be better understood by referring to the following description in conjunction with the accompanying drawings, in which: Figure 1 This is a block diagram illustrating an exemplary network implementation of a cloud application system.

[0005] Figure 2 This is a block diagram illustrating exemplary implementations of various components of a cloud application system.

[0006] Figure 3 This is a block diagram illustrating memory sharing during multiple application instances.

[0007] Figure 4 This is a block diagram illustrating different application instances of cloud-based applications.

[0008] Figure 5This is an exemplary method for sharing data blocks among multiple application instances based on the content of the data blocks. Detailed Implementation

[0009] In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, those skilled in the art will recognize that various specific implementations can be practiced without these specific details. In some instances, well-known structures, components, signals, computer program instructions, and techniques have not been shown in detail to avoid obscuring the methods described herein. It should be understood that, for simplicity and clarity, the elements shown in the accompanying drawings are not necessarily drawn to scale. For example, the dimensions of some of these elements may be enlarged relative to others.

[0010] Systems, apparatus, and methods for efficiently sharing memory space in cloud-based applications are described. In one embodiment, blocks of data can be shared between multiple application instances (e.g., different levels of a game running on different client devices). In one example, data is shared based on its content rather than its attributes to avoid corruption and irregular allocation. Data deemed shareable is identified, and dedicated memory space is allocated to such data. When data sharing is required, processing circuitry determines whether the data is already in use by another application instance. In one embodiment, if the data is already in use, a shared memory storing the data is identified, and the reference counter of that shared memory is updated. In another embodiment, if no other application instance is currently using the data, a selected shared memory is assigned to the data, and the data is copied from its dedicated memory space to that selected shared memory. In either condition, the original memory space is released, thus ensuring efficient memory usage.

[0011] In one specific implementation, an "application instance," as described below, refers to a single occurrence or instantiation of an application running on a computing system. For example, in the context of software development and deployment, an application instance represents a single running copy of an application that may encompass all components, processes, and data of that application, interacting with users or other systems to achieve the intended purpose of the application. Each application instance is isolated from and operates independently of other application instances. It has its own memory space, resources, and runtime environment. For example, for a web application, a new instance of the application is created each time a user accesses the application through a web browser to handle that user's interaction. Similarly, in a cloud computing or server environment, multiple instances of an application may execute concurrently to handle different user requests or tasks.

[0012] In one implementation, an application instance may include an instance of a game application. To interact with an instance of a game application, a player connects to a game server via a network connection on their personal computer, game console, or mobile device. For example, a user may join a virtual environment or game world in which they can interact with other players who are also connected to the same server. The game process of an application instance begins when a player logs into the game and ends when the player logs out or disconnects from the server. In the following description, the terms "application instance" and "instance" are used interchangeably.

[0013] In one specific implementation, as described herein, data blocks can be “shared” among multiple application instances. That is, the contents of a given data block (such as an image) can be used simultaneously (e.g., using parallel processing) by multiple rendering (or other) tasks to generate graphical outputs on multiple client devices running different application instances. These outputs can be similar (e.g., a scene rendered in a game with only a single level) or different (e.g., a scene rendered during different levels of a complex game). In another specific implementation, the “shared memory block” described herein refers to a memory location or memory “block” that can be accessed by multiple processes or tasks such that these processes can share data (e.g., data blocks) by accessing the shared memory block (i.e., the same memory block). In this way, shared memory locations (or blocks) enable data sharing. In various specific implementations, unless otherwise indicated, the discussion of shared memory blocks implies the sharing of data (or data blocks) stored within the memory block.

[0014] Figure 1 This is a block diagram illustrating an exemplary network implementation of a cloud application system. As shown, computing system 102 (optionally referred to as cloud application system 102 or simply application system 102) is connected to multiple client devices 104A to 104N (hereinafter also referred to as user devices 104A to 104N) via network 106. In one implementation, application system 102 is configured to establish an application instance of an application in response to a request (i.e., user input) from a given user device 104 to facilitate interaction between user device 104 and the application. For example, application system 102 may receive user input from user device 104 for accessing a cloud gaming application. In response to receiving the input, application system 102 is configured to provide user device 104 with access to the requested instance of the cloud gaming application. In one implementation, a peer-to-peer (P2P) connection is established between user device 104 and cloud application system 102 to enable the user device to interact remotely with the application instance. For example, as shown in the figure, a P2P connection 130 is established between the cloud application system 102 and the user equipment 104A.

[0015] In one implementation, a given user device 104 is any device configured to communicate wirelessly and / or wiredly with application system 102 via a network (such as network 106). In one example, multiple user devices 104A to 104N include one or more of mobile devices, personal computers, laptops, game consoles, etc. In another implementation, user device 104 is configured to request application system 102 to execute a desired application when user device 104 is unable to host the application locally due to a lack of necessary infrastructure and / or computing resources.

[0016] For example, user device 104 may send a request to application system 102 to connect to a cloud gaming application to access a desired game name. Application system 102 identifies the user associated with user device 104 by accessing user account information stored in a user data repository (e.g., user database 110). Application system 102 verifies the identified user to determine one or more game names that user device 104 is authorized to access. In one implementation, application system 102 interacts with application database 112 to determine one or more game names that user device 104 is authorized to access. When it is determined that user device 104 is authorized to access a game name, application system 102 establishes a network connection for user device 104 to allow user device 104 to remotely control an instance of the game process using one or more user interfaces (not shown) generated at user device 104.

[0017] In one embodiment, application system 102 may include at least a CPU 112, a GPU 114, and system memory 116, as well as other components (not shown for brevity). GPU 114 also includes memory management circuitry 118 (optionally referred to as MMC 118) and GPU memory 120. In one or more embodiments, when multiple instances of a single application are running on different client devices 104A, each client device 104 may generate input while interacting with the application instance, for example, by using one or more controllers (such as a keyboard, mouse, game controller, etc.). These client inputs are received by application system 102 via network 106. These inputs are then processed by CPU 112 and GPU 114 to generate graphical output to be relayed back to client device 104.

[0018] For example, multiple instances or levels of a cloud gaming application can be executed simultaneously for multiple client devices 104. Each different client device 104, when interacting with such an instance, can use its local hardware or software to generate client input. This input is received by the cloud application system 102 via network 106. In one implementation, in response to client input, multiple images can be generated, where any given "image" is a single frame or view of the game that has already been rendered by GPU 114. These rendered images are then encoded and streamed to client devices 104 for display. In one implementation, each frame of the game is essentially an image that contributes to the overall gaming experience.

[0019] In one specific implementation, "image views" are generated when different instances or levels of a particular game are running concurrently on multiple client devices 104. An image view can be a subset or view of previously generated images. In some examples, when the cloud application system 102 uses a graphics API, an image view provides a way to interpret or access specific regions of the image's data. For example, in APIs such as Vulkan or DirectX, when rendering graphics, an image (i.e., a large block of memory used to store pixel data) is created, and then multiple image views are generated by the CPU 112, each representing a different portion of that image. When a cloud gaming application is executed by the application system 102, these image views correspond to different visual representations of game frames being streamed to different client devices 104. Any given image view represents the current state of the game's visuals from a specific angle (typically the player's perspective). Other specific implementations of images and image views, for example, for non-gaming cloud applications, are envisioned.

[0020] In one implementation, when images are generated by GPU 114, these images are stored as data blocks, for example, by allocating a portion of GPU memory 120 to each data block. For instance, each data block containing an image is "bound" to a specific portion of GPU memory 120, making the image accessible to shaders or other parts of the graphics pipeline (not shown), rendered to, or sampled from the image. In another implementation, for example, CPU 112 associates different image views generated for an image with a descriptor set. In one example, associating image views with a descriptor set includes mapping resources (such as buffers and textures) to shaders for use in the rendering pipeline. In one implementation, the descriptor set provides a way to associate these resources with shader stages (vertices, fragments, computations, etc.) and to specify which resources should be used in a particular shader call. These descriptor sets manage communication between CPU 112 and GPU 114, thereby ensuring that appropriate data blocks are available to the shaders when needed.

[0021] In one implementation, the concurrent execution of multiple instances or levels of a cloud application on GPU 114 may limit the efficiency of the cloud application system 102 because GPU memory 120 is insufficient to manage the data blocks generated by concurrently executing instances. Traditionally, when these multiple instances are executed, GPU 114 generates duplicate data blocks, for example, where two different instances of the application request the same data for rendering. For example, when two instances run the same scene, they may request the same data block, and in such cases, the data block may be shared between multiple rendering operations, for example, by allowing access to a shared memory block within GPU memory 120 that stores the data block. In one implementation, data blocks “shared” between application instances or rendering operations, as described herein, mean that the contents of a given data block can be used simultaneously by multiple rendering tasks to generate graphical outputs at multiple client devices. These outputs can be similar (i.e., a scene rendered in a game with only a single level) or different (e.g., a scene rendered during different levels of a complex game).

[0022] In one example, data blocks can be shared based on their attributes and ordinal indexes. However, as application complexity increases, sharing data blocks using only their attributes and / or indexes can lead to data corruption. For example, data corruption can occur in a cloud gaming application when different client devices 104 interact with different levels of a game at a given time. This is because for a game application with multiple different game levels running concurrently, game behavior during different game levels may be inconsistent. Therefore, decisions about sharing data blocks between different game levels cannot be made solely based on data attributes and / or ordinal indexes. Furthermore, sharing data blocks between multiple game instances based on their content can also be difficult because performing one or more tasks for rendering game instances before system 102 uploads the content of the data blocks may have already referenced the original memory allocation of the data blocks in GPU memory 120.

[0023] As described herein, different types of memory allocation for data blocks are possible. In one example, a given data block may be assigned either a dedicated memory block or a non-dedicated memory block within GPU memory. As described below, a non-dedicated memory block is a sub-allocation of memory from the GPU memory pool. A sub-allocation of memory may be defined as pre-allocating a large block of GPU memory and then dividing that block into smaller non-dedicated memory blocks to be used for each individual data block. All non-dedicated allocations for individual data blocks are made from this pre-allocated memory pool. In another specific implementation, data blocks may be assigned memory blocks using dedicated memory allocations. Assigning dedicated memory blocks to data blocks, compared to non-dedicated memory block allocations, ensures that memory is allocated separately for each data block. That is, each data block is assigned its own separate memory space. Furthermore, assigning a “shared memory block” to a given data block means allowing concurrent access to the data block between multiple processes and tasks. That is, multiple processes or applications can concurrently access and modify the same region of memory (the data block). Unless otherwise stated, these terms are used below as defined above.

[0024] In various implementations, the systems and methods described herein achieve data block sharing during the execution of different levels of an application by replacing the memory blocks initially assigned to the data blocks (e.g., using dedicated memory allocations) with shared memory blocks. In one implementation, the contents of a data block are stored in a shared memory block before the rendering circuitry renders data based on the data block. In one example, a shared memory block is assigned to a data block based on its contents. In one implementation, MMC 118 can track the usage of each data block generated as a result of the execution of an application instance and generate a content identifier for a given data block that represents the contents of the given data block. Tracking this usage may include tracking the use of the data block in one or more graphics processes, such as command-line rendering, command buffer references to the data block, and other tasks. Based on the tracked usage, MMC 118 generates a content identifier for the data block. If a data block is to be shared between different instances of the application, MMC 118 queries one or more shared memory blocks in GPU memory 120 that store the content identifiers of the data blocks, indicating that similar content was previously stored in GPU memory 120. If no such shared memory block is found (i.e., no instance is currently using the data block), the MMC 118 may copy the contents of the data block from its dedicated memory block to a selected shared memory block and assign a content identifier to that selected shared memory block. However, if an existing shared memory block already stores the contents of the data block, the MMC 118 may update the reference count of the shared memory block, indicating that another instance is using the contents stored in the shared memory block.

[0025] In one implementation, in response to the data block's contents being copied to (or otherwise made available in) a shared memory block, the dedicated memory block initially assigned to the data block is released by the MMC 118. The dedicated memory block can then be made available for use by other tasks. Furthermore, for example, in data structures that associate the data block's contents with corresponding memory addresses, the MMC 118 replaces all references to the dedicated memory block associated with the data block with the memory address of the shared memory block.

[0026] In several implementations, the content sharing solutions presented herein can support existing cloud-based applications (e.g., games using the Vulkan API) without requiring modifications to the application software or engine. Furthermore, as described herein, sharing memory blocks between different application instances saves GPU memory when running instances across different game levels. Therefore, more instances can be launched on a single GPU (or GPU cluster) without degrading image quality. Additionally, accidental copying or corruption of shared data is avoided when sharing different images. In some implementations, the systems and methods described herein can be further used to determine which data can be shared (or potentially shared) between instances of the application. Other implementations are envisioned.

[0027] Referring again to the specific implementation of cloud gaming, once a dedicated memory block for an image is replaced with a shared memory block, the MMC 118 associates the image with the shared memory block (which was previously associated with the dedicated memory block). Furthermore, the MMC 118 updates the image view of the image, where the new image view references the memory address of the shared memory block instead of the memory address of the dedicated memory block. For example, the descriptor set is updated to be associated with the new image view, allowing one or more shader programs to access the image content from the shared memory block in GPU memory 120.

[0028] As described herein, a "memory management circuit" or MMC (e.g., MMC 118) refers to an electronic component and system within the cloud application system 102 responsible for managing various aspects of memory resources. The MMC is configured to ensure efficient memory usage, implement memory protection, and facilitate the organization of data storage and retrieval. In one implementation, the MMC manages multiple levels of the memory hierarchy, including registers, cache memory, main memory (RAM), and secondary storage (hard disk drives, SSDs). The MMC controls data movement between these different levels, thereby optimizing performance and reducing latency. Furthermore, the MMC may handle the interface between the CPU 112 and system memory 116 and may handle tasks such as addressing memory locations, managing data transfers, and controlling memory access modes. Other implementations of the MMC component are contemplated and are within the scope of this disclosure. Figure 2 and Figure 3 The detailed operation of an exemplary memory management circuit is described.

[0029] Turn now Figure 2 This diagram illustrates exemplary implementations of various components of a cloud application system 202 (or simply "system 202"). While this document describes cloud application system 202 in relation to the processing of image data in cloud gaming applications, other applications and other types of data are contemplated. As shown, system 202 includes a central processing unit (CPU) 204, a graphics processing unit (GPU) 206, and one or more web servers 216. GPU 206 includes rendering circuitry 210, encoding circuitry 212, and memory management circuitry (or MMC) 214. System 202 also includes CPU memory 218 and GPU memory 220. In other implementations, system 202 may include additional processors and circuitry; however, these additional processors and circuitry are not shown for brevity.

[0030] In one embodiment, the application system's processor (i.e., CPU 204 and GPU 206) includes multiple cores configured to execute instructions. In some embodiments, the processor also includes additional circuitry configured to perform parallel processing. In some embodiments, these processors are system-on-a-chip (SoCs) that include multiple hardware components, such as a memory controller. Multiple such embodiments are possible and contemplated. For example, as shown, GPU 206 includes rendering circuitry 210, encoding circuitry 212, and MMC 214 to perform one or more of the functions described herein.

[0031] In one implementation, as used herein, "cloud gaming" involves rendering a video game on system 202 and streaming video or graphics output (e.g., graphics output 262) to a client device over a network. For example, system 202 may execute or render a game application instance requested by client device 222 in response to client input 260 received from client device 222. In one implementation, client device 222 may interact with the application instance at least in part based on commands generated using one or more controllers 224. Example client devices may include smartphones, game consoles, computers, etc. Additional controllers 224 may include keyboards, mice, game controllers, joysticks, etc.

[0032] In one embodiment, rendering circuitry 210 includes specialized hardware components for generating visual output (typically for use with displays such as computer monitors, TVs, and other screens). Rendering circuitry 210 converts digital information into an image perceptible to a client device display. In one embodiment, rendering circuitry 210 may include a graphics pipeline, such as one with circuitry for graphics processing (such as vertex processing, tessellation, geometry processing, rasterization, etc.). In another embodiment, encoding circuitry 212 includes specialized hardware components for converting analog or digital information into a specific encoded format and for data transmission, storage, and compression. These components may include analog-to-digital converters, digital-to-analog converters, data compressors, audio / video encoders, etc. In one embodiment, encoding circuitry 212 includes a video decoding engine (VCE). Other embodiments are envisioned.

[0033] In one implementation, system 202 receives client input 260 and translates this input into one or more game commands (e.g., character movement, shooting, etc.) to render the game based on client input 260. System 202 processes the commands generated from client input 260, for example, to simulate the game world and update the game state. In one implementation, a number of images may be generated based on client input 260. Each of these "images" may correspond to a single frame or perspective of the game that has been processed and rendered by GPU 206. These rendered images are then compressed and transmitted to client device 222 for visual presentation (e.g., on display 226). In one implementation, each game frame serves as an image that collectively enhances the overall game experience.

[0034] Images created in response to client input 260 are stored in GPU memory 220. Furthermore, in response to continuous input from client device 222, MMC 214 creates new images and stores these new images in GPU memory 220. In one implementation, each created image is allocated memory space within GPU memory 220. For example, depending on the cloud application specifics, a dedicated memory block or a sub-allocation of memory from a large pool of GPU memory 220 may be allocated to the image. In one implementation, where image content needs to be shared between different application instances, it may be difficult to do so if the image is allocated a non-dedicated memory block (e.g., a sub-allocation of a large pool of GPU memory). This is because a pool of memory can be associated with several different memory allocations, each with different purposes. Therefore, in response to an application requesting a non-dedicated memory block for an image in GPU memory 220, MMC 214 may transform that request to allocate a dedicated memory block for the image instead. In this way, once image content sharing is required, the MMC 214 can easily move the content from a dedicated memory block to a shared memory block that can be accessed by multiple instances, thereby enabling image content sharing.

[0035] In one implementation, when different instances or levels of a game application need to run concurrently on multiple client devices, the CPU 204 creates "image views." An image view can be a subset or view of previously generated images. In some examples, when the system 202 uses a graphics API, the image view provides a way to interpret or access specific regions of data in an image. For example, in APIs such as Vulkan, when rendering graphics, an image (i.e., a large block of memory used to store pixel data) is created, and then the CPU 204 generates multiple image views, each representing a different part of that image. As the system 202 renders multiple instances of the game application, these image views correspond to different visual representations of game application frames being streamed to different client devices. Each unique image view is updated with a data structure that defines how shaders access resources (e.g., buffers, images, etc.) during the rendering operation. In one example, a "descriptor set" may be generated, which can serve as a bridge between the CPU 204 and the GPU 206, specifying the location of resources in GPU memory 220 and how shaders can use those resources. In one specific implementation, these descriptor sets are stored in CPU memory 218.

[0036] MMC 214 can track image usage, for example, by recording one or more tasks that use the image and / or recording the object state of the image (i.e., the current state or attributes of the image within the scene to be rendered). Furthermore, this usage can be further tracked by recording the use of dedicated memory blocks allocated for the image, the image view of the image, the image's descriptor set, and one or more command buffers that update the image's content. Based on the tracked usage of the image, MMC 214 can generate a content identifier representing the image's content. In one example, the content identifier can be generated by copying the image's content from GPU memory 220 to accessible CPU memory (e.g., CPU memory 218). In one implementation, the content identifier can be a content hash or hash value of the image. In one example, the content hash value can be generated using a "fence" command after the image's content has been updated by one or more command buffers. That is, by using the fence command, MMC 214 waits until the image's content is updated before performing any further tasks on the image. However, in an alternative implementation, the content identifier can be generated before updating the content.

[0037] In one implementation, when different instances of a game application are running concurrently on different client devices (e.g., client devices similar to client device 222), some of these instances may need to render data based on (or otherwise use) the same image. For example, some objects in different scenes of the game application may be similar. To achieve memory efficiency in such conditions, MMC 214 is configured to share image data, allowing the image data to be used by multiple tasks executed during different instances (e.g., instead of the system using separate memory spaces for each instance to request access to the image). In one implementation, the image can be shared between these application instances based on its content instead of just using its attributes, to avoid data corruption.

[0038] To this end, MMC 214 is configured to query one or more shared memory blocks of GPU memory 220 to determine if any of these shared memory blocks corresponds to a content identifier generated for the image. If no such shared memory block is found, MMC 214 selects any given shared memory block and assigns the image's content identifier to the selected shared memory block. Furthermore, the content of the image from its dedicated memory block is copied to the shared memory block. However, if a shared memory block with a content identifier already exists (i.e., one or more tasks are already rendering from the image), MMC 214 may increment the "reference count" of the shared memory block, for example, to indicate that an additional application instance of the cloud gaming application is now accessing the image from the shared memory block.

[0039] Once the content has been copied from the dedicated memory block to the shared memory block (or is otherwise already available at the shared memory block), the dedicated memory block is released for use by other tasks or threads. Furthermore, each reference to the dedicated memory block address is replaced with the address of the shared memory block. For example, an image initially associated with a memory address of the dedicated memory block can be associated with an address of the shared memory block. Additionally, the image view corresponding to the image is updated by CPU 204 so that the new image view can reference the shared memory block address for use by all tasks. The descriptor set is also updated to be associated with the new image view to allow shader programs to access the shared memory block from GPU memory 220.

[0040] After the image is uploaded to the rendering command buffer, but before the rendering circuit 210 renders the data from the image, for example, to generate frames that can be displayed on the screen, a process can be performed to replace the dedicated memory block for the image with a shared memory block. That is, instead of querying the dedicated memory block every time the same image data is needed, the rendering circuit 210 can simply access the data from the shared memory block, thereby improving performance and system efficiency. Furthermore, when multiple instances (or levels) of a game application are to be executed concurrently, the rendering circuit 210 can use the image data from the shared memory block to execute several processes and / or tasks simultaneously. In one implementation, image data is marked as shareable based on its content (e.g., using a content identifier). Marking data as shareable based on its content, rather than its attributes, ensures that data corruption does not occur when such data is shared by multiple rendering tasks in multiple game process instances.

[0041] In one implementation, when image data is updated (or new image data is generated), for example, based on new client input received from a client device, the MMC 214 can regenerate the image's content identifier. Furthermore, the updated content is saved to a selected shared memory block, and the content identifier is associated with that selected shared memory block. Similarly, the rendering circuitry 210 can access the shared memory block to render data based on the image using the updated image data.

[0042] In one embodiment, encoding circuitry 212 is configured to encode the rendered image or frame, for example, by compressing and converting the raw pixel data of the image into a digital format to generate graphics output 262. As shown, graphics output 262 is sent back to client device 222 via network 230. In one or more embodiments, graphics output 262 is displayed using a user interface 228 on client display 226. Furthermore, for example, when a user interacts with these graphics using controller 224, newly generated client input can be sent to system 202 and processed by system 202 using the methods described above for a seamless gaming experience.

[0043] Now for reference Figure 3 This diagram illustrates various tasks performed at a cloud gaming system. As used herein, a "game instance" refers to a specific occurrence within a video game. A game instance can be a single playthrough of a game, typically initiated by a single player or a group of players. A new game instance is created each time a player starts a new game or loads a saved game. Furthermore, a "game level" is a specific playable area within a video game. It is a different segment of the game's virtual world that a player can explore, interact with, and complete objectives within. Levels are designed to provide players with a variety of challenges, environments, and experiences. In one or more implementations, game levels are activated within a game instance. In the following description, "game instance," "game level," or simply "instance" is used interchangeably to refer to different instances of a cloud gaming application.

[0044] As illustrated in the figure, cloud gaming system 302 (or simply "system 302") interacts with one or more client devices 350A to 350N, such that client input received from any of these client devices (e.g., client input 360A) is processed by the system to generate graphical output (e.g., output 370A). In some implementations, the client input can be any input from a given client device (devices 350A to 350N), generated in response to the client device interacting with an instance of the game application through one or more controllers (not shown).

[0045] In one implementation, client input 360A is received by CPU 304, allowing CPU 304 to process client input 360A according to program logic associated with the game application. For example, client input 360A may be processed by CPU 304 to validate and sanitize the input data, for example, to ensure that the input data meets prerequisite criteria. Furthermore, based on the validated input, CPU 304 executes instructions to generate images using the input data. In one implementation, libraries, algorithms, or custom execution may be used to generate these images, allowing the images to be further used to create desired visual content from the original input data. About Figure 4 Some exemplary resources and libraries for generating images are described in detail. Furthermore, while the description herein presents details regarding the generation of images and image data, the generation of other application data is contemplated and is within the scope of this disclosure.

[0046] CPU 304 can set image attributes, including the image's format (color, depth, etc.), size (width, height), usage flags (rendering target, texture, etc.), and / or memory layout. Furthermore, CPU 304 can create image objects in GPU memory 308 based on these specified attributes, for example, using graphics API functions. In one embodiment, memory management circuitry 314 (“MMC 314”) determines whether one or more of the created images are shareable between different game instances (e.g., when different client devices 350 are running game application instances at different levels of the game). Shareable images can be marked as shareable by MMC 314. In one embodiment, images can be marked as shareable based on image attributes. Furthermore, in another embodiment, a specific image (e.g., a shader read-only image) can be marked as shareable, and other images cannot be marked in the same way. Additionally, target or depth template images can be marked as non-shareable. Other embodiments for marking images as shareable or non-shareable are contemplated.

[0047] In one specific implementation, MMC 314 is configured to perform functions 322, including but not limited to recording state 322-1, transforming commands 322-2, identifying content 322-3, querying memory 322-4, updating reference counts 322-5, and associating and replacing 322-6. These functions are performed by MMC 314 during one or more tasks executed by CPU 304 or GPU 306. These functions 322 are described in more detail below. It should be noted that functions other than those described herein are possible and contemplated. In one example, MMC 314 is configured to perform function 322 after an image is uploaded to the rendering command buffer, but before the rendering circuitry 324 performs any tasks for rendering data based on image 310. Furthermore, some of these functions 322 may be performed during a separate task being executed by GPU 306 (e.g., as described by the CPU thread). For example, function association and replacement 322-6 may be performed during one or more rendering tasks, and function identification content 322-3 and memory lookup 322-4 may be performed during an "update" task (e.g., when the content of the image is updated by CPU 304). However, in other specific implementations, any given function of given function 322 may be performed during any task executed within system 302. For example, the identification content 322-3 function may be performed even before the actual content of the image is uploaded to the rendering command buffer.

[0048] In one implementation, an image created by CPU 304 can be allocated memory space in GPU memory 308. As depicted, image 310 created by CPU 304 is stored in GPU memory 308 (memory allocation 312). For example, based on application configuration, a dedicated or non-dedicated memory block within GPU memory 308 can be assigned to image 310. In one implementation, where image data needs to be shared between different application instances, it may be difficult to do so if image 310 is allocated a non-dedicated memory block in GPU memory 308. To avoid this, in one implementation, in response to an application request for a non-dedicated memory block in GPU memory 308 for an image, MMC 314 can execute transformation command function 322-2. In response to transformation command function 322-2, the request for assigning a non-dedicated memory block can be transformed into an alternative request for allocating a dedicated memory block for image 310. This ensures that once image 310 is to be shared, MMC 314 can replace the dedicated memory block for image 310 with a shared memory block accessible by multiple tasks that can share the image data. In one implementation, transform command 322-2 can be executed only on images marked as shareable. This ensures that shareable images can be easily shared and accessed by multiple tasks within system 302. In one example, non-shareable images can continue to be assigned non-dedicated memory blocks, such as sub-allocations of GPU memory blocks in GPU memory 308.

[0049] In one implementation, an image 310 created by CPU 304 may be associated with one or more image views. The image views of image 310 may represent different views of image 310. For example, an image view may provide a way to interpret or access specific regions of data in an image. Image views may be stored in CPU memory 312, as illustrated by image view 316. CPU 304 is also configured to generate descriptor sets for image views 316 and associate image views 316 with their corresponding descriptor sets. As shown, descriptor set 318 is stored in GPU memory 308 by MMC 314.

[0050] Query memory 322-4: During one or more tasks performed by system 302, such as rendering video and images for one or more client devices 350, MMC 314 is configured to track the usage of each shareable image (both existing and newly created) (using tracking 320) to determine whether these tasks require sharing one or more images from the same set of images. In one specific implementation, when different instances of a game application are running concurrently on different client devices (e.g., client devices 350A to 350N), one or more rendering tasks for these instances may require data from the same image to render the scene. For example, some objects in different scenes of the game application may be similar and therefore can be rendered from the same data. To achieve memory efficiency in such conditions, MMC 314 is configured to share image content between tasks performed for these different instances (e.g., instead of the system using a separate memory space for each instance to access the image).

[0051] To share image data between different application instances, the MMC 314 is configured to first track the usage of a given shareable image (e.g., image 310). In one specific implementation, the MMC 314 performs a record state function 322-1 to record the memory allocated for image 310, as well as the image view 316 corresponding to image 310 and the associated descriptor set 318. The record state function 322-1 can be performed by the MMC 314 to further record the state of one or more command buffers programmed to update the content of image 310. The state of other commands that can be recorded while performing the record state function 322-1 may include copy commands initiated by the game application.

[0052] Based on the recorded state, MMC 314 performs the identification content function 322-4. In one embodiment, the identification content function 322-4 calculates a hash code for image 310 such that the hash code identifies the content of image 310. To calculate the hash code, MMC 314 copies the content of image 310 from the memory block associated with that image in GPU memory 308 to CPU-accessible memory (e.g., CPU memory 312). MMC 314 can then calculate the hash code of image 310 based on its content. This hash code is recorded by MMC 314. Alternatively, the hash code can be calculated by CPU 304. Other embodiments for calculating the hash code are contemplated.

[0053] In one specific implementation, MMC 314 can identify when different levels of the game executed on different client devices 350 require access to data from the shareable image 310. As described above, this determination can be made when each of two or more client devices 350 is interacting with the game on a different game level; however, data from the same image (i.e., image 310) is needed for a given scene or frame rendered for each of the two or more client devices 350. In another example, image 310 can also be shared between instances when generic texture or image data (such as generic texture or image data used to render objects such as walls, floors, trees, water, sky, etc.) is required. Other specific implementations of image sharing are envisioned.

[0054] If a given image 310 is to be shared, the MMC 314 can perform a query memory 322-4 function to query the shared memory blocks in GPU memory 308 to determine whether the content of image 310 is already stored in a shared memory block (i.e., one or more given instances are already using the content of the image). In one implementation, the MMC 314 is configured to determine whether a shared memory block stores the content of image 310 based on a content identifier generated for image 310. In one example, the content identifier is a hash associated with image 310. In other examples, the content identifier can be any identifier representing the content of image 310. When no shared memory block stores or is associated with a content identifier (i.e., no other task is currently rendering from image 310), the MMC 314 selects any available shared memory block to store the content for image 310. The content of image 310 is copied from the image's dedicated memory block to the selected shared memory block. In such cases, the association or dependency between image data and the corresponding memory address can be updated for image 310. In one implementation, image 310 is associated with a memory address of a shared memory block, and this association replaces the previous association between image 310 and the memory address of the dedicated memory block initially allocated to image 310. Any subsequent tasks performed during one or more game instances that require access to image 310 can simply access image 310 from the shared memory block using the updated association. In one implementation, MMC 314 updates the association by performing association and replacement functions 322-3. In one or more implementations, the association between image data and memory addresses is stored in GPU memory 308.

[0055] Furthermore, each time a request is received from an application to update the original image view 316 to the descriptor set 318, the MMC 314 is configured to execute the transformation command 322-2 function to transform the request in lieu of updating the image view associated with the shared image. Additionally, after an image 310 has already been shared between two or more application instances, the transformation command function 322-2 is also executed by the MMC 314 to transform one or more other commands (e.g., copy commands initiated by the application). For example, any command call from the application can be reinterpreted by the MMC 314 by performing underlying operations using data from the shared image.

[0056] In one implementation, each shared memory block storing the image is assigned a reference counter. The reference counter of the shared memory block indicates how many game instances share the image 310 stored in the shared memory block. In another implementation, the reference counter may further indicate which game instances are currently sharing data from the image 310. In one example, each time a different game instance requests access to the image 310 (e.g., in response to client input 360B from client device 350B), the reference counter of the shared memory block storing the image is updated (updated reference count 322-5), for example, incremented by 1. Alternatively, when a game instance no longer accesses the image 310 (e.g., in response to client input 360N from client device 350N), the reference counter may be decremented by 1.

[0057] In one embodiment, image 310 is rendered by rendering circuitry 324 to generate a rendered image or other rendered graphics (“rendered output 340”). For example, rendering circuitry 324 processes image 310 to generate a 2D image from a 3D scene. Rendering circuitry 324 may process image 310 to simulate the behavior of light, shadows, reflections, and other visual effects to create a realistic or stylized representation of the scene. Furthermore, encoding circuitry 326 is configured to encode the rendered image, which involves converting the visual information of the image into a digital format that can be stored, transmitted, or manipulated by one or more client devices 350. In one embodiment, graphics output 370A is generated based on the encoded data generated by encoding circuitry 326. Graphics output 370A is sent to client device 350A (or to multiple client devices from client device 350A to 350N).

[0058] Turn now Figure 4The diagram illustrates block diagrams representing different application instances of a cloud-based application. As depicted, multiple different application instances 410-1 to 410-N are shown, each managed by memory management circuitry 430 (or MMC 430) for accessing various data stored in GPU memory 420. In one embodiment, GPU memory 420 includes dedicated memory blocks 422 and shared memory blocks 424. Furthermore, content identifiers 426 stored in GPU memory 420 can each represent the content of a data block stored in dedicated memory block 422 or shared memory block 424. Additionally, the association between data blocks and the memory addresses of the dedicated memory block 422 or shared memory block 424 storing the data blocks is recorded in a lookup table 428 (also stored in GPU memory 420).

[0059] In one specific implementation, during the execution cycle, when a given client device (not shown) interacts with application instance 410, input data may be generated (e.g., input data generated when accessing application instance 410). The input data is processed by processing circuitry (e.g., Figure 2 The CPU 204 or GPU 206 (shown) processes the data to generate graphics output, which is sent back to the client device. In one specific implementation, to process the input data generated in application instance 410, the processing circuitry utilizes one or more application resources 412 associated with application instance 410. For example, for a game application, application resources 412 may include various types of assets and data used to create and enhance the game experience. Application resources 412 can be used to generate visual, audio, and interactive elements of the game. Application resources 412 may include resources such as graphics and visual resources, audio resources, level design resources, cinematic resources, etc.

[0060] In one implementation, for cloud-based applications, the application library 414 associated with each application instance 410 can be used by processing circuitry (and / or software) to simplify development, enhance functionality, and leverage cloud-specific features. The application library 414 includes, for example, libraries for managing backend infrastructure and frontend user interfaces. The application library 414 may include backend and server-side libraries, frontend libraries and frameworks, cloud service libraries, database-related libraries, authentication and authorization libraries, containerization and orchestration libraries, etc.

[0061] In one implementation, one or more drivers 416 associated with a given application instance include software components that enable communication and interaction between the application and hardware devices or external resources (e.g., communication between processing circuitry and client devices). These drivers 416 act as intermediaries, allowing the application to utilize the functionality of hardware devices, peripherals, or other software components. Drivers 416 may include device drivers, network drivers, database drivers, A / V drivers, etc. In one implementation, for a Vulkan API-based cloud gaming application, a "Vulkan loader" may be designed to provide efficient and high-performance access to graphics and computing power on various hardware platforms. In one implementation, the Vulkan loader is programmed to manage communication between application instance 410 and drivers 416.

[0062] In one implementation, application data 418 may include all data generated as a result of interaction between the client device and application instance 410. In one example, application data 418 includes information, content, and settings generated, stored, and managed by application instance 410. In one implementation, application data 418 may be temporary or persistent (stored in GPU memory 420) and may cover a wide range of formats, including text, images, audio, video, configuration settings, user preferences, etc.

[0063] In one implementation, application data 418 may include data blocks that can be shared between different application instances 410. As described above, for example, data blocks, such as images, can be shared between different instances or levels of a cloud gaming application when each such instance needs to render the same scene. These data blocks can be marked as shareable by the MMC 430 based on their content. The content of each such data block can be identified (by processing circuitry) and stored in GPU memory as a content identifier 426.

[0064] In one implementation, whenever a data block is to be shared between two application instances 410, the MMC 430 can determine, for example, whether the shared memory block 424 already stores the data block based on the content identifier of the data block assigned to it. When such a shared memory block 424 is found, the MMC 430 increments the reference counter of the shared memory block 424 to indicate that the data block is now being used by the additional application instance 410. The MMC 430 can continuously update the reference count of the shared memory block based on how many instances are using the data block at any given point in time. For example, when a given instance stops using the data block, the reference counter can be decremented accordingly. Furthermore, the reference counter can also indicate which application instances 410 are currently sharing the data block, such that updating the reference counter uses data from the data block to appropriately identify the application instance 410.

[0065] However, if no shared memory block 424 currently stores the contents of the data block, the MMC 430 can copy the contents of the data block from the dedicated memory block 422 originally assigned to the data block to the selected shared memory block 424. In response to copying the contents to a shared memory block (or otherwise finding a shared memory block 424 that already stores the contents of the data block), the MMC 430 can associate the data block with the address of the shared memory block and store the association in a lookup table 428. This mapping can be utilized by subsequent tasks executed in the system to identify the memory location for the contents of the data block. Furthermore, the dedicated memory block 422 is released and made available for other tasks.

[0066] In one implementation, the functionality of the MMC 430 as described above may alternatively be built into a software component (e.g., an API layer). The software component may examine various ongoing tasks within the computing system to determine when data should be shared between two or more application instances 410. For example, the API layer may communicate with an internal GPU memory management process (also built into the software) via domain sockets to determine the data requirements of application instances 410. Based on such data requirements, the API layer may manage memory allocation for data blocks, enabling seamless and full sharing of these data blocks among multiple application instances 410. This software implementation and other software implementations of memory management based on the methods described herein are envisioned.

[0067] Turn now Figure 5 This describes a method for sharing data blocks across multiple application instances based on the content of the data blocks. In one specific implementation, one or more processes described by this method may be performed by processing circuitry (such as a CPU or GPU) and / or memory management circuitry (such as... Figure 3 The memory management circuit 314 described herein is executed.

[0068] In one implementation, for a cloud-based application, multiple client devices can simultaneously access and interact with the application via a network such as the Internet. Furthermore, for each client device interacting with the application, input data generated by the client device is processed by processing circuitry to generate graphical output. To generate this graphical output, the input data is first processed to generate data blocks (e.g., images). Memory management circuitry detects each new shareable data block generated (box 502). In one implementation, the memory management circuitry identifies a given data block as shareable based on its attributes. For example, an image might be identified as shareable based on attributes such as its width, height, format, associated usage flags, tiling mode, or a combination thereof. Other implementations for identifying which data blocks are shareable are envisioned.

[0069] The memory management circuitry is configured, for example, to allocate a dedicated memory block in the GPU memory for each data block determined to be shareable among multiple application instances (box 504). In one example, "shareable among multiple application instances" in this document means that the contents of a given data block can be used simultaneously by multiple rendering tasks (e.g., using parallel processing) to generate graphics outputs at multiple client devices. These outputs can be similar (e.g., a scene rendered in a game with only a single level) or different (e.g., a scene rendered during different levels of a complex game).

[0070] In some implementations, depending on the specific circumstances of the cloud application, data blocks may be assigned non-dedicated memory blocks from GPU memory. However, replacing the address of a non-dedicated memory block with the address of a shared memory block (e.g., when sharing an image later between application instances) can be difficult to implement. Therefore, in response to an application's request for a non-dedicated memory block from GPU memory, memory management circuitry can transform that request to allocate a dedicated memory block for the data block instead. Dedicated memory block allocation may include assigning a specific portion of GPU memory that is reserved only for the data block and cannot be shared with other processes or components. Once data block sharing is to be implemented, memory management circuitry can replace the memory address of the dedicated memory block with the address of a shared memory block, allowing the data block to be accessed simultaneously by multiple application instances.

[0071] The memory management circuitry further tracks the usage of a given data block (box 506). In one example, tracking the usage of a data block may include recording the original dedicated memory block allocated to the data block, recording which processes will upload and update the contents of the data block, etc. Based on the tracked usage of the data block, the processing circuitry is configured to generate a content identifier representing the contents of the data block (box 508). In one implementation, the content identifier is a hash value associated with the data block.

[0072] In one implementation, memory management circuitry can determine whether a data block should be shared among multiple application instances (condition box 510). In one example, the data block can be shared in response to different application instances performing tasks that require the same content (i.e., the content of the data block). If the data block is not to be shared (condition box 510, "No" box), the data block content is rendered by processing circuitry (box 522). For example, when no other application instance needs to share the content from the data block, or when the data from the data block is otherwise used only by a given task performed during a single application instance, the content of the data block is not shared and is rendered accordingly.

[0073] However, when a data block is to be shared (condition box 510, "Yes" branch), the memory management circuitry locates a shared memory block that previously stored the content identifier of the data block (or was otherwise previously associated with that content identifier) ​​(box 512). For example, when multiple tasks executed (running concurrently) during different application instances require the same content (the content of the data block), the memory management circuitry identifies the memory location ("shared memory block") where the content of the data block has already been stored. In one implementation, the memory management circuitry may make this identification based on a query, for example, of shared memory blocks in GPU memory, to determine whether any of the shared memory blocks stores the content identifier of the data block (or is otherwise associated with that content identifier). The memory management circuitry then determines whether such a shared memory block has been found (condition box 514). When no shared memory block stores the content identifier of the data block (condition box 514, "No" branch), the method continues to box 518. At box 518, the memory management circuitry assigns a selected shared memory block and assigns the content identifier of the data block to the selected shared memory block. Furthermore, the contents of the data block are copied from its initially allocated memory block (the dedicated memory block allocated in box 504) to the shared memory block. This way, whenever a process or task needs to access the contents of the data block, that process or task can access the shared memory block to access the contents. Moreover, multiple tasks can access the contents simultaneously by accessing the shared memory block at the same time.

[0074] However, if a shared memory block storing the content identifier of the data block is found (condition box 514, "Yes" branch), the method continues to box 520. In one implementation, each time the content of a data block is found in a shared memory block, or when the content of a data block is copied from the memory block initially allocated to the data block to the shared memory block, the memory management circuitry releases the original memory block for the data block and maps the shared memory block address to the data block content (box 520). This mapping of the shared memory block address and the data block content replaces all previous mappings of the data block (e.g., the mapping between the data block and its initially allocated private memory block, etc.). Thereafter, when each subsequent task involving the content of the data block is performed (box 522), the processing circuitry can alternatively access the content from the shared memory block.

[0075] The specific implementation presented in this paper supports existing cloud-based applications without requiring modifications to the application or application engine. Furthermore, the techniques described above enable the saving of GPU memory when running different application instances (e.g., different game levels or save points). Therefore, more instances can be launched on a single GPU to meet end-user demands. Additionally, data can be shared based on its content instead of attributes or ordinal indexes, thus avoiding GPU allocation duplication or corruption. The solution presented in this paper also provides a feedback mechanism regarding which data can be shared.

[0076] It should be emphasized that the above-described specific embodiments are merely non-limiting examples. Many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. The following claims are intended to be interpreted as covering all such variations and modifications.

Claims

1. A processor, the processor comprising: Memory management circuit, the memory management circuit being configured to: In response to a request to share the contents of a data block between at least two instances of the application, the memory address of a dedicated memory block originally allocated for the data block is replaced with the memory address of a shared memory block, wherein the request is based on the contents of the data block.

2. The processor of claim 1, wherein the memory management circuitry is configured to allocate the dedicated memory block to the data block in response to the data block being marked as being shareable between two or more instances of the application.

3. The processor of claim 1, wherein the memory management circuitry is configured to replace the memory address of the dedicated memory block in a data structure with the memory address of the shared memory block before one or more rendering tasks render data from the data block.

4. The processor of claim 1, wherein the data block at least partially comprises an image, and wherein the memory management circuitry is configured to mark the image as shareable between two or more different instances of the application based at least in part on one or more attributes associated with the image, the one or more attributes including the width of the image, the height of the image, the format of the image, a usage flag associated with the image, the tiling mode of the image, or a combination thereof.

5. The processor according to claim 1, wherein the memory management circuitry is further configured to: Queries multiple shared memory blocks; In response to the fact that no shared memory block stores a content identifier among the plurality of shared memory blocks, the content identifier is assigned to a selected shared memory block from the plurality of shared memory blocks; and The contents of the data block are copied from the dedicated memory block to the selected shared memory block.

6. The processor of claim 1, wherein the memory management circuitry is further configured to update the reference count associated with the shared memory block based at least in part on the number of different application instances sharing the data block.

7. The processor of claim 1, wherein the memory management circuitry is configured to generate the content identifier of the data block at least in part based on the content of the data block.

8. A method, the method comprising: In response to a request to share the contents of a data block between at least two instances of the application, the memory address of a dedicated memory block originally allocated for the data block is replaced with the memory address of a shared memory block, wherein the request is based on the contents of the data block.

9. The method of claim 8, further comprising allocating the dedicated memory block to the data block by processing circuitry in response to the data block being marked as being shareable between two or more different instances of concurrent execution of the application.

10. The method of claim 8, further comprising, before one or more rendering tasks render data from the data block, having the processing circuitry replace the memory address of the dedicated memory block with the memory address of the shared memory block in the data structure.

11. The processor of claim 8, wherein the data block at least partially comprises an image, and wherein the method further comprises the processing circuitry marking the image as shareable between two or more different instances of the application based at least partially on one or more attributes associated with the image, the one or more attributes including the width of the image, the height of the image, the format of the image, a usage flag associated with the image, the tiling mode of the image, or a combination thereof.

12. The method according to claim 8, further comprising: The processing circuit queries multiple shared memory blocks; In response to the fact that no shared memory block stores a content identifier among the plurality of shared memory blocks, the processing circuit assigns the content identifier to a selected shared memory block from the plurality of shared memory blocks; as well as The processing circuit copies the contents of the data block from the dedicated memory block to the selected shared memory block.

13. The method of claim 8, further comprising updating the reference count associated with the shared memory block by the processing circuitry based at least in part on the number of different application instances sharing the data block.

14. The method according to claim 8, further comprising: The processing circuitry tracks the use of the data blocks in the processing pipeline. as well as The content identifier is generated by the processing circuitry based at least in part on the tracked usage.

15. A system comprising: At least one processing circuit; and Memory management circuit, the memory management circuit being configured to: In response to a request for the contents of a shared data block received from the processing circuitry, the memory address of the dedicated memory block initially allocated for the data block is replaced with the memory address of the shared memory block in the data structure representing the association between the data block and the memory address.

16. The system of claim 15, wherein the memory management circuitry is configured to replace the memory address of the dedicated memory block in the data structure with the memory address of the shared memory block before one or more rendering tasks render data from the data block.

17. The system of claim 15, wherein the data block at least partially comprises an image, and wherein the memory management circuitry is configured to mark the image as shareable between two or more different instances of the application based at least in part on one or more attributes associated with the image, the one or more attributes including the width of the image, the height of the image, the format of the image, a usage flag associated with the image, the tiling mode of the image, or a combination thereof.

18. The system of claim 15, wherein the memory management circuitry is further configured to: Queries multiple shared memory blocks; In response to the fact that no shared memory block stores a content identifier among the plurality of shared memory blocks, the content identifier is assigned to a selected shared memory block from the plurality of shared memory blocks; and The contents of the data block are copied from the original memory block to the selected shared memory block.

19. The system of claim 15, wherein the memory management circuitry is further configured to update the reference count associated with the shared memory block based at least in part on the number of different application instances sharing the data block.

20. The system of claim 15, wherein the memory management circuitry is configured to: Track the use of the data blocks in the processing pipeline; and The content identifier is generated based at least in part on the tracked usage.

Images