Systems and methods for rendering graphics

Abstract

Methods and computing systems for rendering graphics, wherein a request for a texture from a first application instance executing on a computing system is received, it is determined if a location of the texture loaded in a video random-access memory (VRAM) of the computing system is registered in a texture database, and, if the location of the texture in the VRAM is unregistered in the texture database: loading the texture in the VRAM; and registering the location of the texture in the VRAM in the texture database; and providing the texture from the VRAM from the location identified in the texture database to the application instance.

Description

SYSTEMS AND METHODS FOR RENDERING GRAPHICSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This is the first application related to the present disclosure.TECHNICAL FIELD

[0002] The present disclosure relates to computer graphics, and, in particular, to systems and methods for rendering graphics.BACKGROUND

[0003] Millions of users worldwide play games on mobile devices. Gamers demand high game quality, as well as low latency. Those require high computational resources to support. Most mobile devices, however, have limited resources to run high-end games smoothly.

[0004] An alternative solution to rendering graphics on mobile devices is to use cloud-based gaming, wherein the game logic and rendering are performed remotely on a server system, inputs are received via a user input interface of a mobile device, and the rendered graphics are displayed on a display of the mobile device. Based on the data from professional analytic companies (like Gartner, IDC) , the GPU server potential market in China will reach US$6.4B in the year of 2025. It is foreseeable that servers for cloud-based mobile gaming will experience a majority of this growth, currently having a US$3B market share with a year-to-year growth rate of 50%.

[0005] For rendering applications, textures are applied to the surface of a mesh to give it the appearance of a three-dimensional object. However, textures take time to be loaded from storage into graphics processing unit (GPU) memory. This memory-loading process can be the performance bottleneck, causing rendering glitches, and otherwise having a negative impact on the mobile device user experience.

[0006] For graphics applications on mobile devices, due to the limited GPU’s video random-access memory (VRAM) of a mobile device, textures are frequently deleted and re-loaded to the GPU.

[0007] When applications originally designed for mobile devices are just run on a cloud server, simply following the original logic of the mobile application (frequent deletion and re-loading of the same texture) can significantly affect performance.

[0008] To resolve the texture loading performance issue, various state-of-the-art solutions have been proposed.

[0009] One solution is to preload all textures before game playing, either for the entire game or at certain game level. This is a feature that can be statically turned on at application level. It requires a significant amount of GPU memory to store all the textures, and can thus be very challenging for complex games and / or low-end GPUs. This solution is not a dynamic solution, and does not taking game content and system status into consideration.

[0010] Another approach is to let the application executing on the server drive dynamic texture loading. This logic is controlled by each specific game application or game engine, and is thus not a generic platform level solution that can serve all applications. Further, this approach targets single instances of applications executed by the server for mobile devices, and does not consider multi-channel, multi-mobile device, multi-view scenarios in cloud rendering.

[0011] The texture handling logic of a well-designed, very popular mobile game on the market was analyzed. 42%of the textures were redundantly unloaded and reloaded, with one particular texture being repeatedly unloaded and reloaded 113 times in less than two minutes. As will be readily understood, this redundancy is far from optimal for cloud rendering, and leaves room for improvement.SUMMARY

[0012] The present disclosure describes systems and methods which provide one or more efficient techniques to perform graphics rendering.

[0013] In accordance with a first aspect of the present disclosure, there is provided a computer-implemented method for rendering graphics, comprising: receiving a request for a texture from a first application instance executing on a computing system; determining if a location of the texture loaded in a video random-access memory (VRAM) of the computing system is registered in a texture database; if the location of the texture in the VRAM is unregistered in the texture database: loading the texture in the VRAM; and registering the location of the texture in the VRAM in the texture database; and providing the texture from the VRAM from the location identified in the texture database to the application instance.

[0014] In some or all exemplary embodiments of the first aspect, the method further includes: generating a unique key for the texture requested by the first application, and registering the unique key with the location in the VRAM.

[0015] In some or all exemplary embodiments of the first aspect, the registering comprises: generating the unique key for the texture and storing the location of the texture with the unique key, and the determining comprises: generating the unique key for the texture; and determining if the unique key is in the texture database.

[0016] In some or all exemplary embodiments of the first aspect, the method further includes: receiving a delete request to delete a texture from the VRAM from the first application instance or a second application instance; determining if the location of the texture in the VRAM is registered for the texture in the texture database; and, if the location of the texture in the VRAM is registered for the texture in the texture database, deleting the texture from the location of the VRAM.

[0017] In some or all exemplary embodiments of the first aspect, the method further includes: if the location of the texture in the VRAM is registered for the texture in the texture database, removing the location of the texture in the VRAM from the texture database.

[0018] In a second aspect of the present disclosure, there is provided a computer-implemented method for rendering graphics, comprising: determining an in-use level of a VRAM of a computing system, the VRAM storing a set of textures requested by one or more application instances; determining if a condition for proactively deleting a subset of the set of textures stored in the VRAM is satisfied using the in-use level of the VRAM; selecting the subset of the set of textures in the VRAM for deletion if the condition is satisfied; and deleting the subset of the set of textures in the VRAM.

[0019] In some or all exemplary embodiments of the second aspect, the method further includes: maintaining a texture database in storage of the computing system, the texture database storing, for each of the set of textures, a location in the VRAM and a unique key generated.

