Method and apparatus for using daemon-based resource optimization graphics driver

Abstract

Disclosed is a system and method of optimizing a graphics driver. The system can be embodied as a computing device including a storage device internal to the computing device, a graphics processing unit including a driver, and a controller. The controller can be configured to run a daemon process that optimizes a shader and / or a shader pipeline for an application that is not running on the computing device when the application is not running on the computing device, and stores at least one optimization for the shader in the storage device. The at least one optimization can be based on the application. The daemon process can also receive a request from the driver of the GPU for an optimization for the shader / shader pipeline during runtime compilation of the shader, and provide the at least one optimization from the storage device to the driver of the GPU.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 155,727, filed March 2, 2021, and U.S. Provisional Application No. 17 / 227,270, filed April 9, 2021, the disclosures of which are incorporated herein by reference in their entirety. Technical Field

[0003] The topics disclosed herein relate to graphics processing units (GPUs). More specifically, the topics disclosed herein relate to systems and methods for optimizing graphics drivers. Background Technology

[0004] A graphics processing unit (GPU) uses shader programs (shaders), textures, and geometry models to render application-specific graphics for a display. Typically, shader programs for GPUs on portable devices such as smartphones and tablets are compiled at runtime by the portable device's central processing unit (CPU) to render application-specific graphics. Shaders are compiled at runtime because applications using the GPU may not have all the parameters relevant to the portable device's native GPU hardware before runtime.

[0005] Runtime shader compilation can have inherent trade-offs because optimizations occur during multiple compiler passes when there's only a limited time window to load the application before the user becomes impatient. Additional constraints might include limited battery power available for all system operations (not just shader compilation) and the maximum operating temperature that multiple compilation passes might exceed. As the number of optimizations increases, compilation time also increases accordingly. For example, if a game application compiles thousands of shaders, it could take a very long time for the application to be ready, increasing the likelihood of user impatience due to delays. Therefore, shortcuts are often used during runtime compilation to improve compilation time, but this comes at the cost of shader program efficiency. Typically, trade-offs can be made at a coarse level (e.g., application-independent) to be most efficient for most applications and device hardware combinations. Generally, trade-offs are general-type optimizations for the end-user environment, which may only be assumed. Memory blobs and similar storage techniques can be used to provide persistence to improve load times, but even so, the original compile-time operation may not have an infinite amount of time to optimize shaders / assets. Summary of the Invention

[0006] An example embodiment provides a computing device that may include storage, a graphics processing unit (GPU), and a controller within the computing device. The GPU may include a driver. The controller may be coupled to the storage and may be configured to run a daemon process that optimizes one or more of a shader and a shader pipeline for an application residing on the computing device. The daemon process may store at least one optimization for one or more of the shaders and shader pipelines in the storage, wherein the at least one optimization may be application-based. The daemon process may, in response to a request from the GPU driver for optimizations for the shaders during runtime compilation, provide at least one optimization for one or more of the shaders and shader pipelines from the storage to the GPU driver. In one embodiment, the daemon process may be configured to optimize one of the shaders and shader pipelines when the computing device is not running an application and the computing device is charging. In another embodiment, at least one optimization for one or more of the shaders and shader pipelines may include converting one or more of the shaders and shader pipelines into the native format of the graphics processing unit (GPU) of the computing device. In yet another embodiment, a daemon process may be configured to optimize a texture used by the application when the computing device is not running the application, store at least one optimization for the texture in a storage device, and provide at least one optimization for the texture to the GPU driver from the storage device in response to a request from the GPU driver for optimization of the texture during runtime compilation of the shader. In one embodiment, the daemon process may be configured to return to the GPU driver a descriptor indicating at least one characteristic of the at least one optimization that differs from a non-optimized version of the texture. In yet another embodiment, the daemon process may be configured to optimize a geometry model used by the application when the computing device is not running the application, store at least one optimization for the geometry model in a storage device, and provide at least one optimization for the geometry model to the GPU driver from the storage device in response to a request from the GPU driver for optimization of the geometry model during runtime compilation of the shader. In one embodiment, the daemon process can be configured to send at least one optimization for one or more of the shaders and shader pipelines to a database external to the computing device. The daemon process can also be configured to provide at least one optimization for one or more of the shaders and shader pipelines from one of internal storage devices and an external database to the graphics processing unit driver. The computing device can be a smartphone, tablet, or laptop computer.