[0020] In some or all exemplary embodiments of the second aspect, the method further includes: storing log information in storage of the computing system for requests for the set of textures received from the one or more application instances; and determining the subset of the set of textures using the log information.

[0021] In some or all exemplary embodiments of the second aspect, the method further includes: analyzing the log information to identify correlated textures, wherein the correlated textures in the set of textures include a second texture that is requested after the first texture within a threshold time period with a minimum threshold probability; receiving a new request for the first texture from the one of the one or more application instances; determining if the second texture is loaded in video random-access memory (VRAM) ; and loading the second texture in the VRAM if the second texture is not loaded in the VRAM.

[0022] In a third aspect of the present disclosure, there is provided a computer-implemented method for rendering graphics, comprising: receiving a request to delete a texture from a VRAM from a first application instance; determining if a location of the texture in the VRAM is registered for the texture in a texture database; and if the location of the texture in the VRAM is registered for the texture in the texture database, deleting the texture from the location of the VRAM, and removing the location of the texture in the VRAM from the texture database.

[0023] In a fourth aspect of the present disclosure, there is provided a computer-implemented method for rendering graphics, comprising: analyzing log information stored by a computing system for requests for a set of textures received from a set of application instances to identify correlated textures in the set of textures, wherein the correlated textures in the set of textures include a second texture that is requested after a first texture within a threshold time period with a minimum threshold probability; receiving a new request for the first texture from one application instance of the set of application instances; determining if the second texture is loaded in a video random-access memory (VRAM) ; and loading the second texture in the VRAM if the second texture is not loaded in the VRAM.

[0024] In a fifth aspect of the present disclosure, there is provided a computing system for rendering graphics, comprising: one or more processors; and a non-transitory storage medium storing machine-executable instructions that, when executed by the one or more processors, cause the one or more processors to: receive a request for a texture from a first application instance executing on the computing system; determine if a location of the texture loaded in a video random-access memory (VRAM) of the computing system is registered in a texture database; if the location of the texture in the VRAM is unregistered in the texture database: load the texture in the VRAM; and register the location of the texture in the VRAM in the texture database; and provide the texture from the VRAM from the location identified in the texture database to the application instance.

[0025] In some or all exemplary embodiments of the fifth aspect, the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: generate a unique key for the texture requested by the first application, and register the unique key with the location in the VRAM.

[0026] In some or all exemplary embodiments of the fifth aspect, the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: generate the unique key for the texture and storing the location of the texture with the unique key, determine if the unique key is in the texture database when determining if the location of the texture in the VRAM is unregistered in the texture database.

[0027] In some or all exemplary embodiments of the fifth aspect, the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receive a delete request to delete a texture from the VRAM from the first application instance or a second application instance; determine if the location of the texture in the VRAM is registered for the texture in the texture database; and if the location of the texture in the VRAM is registered for the texture in the texture database, delete the texture from the location of the VRAM.

[0028] In some or all exemplary embodiments of the fifth aspect, the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: if the location of the texture in the VRAM is registered for the texture in the texture database, remove the location of the texture in the VRAM from the texture database.

[0029] In a sixth aspect of the present disclosure, there is provided a computing system for rendering graphics, comprising: one or more processors; and a non-transitory storage medium storing machine-executable instructions that, when executed by the one or more processors, cause the one or more processors to: determine an in-use level of a VRAM of a computing system, the VRAM storing a set of textures requested by one or more application instances; determine if a condition for proactively deleting a subset of the set of textures stored in the VRAM is satisfied using the in-use level of the VRAM; select the subset of the set of textures in the VRAM for deletion if the condition is satisfied; and delete the subset of the set of textures in the VRAM.

[0030] In some or all exemplary embodiments of the sixth aspect, the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: maintain a texture database in storage of the computing system, the texture database storing, for each of the set of textures, a location in the VRAM and a unique key generated.

[0031] In some or all exemplary embodiments of the sixth aspect, the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: store log information in storage of the computing system for requests for the set of textures received from the one or more application instances; and determine the subset of the set of textures using the log information.

[0032] In some or all exemplary embodiments of the sixth aspect, the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: analyze the log information to identify correlated textures, wherein the correlated textures in the set of textures include a second texture that is requested after the first texture within a threshold time period with a minimum threshold probability; receive a new request for the first texture from the one of the one or more application instances; determine if the second texture is loaded in video random-access memory (VRAM) ; and load the second texture in the VRAM if the second texture is not loaded in the VRAM.

[0033] In a seventh aspect of the present disclosure, there is provided a computing system for rendering graphics, comprising: one or more processors; and a non-transitory storage medium storing machine-executable instructions that, when executed by the one or more processors, cause the one or more processors to: receive a request to delete a texture from a VRAM from a first application instance; determine if a location of the texture in the VRAM is registered for the texture in a texture database; and if the location of the texture in the VRAM is registered for the texture in the texture database, delete the texture from the location of the VRAM, and removing the location of the texture in the VRAM from the texture database.