[0007] An example embodiment provides a computing device that may include a storage device, a graphics processing unit (GPU), and a controller within the computing device. The GPU may include a driver. The controller may be coupled to the storage device and may be configured to run a daemon process that performs the following operations: when the computing device is not running an application residing on the computing device, optimizing one of a shader and a texture for the application, and storing at least one optimization for the shader and at least one optimization for the texture in the storage device; and, in response to a request from the GPU driver for optimization of one of the shader and the texture during runtime compilation of the shader, providing one of the at least one optimization for the shader and at least one optimization for the texture from the storage device to the GPU driver. In one embodiment, the daemon process may be configured to optimize one of the shader and the texture when the computing device is not running an application and the computing device is charging. In another embodiment, the daemon process can be configured to optimize a geometric model, including 3D vertices, used by the application when the computing device is not running an application, store at least one optimization for the geometric model in a storage device, and, in response to a request from the graphics processing unit's driver for optimizations of the geometric model during runtime compilation of the shader, provide at least one optimization for the geometric model from the storage device to the graphics processing unit's driver. In yet another embodiment, the daemon process can be configured to send one of at least one optimization for the shader and one of at least one optimization for the texture to a database external to the computing device. In one embodiment, the daemon process can be configured to provide one of at least one optimization for the shader and one of at least one optimization for the texture to the graphics processing unit's driver from one of storage devices internal to the computing device and one of databases external to the computing device. The computing device can be a smartphone, tablet, or laptop computer.

[0008] An example embodiment provides a method for optimizing shader compilation on a computing device, wherein the method may include: optimizing one of a shader and a texture for the application by a daemon process when the computing device is not running an application residing on the computing device; storing at least one optimization for the shader and at least one optimization for the texture in a storage device within the computing device by the daemon process; receiving a request from a driver of the graphics processing unit of the computing device for optimization of one of the shader and the texture during runtime compilation of the shader by the daemon process; and providing one of the at least one optimization for the shader and at least one optimization for the texture from the storage device to the driver of the graphics processing unit. In one embodiment, optimizing one of the shader and the texture when the computing device is not running an application may further include: optimizing one of the shader and the texture when the computing device is not running an application and the computing device is charging. In another embodiment, the method may further include: optimizing a geometric model used by the application by a daemon process when the computing device is not running an application; storing at least one optimization for the geometric model in a storage device by the daemon process; receiving a request from a driver of the graphics processing unit for optimizations for the geometric model during runtime compilation of a shader by the daemon process; and providing the at least one optimization for the geometric model to the driver of the graphics processing unit from the storage device by the daemon process. In one embodiment, the method may further include: sending one of at least one optimization for a shader and one of at least one optimization for a texture to a database external to the computing device by the daemon process; and providing one of at least one optimization for a shader and one of at least one optimization for a texture to the driver of the graphics processing unit from one of storage devices internal to the computing device and one of databases external to the computing device by the daemon process. The computing device may be a smartphone, tablet, or laptop computer. Attached Figure Description

[0009] In the following sections, aspects of the subject matter disclosed herein will be described with reference to exemplary embodiments illustrated in the accompanying drawings, in which:

[0010] Figure 1 A system for graphics driver optimization based on the topics disclosed herein is described;

[0011] Figure 2 A flowchart depicting an example embodiment of a method for optimizing graphics drivers using cloud-based resources, based on the subject matter disclosed herein; and

[0012] Figure 3 This paper describes an electronic device that provides graphics driver optimization based on the topics disclosed herein. Detailed Implementation

[0013] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of this disclosure. However, those skilled in the art will understand that the aspects disclosed can be practiced without these specific details. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to obscure the subject matter of this disclosure.

[0014] Throughout this specification, references to "an embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment disclosed herein. Therefore, the phrases "in an embodiment," "in an embodiment," or "according to an embodiment" (or other phrases with similar meanings) appearing in various places throughout this specification may not necessarily refer to the same embodiment. Furthermore, in one or more embodiments, particular features, structures, or characteristics may be combined in any suitable manner. In this regard, as used herein, the word "exemplary" means "as an example, instance, or illustration." Any embodiment described herein as "exemplary" should not be construed as necessarily being more preferred or advantageous than other embodiments. Furthermore, in one or more embodiments, particular features, structures, or characteristics may be combined in any suitable manner. Additionally, depending on the context discussed herein, singular items may include corresponding plural forms, and plural items may include corresponding singular forms. Similarly, hyphenated terms (e.g., "two-dimensional", "pre-determined", "pixel-specific", etc.) are occasionally used interchangeably with their non-hyphenated counterparts (e.g., "two-dimensional", "predetermined", "pixel specific", etc.), and uppercase entries (e.g., "counter clock", "row select", "pixout", etc.) are interchangeable with their non-uppercase counterparts (e.g., "counter clock", "row select", "pixout", etc.). This occasional interchangeability should not be considered inconsistent with each other.