[0034] In an eighth aspect of the present disclosure, there is provided a computer-implemented method for rendering graphics, comprising: one or more processors; and a non-transitory storage medium storing machine-executable instructions that, when executed by the one or more processors, cause the one or more processors to: analyze log information stored by a computing system for requests for a set of textures received from a set of application instances to identify correlated textures in the set of textures, wherein the correlated textures in the set of textures include a second texture that is requested after a first texture within a threshold time period with a minimum threshold probability; receive a new request for the first texture from one application instance of the set of application instances; determine if the second texture is loaded in a video random-access memory (VRAM) ; and load the second texture in the VRAM if the second texture is not loaded in the VRAM.

[0035] In a ninth aspect of the present disclosure, there is provided a non-transitory machine-readable medium having tangibly stored thereon executable instructions for execution by one or more processors, wherein the executable instructions, in response to execution by the one or more processors, cause the one or more processors to perform any of the methods described above.

[0036] Other aspects and features of the present disclosure will become apparent to those of ordinary skill in the art upon review of the following description of specific implementations of the application in conjunction with the accompanying figures.BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:

[0038] FIG. 1 is a schematic diagram illustrating a server for rendering graphics for applications on mobile devices and its operating environment.

[0039] FIG. 2 is a schematic diagram showing a conventional general graphics architecture of a server of FIG. 1.

[0040] FIG. 3 is a schematic diagram showing a novel graphics architecture of a server of FIG. 1 in accordance with some example embodiments described herein.

[0041] FIG. 4 is a schematic diagram of the loading and deletion of textures used by the server of FIG. 3 in accordance with example embodiments described herein.

[0042] FIG. 5 shows an exemplary timeline of the loading of three textures that are used in series using a conventional approach.

[0043] FIG. 6 shows an exemplary timeline of the loading of three textures that are used in series using the approach of the server of FIGS. 3 and 4.

[0044] FIG. 7 is a schematic diagram illustrating various components of the server of FIGS. 3 and 4 in accordance with some example embodiments described herein.

[0045] Similar reference numerals may have been used in different figures to denote similar components. Unless otherwise specifically noted, articles depicted in the drawings are not necessarily drawn to scale.DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0046] The present disclosure is made with reference to the accompanying drawings, in which embodiments are shown. However, many different embodiments may be used, and thus the description should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same elements, and prime notation is used to indicate similar elements, operations or steps in alternative embodiments. Separate boxes or illustrated separation of functional elements of illustrated systems and devices does not necessarily require physical separation of such functions, as communication between such elements may occur by way of messaging, function calls, shared memory space, and so on, without any such physical separation. As such, functions need not be implemented in physically or logically separated platforms, although such functions are illustrated separately for ease of explanation herein. Different devices may have different designs, such that although some devices implement some functions in fixed function hardware, other devices may implement such functions in a programmable processor with code obtained from a machine-readable medium. Lastly, elements referred to in the singular may be plural and vice versa, except wherein indicated otherwise either explicitly or inherently by context.

[0047] FIG. 1 shows a server computing system 20 for rendering graphics and its operating environment. The server computing system 20 is configured to generate graphics for a plurality of computing devices, and is a powering computing system with significant resources, such as memory, VRAM, and GPU performance. In the illustrated scenario, the server computing system 20 is in communication with a plurality of mobile devices 24 via a data communications network 28. The mobile devices 24 can include, for example, smartphones, tablets, laptop computers, or any other computing device capable of data communications and having a display for displaying graphics and a user input interface for receiving input from a user.

[0048] The data communications network 28 can be any suitable type of network for real-time communications of data that is sufficiently provisioned to carry graphics rendered in real time.

[0049] The server computing system 20 executes virtual machine (VM) instances 50 of one or more applications 22 on behalf of users of the mobile devices 24. Each VM instance 50 corresponds to instantiations of one or more applications 22 on behalf of a corresponding mobile device 24. While more than one application can be instantiated within the VM instance, typically only a single application is executing within the VM instance at any one time. The applications 22 can be, for example, games or computer-aided design applications. During execution of the one or more applications 22, the server computing system 20, at the instruction of the VM instances 50 of the applications 22, retrieves textures for rendering graphics from a database 32. The database 32 can be managed by the server computing system 20 or can be accessed via another computing device.

[0050] The mobile devices 24 execute VM clients 52 for displaying graphics received from the VM instances 50 and for providing input to the VM instances 50. Graphics received from the VM instances 50 are presented on displays of the mobile devices 24 and / or displays connected to the mobile devices 24, such as, for example, external monitors. Input for the VM instances 50 can be received via hardware buttons or controls of the mobile devices 24, via touchscreens of the mobile devices 24, one or more connected input devices (such as a wired or wireless game controller) , and / or any other suitable input device.

[0051] FIG. 2 shows a conventional general graphics architecture of the server computing system 20 of FIG. 1. The server computing system 20 includes a GPU driver 40, a GPU VRAM 44, and a GPU application-specific integrated circuit (ASIC) 48. The GPU driver 40 is software that allows operating system and applications to communicate with the GPU ASIC 48, and it translates high-level commands into a format the GPU ASIC 48 can execute, optimizing performance and ensuring compatibility with various programs and games. The GPU VRAM 44 is the memory used by the GPU ASIC to store image data and textures that need to be rendered. It acts as a buffer between the CPU of the server computing system 20 and the GPU ASIC 48, enabling smooth rendering of graphics. The GPU ASIC 48 is the graphics hardware that performs the rendering of graphics.