[0015] Furthermore, depending on the context of this discussion, singular items may include corresponding plural forms, and plural items may include corresponding singular forms. It should also be noted that the various figures shown and discussed herein (including component diagrams) are for illustrative purposes only and are not drawn to scale. For example, the dimensions of some elements may be exaggerated relative to others for clarity. Additionally, reference numerals are repeated between figures where deemed appropriate to indicate corresponding and / or similar elements.

[0016] The terminology used herein is for describing some exemplary embodiments only and is not intended to limit the claimed subject matter. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms “comprise” and / or “comprising,” when used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof.

[0017] It should be understood that when an element or layer is referred to as "located in," "connected to," or "coupled to" another element or layer, that element or layer may be directly located in, connected to, or coupled to that other element or layer, or there may be an element or layer in between. Conversely, when an element is referred to as "directly located in," "directly connected to," or "directly coupled to" another element or layer, there is no element or layer in between. The same notation refers to the same element throughout. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0018] As used herein, the terms “first,” “second,” etc., serve as labels for the nouns that follow them and do not imply any kind of ordering (e.g., spatial, temporal, logical, etc.) unless explicitly defined as such. Furthermore, the same reference numerals may be used across two or more figures to refer to parts, components, blocks, circuits, units, or modules having the same or similar functions. However, such use is merely for simplicity of description and ease of discussion; it does not imply that the structural or architectural details of such components or units are identical across all embodiments, or that such commonly referenced parts / modules are the only way to implement some of the exemplary embodiments disclosed herein.

[0019] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this subject pertains. It should also be understood that terms (such as those defined in common dictionaries) should be interpreted as having the meaning consistent with their meaning in the context of the relevant field, and will not be interpreted in an idealized or overly formal sense unless explicitly defined herein.

[0020] As used herein, the term "module" refers to any combination of software, firmware, and / or hardware configured to provide the functionality described herein in conjunction with modules. For example, software can be embodied as a software package, code, and / or instruction set or instructions, and the term "hardware" as used in any implementation described herein can include, for example, single or arbitrary combinations of assemblies, hardwired circuitry, programmable circuitry, state machine circuitry, and / or firmware storing instructions executed by programmable circuitry. These modules can be embodied collectively or individually as circuitry forming part of a larger system, such as, but not limited to, integrated circuits (ICs), system-on-a-chip (SoCs), assemblies, etc.

[0021] In one embodiment, the subject matter disclosed herein provides a system and process for scanning portable devices to find specific applications (target applications) (such as games) residing on the device and compiling shaders at runtime. Portable devices can be, for example, closed products such as smartphones, tablets, laptops, or fixed appliances, including a specific GPU with a specific clock rate and a display screen with a specific size, resolution, and fixed and / or variable refresh rates. The process can be a daemon process or a daemon-like application running on the device in the background and not under the direct control of the interactive user. When the device is idle, the daemon process can recompile stored shaders and / or complete the shader pipeline with more extensive optimizations enabled; similarly, data assets for the application (e.g., textures and / or geometry models with 3D vertices representing characters or 3D objects) can be converted to a more optimized format utilizing native hardware. Therefore, these shaders and data assets can be customized for the device. In other words, when the device is not running the target application and / or when the device is charging (and is typically idle), shaders and data assets can be compiled or optimized "offline" by the daemon process using "unbounded" compilation time to generate improvements and optimizations that can be stored locally for later use. When the target application is running, the GPU driver on the device can communicate with the daemon process to obtain any improvements and / or optimizations (shaders and / or data assets), where these improvements and / or optimizations are stored locally on the device and can be used on a per-application basis to replace the shaders and / or data assets that are requested to be compiled / retrieved at runtime.

[0022] The daemon process can use heuristics to identify problematic interactions between the GPU driver and specific applications, and generate "offline" improvements and optimizations to improve application performance, startup time, and application-specific bug fixes. For example, application-based offline improvements and optimizations may include, but are not limited to: improving shader compiler configurations and / or settings to enhance shader compilation efficiency and / or shader compilation time; reducing shader compiler / driver overhead; reducing application load (startup) time; generating pre-compiled shader pipelines; enabling or disabling GPU driver settings / driver capabilities; altering graphics driver capability limitations; improving or optimizing textures to provide a high level of texture quality in the device's native format; generating textures with additional quality and size; generating different texture compressions; generating application-specific enhancements; and / or improving peak application performance.

[0023] In another embodiment, the subject matter disclosed herein provides a system and process for scanning devices to find specific applications that compile shaders at runtime. The disclosed system and process can use “unlimited” compilation time during device idle time to compile improved and / or optimized shaders and / or data assets for the application, generating improvements and optimizations that can be stored locally for later use. Furthermore, the disclosed system and method can download improved and / or optimized shaders and / or data assets from external storage devices (such as cloud services hosting application profiles and optimized assets). Data assets downloadable from the cloud can include, but are not limited to, pre-compiled shaders, shader compiler feature configurations, modified texture assets, GPU driver extensions, and / or capability feature configurations. Shaders and / or data assets optimized on the device by the disclosed system and process can be uploaded to external storage devices (e.g., cloud services) for verification, access by other similar devices, and / or to provide customer preferences for subjective improvements. Shaders for the device can be optimized by the cloud service and made available to the device by being transferred to the disclosed process.

[0024] In another embodiment, the systems and processes disclosed herein may include opt-in features that send performance metrics to the cloud for further optimization, such as updating game profiles for future optimizations. Example performance metrics may include, but are not limited to: performance and initialization time for different applications and benchmarks, performance based on system settings (e.g., graphics quality level), GPU utilization, frame rate measurements, and bandwidth usage (e.g., the amount of data read and written by the GPU beyond the GPU itself and / or beyond the lowest-level cache (LLC)). An automated and selective (cloud-based) testing infrastructure can accumulate device-optimized shaders and / or data assets based on real, field-use cases that provide “collective intelligence” optimization. Another aspect of the subject matter disclosed herein may include performing “unlimited-time” optimizations in the cloud that can be used to replace runtime compilation on the device. If a particular optimization is found not to improve the application, performance data received from multiple devices can be used to determine that a particular optimization for the application should be turned off to save compilation / runtime. Furthermore, feedback from the devices can be used for beta-type test optimizations in the field.

[0025] In one embodiment, the database outside the portable device may contain configuration files for one or more configurations for popular applications and games, targeting specific GPUs and GPU drivers. Each configuration file may be statically optimized by the application and game provider on a per-application / game basis for specific GPUs and GPU drivers to provide an enhanced set of user configuration settings that can be responsively delivered to daemon processes and / or allow users to find optimal solutions and selectively apply them.

[0026] Furthermore, different types of statistics can be collected through selectively added feedback (such as which shaders are most worth optimizing and which optimizations can improve future products) that can be used to improve the Quality of Service (QoS) of current and future products. Additionally, obtaining information related to how frequently a particular pixel shader runs is also worthwhile, which may lead to the addition / modification / rejection of individual ISA-level instructions. If the current, real-time game play is understood, it may be possible to select specific shader variants that are more optimized for specific conditions and / or given scenarios. For example, knowing the number of texture accesses based on settings configured for energy efficiency, contrasting with high-resolution configurations or configurations used for complex graphics effects, can be useful. For example, if the graphics resolution configuration is set to low, a simpler Big O complexity variant of the algorithm can be more energy-efficient than a fast but energy-intensive version.

[0027] GPU drivers can be supplemented by a local database on the device, managed by a daemon process or similar application running in the background and serving the GPU driver. The daemon process can use runtime profiles to compile shaders / data assets on demand, and subsequently replace or store various shader variants in the local database under separate profiles that include more comprehensive optimizations. During periods when the device may not be actively running demanding applications (and / or may be plugged in), the daemon process can asynchronously compile all stored shaders with “unbounded” compile times to optimize shaders based on profile attributes and formats, as well as the device’s native hardware constraints. Profile attributes may include, but are not limited to, memory footprint, performance efficiency, and / or precision reductions for improved frame rates. Users can select profiles for applications, which are then accessed and used by the GPU driver at application runtime. Furthermore, the daemon process can improve texture and geometry models by converting textures to native formats or applying native compression schemes, removing unused levels of detail that reduce bandwidth requirements, and notifying the application of corresponding descriptors of changes; new assets can then be used by the device’s GPU hardware and GPU driver.