[0052] The GPU driver 40 has an application programming interface (API) for communicating with the VM instances 50 of the applications 22 executing on the server computing system 20. Each of the VM instances 50 is in communication with a corresponding VM client 52 executing on a mobile device 24 for presenting graphics and for receiving input. The VM instances 50 of the applications 22 control the texture management logic, and communicate texture handling commands (e.g., the loading and deleting of textures) to the GPU driver 40 directly, without consideration of platform resources, and without consideration of other VM instances 50 of the same application 22 and / or other applications 22.

[0053] FIG. 3 shows a novel server computing system 100 in accordance with some embodiments of the present disclosure. The server computing system 100 is similar to the server computing system 20 of FIGS. 1 and 2, but includes a platform level texture manager 104 that better manages the loading and the deletion of textures from GPU VRAM 44. The texture manager 104 intermediates between the VM instances 50 of the applications and the GPU driver 40, the GPU VRAM 48, and the GPU ASIC 48. The VM instances 50 can be executing instances of one or more applications (such as games or other graphical applications) . The VM instances 50 request graphical images or series of graphical images forming a video sequence to be rendered. The graphical images are generally 3D but may also be two-dimensional in some cases. The texture loading and deletion commands determined and issued by the texture manager 104 are optimized by redundancy removal, prediction, and multi-device / multi-view sharing.

[0054] Upon receiving requests for graphical images or series of graphical images from any of the VM instances 50, the texture manager 104 interacts with the GPU driver 40, the GPU VRAM (alternatively referred to hereinafter as simply VRAM) 44, and the GPU ASIC (alternatively referred to hereinafter as simply ASIC) 48 as will be described below.

[0055] The server computing system 100 may manage graphics rendering and texture loading and deleting for a set of VM instances 50 instantiating one or more applications. Each of the VM instances 50 is in communication with a corresponding VM client 52 executing on a mobile device 24 for delivering graphics to be displayed via the mobile device 24 and for receiving input via the mobile device 24.

[0056] FIG. 4 shows the processes of loading and deletion textures in GPU VRAM 44 of FIG. 3 by the texture manager 104. The processes include a passive texture loading pipeline 200, a passive texture deletion pipeline 300, a proactive texture deletion pipeline 400, and a proactive texture loading pipeline 500. Passive loading and deleting of textures in VRAM occur when applications on mobile devices request these textures to be loaded and unloaded. Proactive loading and deleting of textures are performed by the texture manager without receiving a request to load or delete a texture in VRAM.

[0057] The texture database 32 stores different texture-related information. The texture-related information includes a texture key, a texture file, a texture log, and texture correlations (that is, for each texture, an identification of any other textures that are likely to be needed to render graphics shortly after the particular texture is required) . The texture key is a unique identifier generated from the texture file and / or one or more attributes thereof, such as the filename, the last modified date, the file size, etc. The texture log stores entries for each time a texture is loaded in VRAM, including the texture key, the VRAM address, the size of the file, and whether the texture has subsequently been deleted from VRAM.

[0058] For the passive texture loading pipeline 200, when a texture loading command specifying a particular texture is received from an instantiated application executing in a VM instance corresponding to one of the mobile devices 24, the texture manager generates a unique key for the requested texture (210) . The unique key can be any type of unique identifier generated in any suitable manner that has a zero or near-zero chance of collisions. For example, the texture key can be generated using a secure hash algorithm (SHA or SHA2) . Further, the unique key is generated so that it is always the same for a particular texture, regardless of when the texture is being requested or what application is requesting the texture. This is done to address the case where the same texture can have some different attributes, such as path or filename, but the files still the same texture data (e.g., a binary match) . In this manner, duplicate texture storage in VRAM can be avoided. Typically, the same texture is not used by multiple applications, but may be in some scenarios.

[0059] It is then determined if the requested texture is in the texture database (220) . Using the specific texture filename or the texture key, the texture manager 104 searches the texture database 32 to determine if the requested texture has been registered in the texture database 32. If the requested texture is not registered in the texture database 32, the texture file is copied to VRAM (240) . The texture just copied to VRAM is then registered in the texture database 32 (250) . When registering a texture in the texture database 32, the texture file, the texture key generated at 210, the VRAM address where the texture has been copied to VRAM, and the size of the texture are recorded in the texture database 32. In some configurations, the texture database 32 registers all requests for textures, including when the textures are copied to VRAM, and can include an application or application instance identifier. In other configurations, the texture database 32 registers entries when textures are copied to VRAM. In further configurations, the texture database 32 only stores one active entry for a texture, and may delete it or mark the texture as deleted in the entry once the texture is deleted from VRAM. After copying the texture to VRAM at 240 and registering the texture in the texture database 250, the VRAM address and the size of the texture file are passed to the application executing in the VM instance (260) .

[0060] If, instead, it is determined at 22 that the requested texture is in the texture database 32, it is determined if the texture is in VRAM (230) . The texture database 32 maintains an active entry for a texture that is actively in VRAM that includes the texture key, the VRAM address, and the texture size. If this active entry is located for the requested texture (using the texture key) , the texture manager retrieves the VRAM address and the texture size from the texture database 32 and passes them back to the application executing in the VM instance at 260. If there is no active entry for the texture in the texture database 32, the texture is copied to VRAM 240 (240) , after which the VRAM address and the texture size are registered in the texture database 32 as an active entry for the texture. After registering the active entry for the texture in the texture database 32, the VRAM address and texture size are passed back to the application executing in the VM instance at 260.