[0028] One example embodiment provides a method for optimizing shader compilation on a portable device including a graphics processing unit (GPU), wherein the method may include: scanning one or more applications on the target device to determine application-specific data related to shaders, textures, and / or geometry models. The application-specific data may be transferred from a GPU driver to a daemon process located on the target device and separate from the GPU driver. The daemon process may use the application-specific data to generate improved and / or optimized shaders, textures, and / or geometry models. The improved and / or optimized shaders, textures, and / or geometry models may be received by the GPU driver and used when the application corresponding to the improved and / or optimized shaders, textures, and / or geometry models runs on the device. Feedback information may be transferred to the daemon process for further asynchronous improvement and / or optimization of the shaders, textures, and / or geometry models.

[0029] Application-specific data and / or feedback information can be transmitted to processes outside the device, such as cloud services and / or resources located on a local area network (LAN) connected to the device. Cloud services and / or resources on the LAN can provide alternative compiled versions of shaders, textures, and / or geometry models that can be delivered to the device. When the corresponding application runs on the device, the user of the device can select the specific compiled version to be used by the GPU driver. Optimizations available from cloud services and / or resources on the LAN can be beta-tested in the field by a set of devices to further refine and / or optimize the shaders, textures, and / or geometry models.

[0030] Figure 1 A system 100 for graphics driver optimization is described according to the subject matter disclosed herein. System 100 includes a device 101, wherein device 101 may be communicatively coupled to a cloud service 102 that may provide optional supplementary services 103. Device 101 may be a portable computing device, such as, but not limited to, a smartphone, laptop computer, or tablet computer. It should also be understood that device 101 may not necessarily be a portable device, as in one embodiment, device 101 may be a desktop computer or a relatively non-mobile computing device. Alternatively or additionally, although in Figure 1 The cloud service 102 is described as providing supplementary service 103, but in an alternative embodiment, supplementary service 103 may reside on a resource communicatively coupled to the LAN of device 101.

[0031] Device 101 may include one or more CPUs 104, memory 105, one or more GPUs 106, and a network interface device 107 coupled together as shown. CPU 104 may run an application 108 stored in memory 105. Application 108 may include shaders, textures, and / or geometry models compiled at runtime. Each GPU 106 may have a corresponding GPU driver 109 stored in memory 105. A compiler service (daemon) 110 stored in memory 105 may run in the background of device 101 and interface with the graphics driver 109 and local database 111 in memory 105. Compiler service 110 may be a daemon process or a daemon-like application. Daemon process 110 may run as a background process on device 101 and is not directly controlled by the interactive user. In one embodiment, compiler service 110 may be implemented as a module. When application 108 starts and GPU driver 109 begins compiling shaders, textures, and / or geometry models for application 108, GPU driver 109 communicates with daemon process 110 to obtain shaders, textures, and / or geometry models that can be improved and / or optimized compared to shaders, textures, and / or geometry models that GPU driver 109 can compile at runtime.

[0032] Device 101 may also include Figure 1 Components and / or modules, and functions, not indicated for clarity. For example, device 101 may include components and / or modules such as, but not limited to, a display, memory, memory controller, persistent storage device, user interface, and (wired and / or wireless) network interface. The various components and / or modules of device 101 may be implemented as any combination of software, firmware, and / or hardware configured to provide the functions described herein in conjunction with the components and / or modules, and to provide functions that can be associated with device 101.

[0033] (Optional) Cloud service 102 may include one or more servers (not shown), wherein the one or more servers may run supplementary service 103, which daemon process 110 may access via network interface 107 of device 101 and a corresponding communication network (not shown) to cloud service 102. Alternatively or additionally, supplementary service may reside on resources of a LAN accessible by daemon process 108. Supplementary service 103 may accumulate improved and optimized shaders, textures, and / or geometry models generated by daemon processes running on other devices (not shown). Daemon process 110 may access the improved and / or optimized shaders, textures, and / or geometry models accumulated in supplementary service 103.

[0034] Figure 2 A flowchart depicts an example embodiment of a method 200 for optimizing a graphics driver using cloud-based resources, based on the subject matter disclosed herein. Method 200 relates to application 108 and a device (such as...) Figure 1 A daemon process 110 runs as a background operation on device 101. Application 108 can be any application that provides graphical display output for display on the monitor of device 101. Alternatively, application 108 can be a computational application that generates calculation results but does not produce graphical output.

[0035] refer to Figure 1 and Figure 2In both cases, in 201, application 108 is launched by the user of the device. In 202, application 108 causes the GPU driver 109 to compile the shader pipeline. In 203, application 108 initiates all other operations associated with the application. In 204, textures are loaded and can be placed within the graphics pipeline. At this point, application 108 is running. After a period of time, in 205, application 108 terminates. Operations 201 to 205 are the operations that typically occur on device 101 while the application is running. When only operations 201 to 205 are running (and daemon process 110 is unavailable), the shaders compiled at runtime in 202 and the textures loaded in 204 may not be optimized because the GPU driver 109 may not have all the parameters relevant to the native GPU hardware of device 101 before runtime.