[0061] Texture correlation among the textures is built up based on texture usage history. The texture manager observes the requests for textures from the VM instances 50 instantiating applications on the server computing system 100 and identify patterns between textures. For example, if requests to load textures B and C almost always follow requests to load texture A, this can indicate a strong correlation between texture A and textures B and C. This information can be either gleaned from the log in the texture database 32 (where such a log is maintained) , or may be recorded elsewhere by the texture manager.

[0062] During passive texture deletion 300, upon receiving a request to delete the texture in VRAM from a an application executing in a VM instance 50 instantiated on behalf of a mobile device 24, the status of VRAM is checked to determine the amount of VRAM available (310) . If VRAM has enough room, the deletion request from the VM instance 50 is ignored, the texture will be kept in VRAM, otherwise it will decide which texture to be deleted based on certain rules; e.g., Least Recently Used (LRU) . If it is determined at 310 that VRAM does not have enough room, the texture manager determines if the texture is in the texture database 32 (320) . In order to check, a texture key is generated for the requested texture and it is determined by the texture manager if a corresponding active entry exists in the texture database 32. If the texture database 32 does not include an active entry for the texture, if the texture is not in the texture database 32, the deletion request is ignored (330) . If, instead, there is an active entry for the texture in the texture database 32, the texture specified in the request is deleted in VRAM (340) . The VRAM address and the file size are retrieved from the active entry and used to delete the texture from VRAM. Upon deletion of the texture from VRAM, the log for the texture in the texture database 32 is removed or marked as inactive, as appropriate based on the configuration (350) . The texture key and the texture file are still kept in the texture database 32.

[0063] Proactive texture deletion is performed by the texture manager during operation independent of requests from applications executing in VM instances 50on behalf of mobile devices 24. By proactively deleting textures from VRAM, space in VRAM can be made in preparation for subsequently requested textures called for by applications executing in VM instances on behalf of the mobile devices 24 and / or for proactively loaded textures.

[0064] During proactive texture deletion 400, the status of VRAM is monitored to determine the amount of unused VRAM available (410) . The texture manager then determines if it is beneficial to delete one or more textures from VRAM (420) . If the amount of VRAM available for immediate use for loading textures determined at 410 drops below a desirable level, such as a threshold that may be static or dynamically set, such as based on textures that are desirable to load proactively, textures in VRAM can be deleted to increase the amount of VRAM available across all VM instances 50 executing on the server computing system. In another example, the threshold can be determined according to the application (s) being executed by the mobile devices 24. For example, for the type of application does not change scene frequently, the “likelihood of deletion previous texture” is low. This likelihood can be exposed as a parameter to let application provide a hint.

[0065] If it is determined that there is no immediate need to delete textures proactively at 420, the texture manager continues to monitor the status of VRAM at 410. If, instead, it is determined that it is beneficial to delete one or more textures from VRAM at 420, one or more textures are deleted in VRAM (430) . The texture manager analyzes the textures in VRAM to determine which texture or textures are to be deleted based on certain rules; e.g. least-recently used (LRU) The LRU algorithm operates on the principle that texture accessed recently are more likely to be used again in the near future. The texture manager maintains a list of textures in VRAM, ordered from most recently used to least recently used. When a texture is accessed, it's moved to the front of the queue. If the VRAM reaches capacity and a new texture needs to be added, the algorithm removes the texture at the end of the list, which is considered the least recently used.

[0066] In another example, the texture file size can be used to identify larger textures to delete first from VRAM to more quickly free up space. In a further example, smaller textures can be identified for deletion before larger files as the benefit of maintaining these smaller textures in VRAM is less than for larger textures. In another example, textures can be identified for deletion based on the frequency with which the textures are requested.

[0067] Once the one or more textures are deleted from VRAM, the texture database 32 is updated by removing the active entries for these textures or marking them as inactive (440) .

[0068] The texture manager can learn of the correlations between textures by the sequence of textures requested to be loaded and deleted by each of the applications executing in the VM instances 50 on behalf of the mobile devices 24. This can be done by the texture manager tracking texture requests made by each application executing in a VM instance, by analyzing the texture load logs in the texture database 32 where each request is logged, or by any other suitable method.

[0069] In addition to proactively deleting textures from VRAM, the texture manager proactively loads textures into VRAM at least partially independent of texture loading requests from the VM instances in anticipation of texture loading requests expected to be received from one or more of the applications executing in the VM instances. Sets of two or more textures can be deemed to be correlated if load requests for the two or more textures are often received in temporal proximity (e.g., within a threshold time period) of each other from the same application executing in the same VM instance. The texture correlations can be built up based on the sequence of “texture in use” from the application logic using techniques such as, but not limited to, Markov chain and / or neural networks models. Texture loading for predicted future frames is run in one or more separate threads that do not affect the performance of current frame rendering.