[0036] According to the subject matter disclosed herein, daemon process 110 can run as a background process on device 101. Daemon process 110 can provide graphics driver optimizations for device 101. While the shader pipeline is being compiled in 202 (and if daemon process 110 is available on device 101), GPU driver 109 queries daemon process 110 for any improved and / or optimized shaders available. In 211, daemon process 110 determines whether any improvements and / or optimizations for the shader pipeline are stored in database 111. If so, daemon process 110 proceeds to 212, where the improvements and / or optimizations for the shader pipeline stored in database 111 are returned to GPU driver 109 and application 108 in 202. If no improvements and / or optimizations for the shader pipeline are stored in database 111 in 211, daemon process 110 compiles the shader pipeline in 213. In one embodiment, the initial compilation of the shader pipeline by the daemon process 110 can be a default-level compilation. In another embodiment, the initial compilation of the shader pipeline by the daemon process 110 can be more refined than the initial compilation performed by the GPU driver 109. In 213, the shader pipeline generated by the daemon process 110 can be stored in the database 111 for future use, and the process continues to 212, where the initial shader pipeline is returned to the GPU driver 109 and application 108 in 202.

[0037] When GPU driver 109 loads a texture in 204, the GPU driver queries daemon process 110 for any available improvements and / or optimizations to the data asset (texture and / or geometry model). In 214, daemon process 110 determines whether any improvements and / or optimizations related to the data asset are stored in database 111. If so, daemon process 110 proceeds to 215, where the improvements and / or optimizations related to the data asset stored in database 111 are returned to GPU driver 109 and application 108 in 204. In addition to returning the optimized texture, a descriptor may also be returned, which provides new details about the texture asset in some way, thereby informing the graphics driver whether the texture must be loaded differently due to a change in asset format (e.g., size, format style, compression type, level of detail information). For example, the optimized texture may have a smaller size or memory footprint, and metadata may be used to convey that different compression techniques can be used to read the texture, as well as the new size and / or dimensions of the optimized texture. Similarly, an optimized geometry model can have fewer vertices, and metadata can be used to transmit new vertex counts for the optimized geometry model. If no improvements and / or optimizations related to the data asset are stored in database 111 in 214, the process continues to 216, where daemon process 110 initially optimizes the data asset and stores the initially optimized data asset in database 111 for future use. The process continues to 215, where the initially optimized data asset is returned to GPU driver 109 and application 108 in 204.

[0038] When device 101 is not running application 108 (or another application) and / or when the device is charging (and is typically likely idle), shaders and data assets can be compiled "offline" by daemon process 110 using "unlimited" compilation time to generate improvements and optimizations that can be stored locally for later use. In 221, daemon process 110 determines whether device 101 is idle and charging. In one embodiment, when both conditions are met, daemon process 110 determines in 222 whether any unoptimized shaders and / or data assets exist for the application residing on the device. If so, the process continues to 223, where daemon process 110 (optionally) compiles and / or transforms shaders and / or data assets to be improved and / or optimized for the application residing on device 101. The improved and / or optimized shaders and / or data assets are stored in database 111. The process returns to 221.

[0039] In one embodiment, the daemon process 110 may communicate with supplemental services 103 external to device 101, such as cloud service 102 and / or resources located on a local area network (LAN) connected to device 101. The cloud service and / or resources on the LAN may provide alternative compiled / optimized versions of shaders, textures, and / or geometry models that can be delivered to device 101. Alternatively, the external database may contain profiles for one or more configurations for popular applications and games targeting specific GPUs and GPU drivers. Each configuration profile may be statically optimized by application and game providers on a per-application / game basis for specific GPUs and GPU drivers to provide a set of enhanced user configuration settings that can be responsively delivered to the daemon process and / or allow users to find optimal solutions and selectively apply them. When the corresponding application is running on the device, the user of the device can select a specific compiled version to be used by the GPU driver. Optimizations available from the cloud service and / or resources on the LAN may be beta-tested in the field by a set of devices to further determine improved and / or optimized shaders, textures, and / or geometry models.

[0040] Figure 3 This document describes an electronic device 300 that provides graphics driver optimization according to the subject matter disclosed herein. The electronic device 300 may include a controller (or CPU) 310, input / output devices 320 (such as, but not limited to, a keypad, keyboard, display, touchscreen display, camera and / or image sensor), memory 330, interface 340, GPU 350, image processing unit 360, and neural processing unit 370, all coupled to each other via a bus 380. The controller 310 may include, for example, at least one microprocessor, at least one digital signal processor, at least one microcontroller, etc. The memory 330 may be configured to store command code or user data to be used by the controller 310. The electronic device 300 may operate to run daemon processes (e.g.,...). Figure 1 The daemon process 110 in the document is used to improve and / or optimize shaders and / or data assets used by applications running on electronic devices according to the subject matter disclosed herein. The daemon process may use neural processing unit 370 to improve and / or optimize shaders, textures and / or geometry models as disclosed herein.

[0041] Electronic device 300 and its various system components may include image processing unit 360. Interface 340 may be configured to include a wireless interface, wherein the wireless interface is configured to use RF signals to transmit data to or receive data from a wireless communication network. Wireless interface 340 may include, for example, an antenna. Electronic System 300 can also be used under the communication interface protocol of the communication system, such as, but not limited to, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), North American Digital Communications (NADC), Extended Time Division Multiple Access (E-TDMA), Wideband CDMA (WCDMA), CDMA2000, Wi-Fi, Municipal Wi-Fi (Muni Wi-Fi), Bluetooth, Digital Enhanced Cordless Communication (DECT), Wireless Universal Serial Bus (Wireless USB), Fast Low Latency Access with Seamless Handover (Flash-OFDM), IEEE 802.20, General Packet Radio Service (GPRS), iBurst, Wireless Broadband (WiBro), WiMAX, WiMAX-Advanced, Universal Mobile Telecommunications Service - Time Division Duplex (UMTS-TDD), High-Speed ​​Packet Access (HSPA), Evolved Data Optimized (EVDO), Advanced Long Term Evolution (LTE-Advanced), Multichannel Multipoint Allocation Service (MMDS), 5G, and 6G.

[0042] Embodiments of the subject matter and operation described in this specification may be implemented in digital electronic circuits, in computer software, firmware, or hardware (including the structures disclosed in this specification and their equivalents), or in a combination of one or more of these. Embodiments of the subject matter described in this specification may be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a computer storage medium for execution by or control of the operation of a data processing apparatus. Alternatively or additionally, the program instructions may be encoded on artificially generated propagating signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information for transmission to a suitable receiver device for execution by the data processing apparatus. The computer storage medium may be one of, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, and combinations thereof. Furthermore, while the computer storage medium is not a propagating signal, it may be a source or destination of computer program instructions encoded in artificially generated propagating signals. Computer storage media may also be one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices), or may be included in one or more separate physical components or media. Furthermore, the operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0043] While this specification may contain numerous specific implementation details, these details should not be construed as limiting the scope of any claimed subject matter, but rather as descriptions of features specific to particular embodiments. Specific features described in the context of individual embodiments in this specification may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually in multiple embodiments, or in any suitable sub-combination. Furthermore, although features may be described above as functioning in a particular combination, or even initially claimed in this way, in some cases, one or more features may be removed from the claimed combination, and the claimed combination may refer to a sub-combination or a variation of a sub-combination.

[0044] Similarly, although operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order or sequential order shown, or requiring all of the shown operations to be performed, in order to obtain the desired result. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of the various system components in the embodiments described above should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0045] Therefore, specific embodiments of the subject matter are described herein. Other embodiments fall within the scope of the appended claims. In some cases, the actions set forth in the claims may be performed in a different order and still yield the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific order or sequential sequence shown to obtain the desired result. In certain embodiments, multitasking and parallel processing may be advantageous.

[0046] As those skilled in the art will recognize, the innovative concepts described herein can be modified and varied across a wide range of applications. Therefore, the scope of the claimed subject matter should not be limited to any specific exemplary teachings discussed above, but is defined by the appended claims.

Claims

1. A computing device, comprising: Storage device, located inside the computing device; A graphics processing unit (GPU), the GPU including a driver; and A controller, coupled to the storage device, is configured to run a daemon process, wherein the daemon process performs the following operations: When no application residing on the computing device is running, one or more of the shaders and shader pipelines are optimized for the application, and at least one optimization for one or more of the shaders and shader pipelines is stored in the storage device, the at least one optimization being based on the application. In response to a request from the GPU driver for optimizations targeting the shader during runtime compilation, at least one optimization for one or more of the shader and the shader pipeline is provided from the storage device to the GPU driver. At least one optimization for one or more of the shaders and the shader pipeline is sent to a database outside the computing device, and The GPU driver provides at least one optimization for one or more of the shaders and shader pipelines from one of the storage devices inside the computing device and one of the databases outside the computing device.