[0070] For example, if an object being rendered has four textures required to render the object, it is likely that whenever one of the textures is requested to be loaded that the other three textures will be requested to be loaded. By proactively loading these textures in advance of these requests, graphic rendering times can be significantly reduced, resulting in virtual applications on the mobile devices 24 feeling more responsive. In the case of games, this improved responsiveness can diminish the perceived difference between a game that is graphically rendered locally and one that is graphically rendered on one or more remote servers.

[0071] The process of proactive texture loading 500 begins with the prediction of textures to be requested for future frames (i.e., images or portions thereof for generating a video sequence) (510) . Correlations between textures can be used to predict textures that may be required in the near future. The texture manager determines if these predicted textures are already in VRAM (520) . If a predicted texture is already in VRAM, it can be marked with a score so this predicted texture can be maintained in VRAM if possible. If it is determined at 520 that a predicted texture is not loaded in VRAM, the texture manager copies the texture from the texture database 32 to VRAM (530) . It then updates the texture database with the VRAM address and the size (540) . Once the texture database 32 is updated at 540 or if it is determined that the predicted texture is already loaded in VRAM at 520, the texture manager passes the VRAM address and size to the GPU driver (550) .

[0072] If a predicted texture is loaded into VRAM, but a request for the texture is not received within an expected period of time, this misprediction is used as feedback for texture correlation to adjust future predictions.

[0073] FIG. 5 shows the process of loading and rendering three textures via a conventional cloud-based mobile gaming platform. A first texture is requested by a VM instance and retrieved, and then a first frame is rendered using the first texture and served to the corresponding mobile device. Next, a second texture is requested and retrieved, and a second frame is rendered using the second texture and served to the mobile device. Finally, a third texture is requested and retrieved, and a third frame is rendered using the third texture and served to the mobile device. As a result, there are delays in the rendering process as each subsequent texture must be loaded after the last frame has been rendered. While this example is greatly simplified by indicating that a single texture is required to render graphic frames, it will be appreciated that the same logic can be extended to scenarios where more than one texture are required to render newer frames.

[0074] FIG. 6 shows the process of loading and rendering the same three textures using the system of FIGS. 3 and 4. Upon receiving a request for a first texture, the texture manager identifies and loads textures that are related to the first texture into VRAM. This happens simultaneously with the rendering of the first frame before serving it to the corresponding mobile device. As a result, the second and third frames can be rendered more quickly because the second and third textures have been preloaded. As will be understood, this will provide a more responsive application on the mobile device side.

[0075] FIG. 7 shows various physical and logical components of the server computing system 100 for rendering graphics in accordance with an embodiment of the present disclosure. Although an example embodiment of the server computing system 100 is shown and discussed below, other embodiments may be used to implement examples disclosed herein, which may include components different from those shown. Although FIG. 7 shows a single instance of each component of the server computing system 100, there may be multiple instances of each component shown.

[0076] The server computing system 100 includes one or more processors 104, such as a central processing unit, a microprocessor, an application-specific integrated circuit (ASIC) , a field-programmable gate array (FPGA) , a dedicated logic circuitry, a tensor processing unit, a neural processing unit, a dedicated artificial intelligence processing unit, or combinations thereof. The one or more processors 604 may collectively be referred to as a processor 604.

[0077] The server computing system 100 also includes one or more GPUs 605. The one or more GPUS 605 may collectively be referred to as a GPU 605. The GPU 605 is a specialized electronic circuit originally designed for digital image processing and to accelerate the rendering of computer graphics.

[0078] VRAM 606 is also provided for use by the GPU 605. VRAM 606 is dedicated memory used to store graphics data as a framebuffer to be rendered. It often uses a different technology than other computer memory, in order to be read quickly for rendering graphics using textures loaded into the VRAM 606. VRAM 606 can be provided in the same package as the GPU 605, but can also be provided separately in some cases.

[0079] The server computing system 100 may further include a display 608 for outputting data and / or information in some applications, but may not in some other applications.

[0080] One or more network interfaces 609 enable the server computing system 100 to communicate with other computing devices, such as mobile devices, over a data communications network. The one or more network interfaces 609 may collectively be referred to as a network interface 609.

[0081] The server computing system 100 includes one or more memories 612 (collectively referred to as “memory 612” ) , which may include a volatile or non-volatile memory (e.g., a flash memory, a random-access memory (RAM) , and / or a read-only memory (ROM) ) . The non-transitory memory 612 may store machine-executable instructions for execution by the processor 604. A set of machine-executable instructions 616 defining a graphics rendering system (described herein) is shown stored in the memory 612, which may be executed by the processor 604 to perform the steps of the methods for rendering graphics described herein. The memory 612 may include other machine-executable instructions for execution by the processor 604, such as machine-executable instructions for implementing an operating system, and other applications or functions. These applications can include the applications instantiated by the server computing system 100 and VM software for compartmentalizing the instantiated applications and for allowing the VM clients executing on mobile devices to connect thereto.

[0082] The memory 612 also stores the texture database 32 that houses textures for rendering graphics for applications served by the server computing system 100.

[0083] In some examples, the server computing system 100 may also include one or more electronic storage units (not shown) , such as a solid state drive, a hard disk drive, a magnetic disk drive and / or an optical disk drive. In some examples, one or more datasets and / or modules may be provided by an external memory (e.g., an external drive in wired or wireless communication with the server computing system 100) or may be provided by a transitory or non-transitory computer-readable medium. Examples of non-transitory computer readable media include a RAM, a ROM, an erasable programmable ROM (EPROM) , an electrically erasable programmable ROM (EEPROM) , a flash memory, a CD-ROM, or other portable memory storage. The storage units and / or external memory may be used in conjunction with memory 612 to implement data storage, retrieval, and caching functions of the server computing system 100.

[0084] The components of the server computing system 100 may communicate with each other via a bus, for example. In some embodiments, the server computing system 100 is a distributed computing system and may include multiple computing devices in communication with each other over a network, as well as optionally one or more additional components. The various operations described herein may be performed by different computing devices of a distributed system in some embodiments. In some embodiments, the server computing system 100 is a virtual machine provided by a cloud computing platform.

[0085] The steps (also referred to as operations) in the flowcharts and drawings described herein are for purposes of example only. There may be many variations to these steps / operations without departing from the teachings of the present disclosure. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified, as appropriate.

[0086] In other embodiments, the same approach described herein can be employed for other modalities. General

[0087] Through the descriptions of the preceding embodiments, the present invention may be implemented by using hardware only, or by using software and a necessary universal hardware platform, or by a combination of hardware and software. The coding of software for carrying out the above-described methods described is within the scope of a person of ordinary skill in the art having regard to the present disclosure. Based on such understandings, the technical solution of the present invention may be embodied in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be an optical storage medium, flash drive or hard disk. The software product includes a number of instructions that enable a computing device (personal computer, server, or network device) to execute the methods provided in the embodiments of the present disclosure.

[0088] All values and sub-ranges within disclosed ranges are also disclosed. Also, although the systems, devices and processes disclosed and shown herein may comprise a specific plurality of elements, the systems, devices and assemblies may be modified to comprise additional or fewer of such elements. Although several example embodiments are described herein, modifications, adaptations, and other implementations are possible. For example, substitutions, additions, or modifications may be made to the elements illustrated in the drawings, and the example methods described herein may be modified by substituting, reordering, or adding steps to the disclosed methods.

[0089] Features from one or more of the above-described embodiments may be selected to create alternate embodiments comprised of a sub-combination of features which may not be explicitly described above. In addition, features from one or more of the above-described embodiments may be selected and combined to create alternate embodiments comprised of a combination of features which may not be explicitly described above. Features suitable for such combinations and sub-combinations would be readily apparent to persons skilled in the art upon review of the present disclosure as a whole.

[0090] In addition, numerous specific details are set forth to provide a thorough understanding of the example embodiments described herein. It will, however, be understood by those of ordinary skill in the art that the example embodiments described herein may be practiced without these specific details. Furthermore, well-known methods, procedures, and elements have not been described in detail so as not to obscure the example embodiments described herein. The subject matter described herein and in the recited claims intends to cover and embrace all suitable changes in technology.

[0091] Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the invention as defined by the appended claims.

[0092] The present invention may be embodied in other specific forms without departing from the subject matter of the claims. The described example embodiments are to be considered in all respects as being only illustrative and not restrictive. The present disclosure intends to cover and embrace all suitable changes in technology. The scope of the present disclosure is, therefore, described by the appended claims rather than by the foregoing description. The scope of the claims should not be limited by the embodiments set forth in the examples, but should be given the broadest interpretation consistent with the description as a whole.

Claims