2. The computing device according to claim 1, wherein, The daemon process is configured to optimize one of the shaders and the shader pipeline when the computing device is not running the application and the computing device is charging.

3. The computing device according to claim 1, wherein, At least one optimization for one or more of the shaders and shader pipelines includes converting one or more of the shaders and shader pipelines to the native format of the GPU of the computing device.

4. The computing device according to claim 1, wherein, The daemon process is configured to optimize a texture used by the application when the computing device is not running the application, store at least one optimization for the texture in the storage device, and provide at least one optimization for the texture to the GPU driver from the storage device in response to a request from the GPU driver for optimization of the texture during runtime compilation of the shader.

5. The computing device according to claim 4, wherein, The daemon process is configured to return a descriptor to the GPU driver indicating at least one characteristic that differs from the non-optimized version of the texture in the at least one optimized version.

6. The computing device according to claim 1, wherein, The daemon process is configured to optimize the geometry model used by the application when the computing device is not running the application, store at least one optimization for the geometry model in the storage device, and provide at least one optimization for the geometry model to the GPU driver from the storage device in response to a request from the GPU driver for optimization of the geometry model during runtime compilation of the shader.

7. The computing device according to claim 1, wherein, The computing device includes one of a smartphone, tablet, or laptop computer.

8. A computing device, comprising: Storage device, located inside the computing device; A graphics processing unit (GPU), the GPU including a driver; and A controller, coupled to the storage device, is configured to run a daemon process, wherein the daemon process performs the following operations: When no application is running on the computing device, one of the shaders and textures is optimized for the application, and at least one optimization for the shader and at least one optimization for the texture are stored in the storage device; In response to a request from the GPU driver for optimizations for one of the shaders and the textures during runtime compilation of the shader, at least one optimization for the shader and at least one optimization for the texture are provided from the storage device to the GPU driver. Send one of at least one optimization for the shader and at least one optimization for the texture to a database outside the computing device; and One of at least one optimization for the shader and at least one optimization for the texture is provided to the GPU driver from one of the storage devices inside the computing device and the database outside the computing device.

9. The computing device according to claim 8, wherein, The daemon process is configured to optimize one of the shaders and the textures when the computing device is not running the application and the computing device is charging.

10. The computing device according to claim 8, wherein, The daemon process is configured to optimize a geometric model, including three-dimensional vertices, used by the application when the computing device is not running the application, store at least one optimization for the geometric model in the storage device, and provide at least one optimization for the geometric model to the GPU driver from the storage device in response to a request from the GPU driver for optimization of the geometric model during runtime compilation of the shader.

11. The computing device according to claim 8, wherein, The computing device includes one of a smartphone, tablet, or laptop computer.

12. A method for optimizing shader compilation on a computing device, the method comprising: When no application residing on the computing device is running, a daemon process optimizes one of the shaders and textures for the application. The daemon process stores at least one optimization for the shader and at least one optimization for the texture in the storage device inside the computing device; The daemon process receives a request from the driver of the graphics processing unit (GPU) of the computing device for optimization of one of the shaders and the textures during runtime compilation of the shaders; as well as The daemon process provides the GPU driver with one of at least one optimization for the shader and at least one optimization for the texture from the storage device.

13. The method according to claim 12, wherein, Optimizing one of the shaders and the texture when the computing device is not running the application further includes optimizing one of the shaders and the texture when the computing device is not running the application and the computing device is charging.

14. The method of claim 12, further comprising: When the application is not running on the computing device, the daemon process optimizes the geometric model used by the application. The daemon process stores at least one optimization for the geometric model in the storage device; The daemon process receives a request from the GPU driver for optimization of the geometry model during the runtime compilation of the shader; as well as The daemon process provides at least one optimization for the geometry model to the GPU driver from the storage device.

15. The method of claim 12, further comprising: The daemon process sends one of at least one optimization for the shader and at least one optimization for the texture to a database outside the computing device; as well as The daemon process provides one of at least one optimization for the shader and at least one optimization for the texture to the GPU driver from one of the storage devices inside the computing device and the database outside the computing device.

16. The method according to claim 12, wherein, The computing device includes one of a smartphone, tablet, or laptop computer.

Images