1.A computer-implemented method for rendering graphics, comprising:receiving a request for a texture from a first application instance executing on a computing system;determining if a location of the texture loaded in a video random-access memory (VRAM) of the computing system is registered in a texture database;if the location of the texture in the VRAM is unregistered in the texture database:loading the texture in the VRAM; andregistering the location of the texture in the VRAM in the texture database; andproviding the texture from the VRAM from the location identified in the texture database to the application instance.2.The computer-implemented method of claim 1, further comprising:generating a unique key for the texture requested by the first application, andregistering the unique key with the location in the VRAM.3.The computer-implemented method of claim 2, wherein the registering comprises:generating the unique key for the texture and storing the location of the texture with the unique key, and wherein the determining comprises:generating the unique key for the texture; anddetermining if the unique key is in the texture database.4.The computer-implemented method of any one of claims 1 to 3, further comprising:receiving a delete request to delete a texture from the VRAM from the first application instance or a second application instance;determining if the location of the texture in the VRAM is registered for the texture in the texture database; andif the location of the texture in the VRAM is registered for the texture in the texture database, deleting the texture from the location of the VRAM.5.The computer-implemented method of claim 4, further comprising:if the location of the texture in the VRAM is registered for the texture in the texture database, removing the location of the texture in the VRAM from the texture database.6.A computer-implemented method for rendering graphics, comprising:determining an in-use level of a VRAM of a computing system, the VRAM storing a set of textures requested by one or more application instances;determining if a condition for proactively deleting a subset of the set of textures stored in the VRAM is satisfied using the in-use level of the VRAM;selecting the subset of the set of textures in the VRAM for deletion if the condition is satisfied; anddeleting the subset of the set of textures in the VRAM.7.The computer-implemented method of claim 6, further comprising:maintaining a texture database in storage of the computing system, the texture database storing, for each of the set of textures, a location in the VRAM and a unique key generated.8.The computer-implemented method of claim 6 or 7, further comprising:storing log information in storage of the computing system for requests for the set of textures received from the one or more application instances; anddetermining the subset of the set of textures using the log information.9.The computer-implemented method of claim 8, further comprising:analyzing the log information to identify correlated textures, wherein the correlated textures in the set of textures include a second texture that is requested after the first texture within a threshold time period with a minimum threshold probability;receiving a new request for the first texture from the one of the one or more application instances;determining if the second texture is loaded in video random-access memory (VRAM) ; andloading the second texture in the VRAM if the second texture is not loaded in the VRAM.10.A computer-implemented method for rendering graphics, comprising:receiving a request to delete a texture from a VRAM from a first application instance;determining if a location of the texture in the VRAM is registered for the texture in a texture database; andif the location of the texture in the VRAM is registered for the texture in the texture database, deleting the texture from the location of the VRAM, and removing the location of the texture in the VRAM from the texture database.11.A computer-implemented method for rendering graphics, comprising:analyzing log information stored by a computing system for requests for a set of textures received from a set of application instances to identify correlated textures in the set of textures, wherein the correlated textures in the set of textures include a second texture that is requested after a first texture within a threshold time period with a minimum threshold probability;receiving a new request for the first texture from one application instance of the set of application instances;determining if the second texture is loaded in a video random-access memory (VRAM) ; andloading the second texture in the VRAM if the second texture is not loaded in the VRAM.12.A computing system for rendering graphics, comprising:one or more processors; anda non-transitory storage medium storing machine-executable instructions that, when executed by the one or more processors, cause the one or more processors to:receive a request for a texture from a first application instance executing on the computing system;determine if a location of the texture loaded in a video random-access memory (VRAM) of the computing system is registered in a texture database;if the location of the texture in the VRAM is unregistered in the texture database:load the texture in the VRAM; andregister the location of the texture in the VRAM in the texture database; andprovide the texture from the VRAM from the location identified in the texture database to the application instance.13.The computing system of claim 12, wherein the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to:generate a unique key for the texture requested by the first application, andregister the unique key with the location in the VRAM.14.The computing system of claim 13, wherein the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to:generate the unique key for the texture and storing the location of the texture with the unique key,determine if the unique key is in the texture database when determining if the location of the texture in the VRAM is unregistered in the texture database.15.The computing system of any one of claims 12 to 14, wherein the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to:receive a delete request to delete a texture from the VRAM from the first application instance or a second application instance;determine if the location of the texture in the VRAM is registered for the texture in the texture database; andif the location of the texture in the VRAM is registered for the texture in the texture database, delete the texture from the location of the VRAM.16.The computing system of claim 15, wherein the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to:if the location of the texture in the VRAM is registered for the texture in the texture database, remove the location of the texture in the VRAM from the texture database.17.A computing system for rendering graphics, comprising:one or more processors; anda non-transitory storage medium storing machine-executable instructions that, when executed by the one or more processors, cause the one or more processors to:determine an in-use level of a VRAM of a computing system, the VRAM storing a set of textures requested by one or more application instances;determine if a condition for proactively deleting a subset of the set of textures stored in the VRAM is satisfied using the in-use level of the VRAM;select the subset of the set of textures in the VRAM for deletion if the condition is satisfied; anddelete the subset of the set of textures in the VRAM.18.The computing system of claim 17, wherein the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to:maintain a texture database in storage of the computing system, the texture database storing, for each of the set of textures, a location in the VRAM and a unique key generated.19.The computing system of claim 17 or 18, wherein the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to:store log information in storage of the computing system for requests for the set of textures received from the one or more application instances; anddetermine the subset of the set of textures using the log information.20.The computing system of claim 19, wherein the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to:analyze the log information to identify correlated textures, wherein the correlated textures in the set of textures include a second texture that is requested after the first texture within a threshold time period with a minimum threshold probability;receive a new request for the first texture from the one of the one or more application instances;determine if the second texture is loaded in video random-access memory (VRAM) ; andload the second texture in the VRAM if the second texture is not loaded in the VRAM.21.A computing system for rendering graphics, comprising:one or more processors; anda non-transitory storage medium storing machine-executable instructions that, when executed by the one or more processors, cause the one or more processors to:receive a request to delete a texture from a VRAM from a first application instance;determine if a location of the texture in the VRAM is registered for the texture in a texture database; andif the location of the texture in the VRAM is registered for the texture in the texture database, delete the texture from the location of the VRAM, and removing the location of the texture in the VRAM from the texture database.22.A computer-implemented method for rendering graphics, comprising:one or more processors; anda non-transitory storage medium storing machine-executable instructions that, when executed by the one or more processors, cause the one or more processors to:analyze log information stored by a computing system for requests for a set of textures received from a set of application instances to identify correlated textures in the set of textures, wherein the correlated textures in the set of textures include a second texture that is requested after a first texture within a threshold time period with a minimum threshold probability;receive a new request for the first texture from one application instance of the set of application instances;determine if the second texture is loaded in a video random-access memory (VRAM) ; andload the second texture in the VRAM if the second texture is not loaded in the VRAM.23.A non-transitory machine-readable medium having tangibly stored thereon executable instructions for execution by one or more processors, wherein the executable instructions, in response to execution by the one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 12.

Images