Patent Application
20130212600
On early contemporary computing devices that had relatively low computational power (e.g., compared to a PC), such as a mobile device or game console, if an application was running and was subsequently replaced in the foreground by another application (or title), the first application was deactivated and the application's process terminated by the operating system.
As this was rather inconvenient at times to the user, one improvement was to save state of the application before deactivation, and then restore that state if and when that application was reactivated. However, when returning to an application that was terminated by the operating system, the user needed to wait for the device application framework to initialize, and for the application itself to load saved state to resume the previous experience. Resuming in this way was relatively slow and thus provided a somewhat undesirable user experience.
In more recent devices, another improvement is the concept of a dormant state, in which the shell component/framework that comprises the (e.g., Windows® phone) application platform retains the application process in memory, and maintains state and execution context for the application. This eliminates the need to reinitialize the application and reload state, and thus allows for much faster reactivation. However, a dormant application is limited in that it may not execute code when in the background, and instead regains the ability to execute code when the user brings the application out of the dormant state. As such computing devices grow in power, users expect more and more features with respect to application execution.
This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.
Briefly, various aspects of the subject matter described herein are directed towards a technology by which an application is moved from a full running (e.g., primary user experience) state into a constrained running mode (or state) in which the application process is able to execute code with reduced resources.
In one aspect, a shell component is configured to run applications in different modes, including to run an application in a constrained running mode, in which the constrained running mode has reduced resources available to the application relative to resources available to applications in a full running mode, the application in the constrained running mode configured to run in parallel with another application that is run in a full running mode.
In one aspect, there is described moving a running application from a full running state into a constrained running state, including notifying the application of a state transition. Also described is reducing one or more resources available to the constrained application including reducing a number of CPU (central processing unit) cores reserved to the application, an amount of memory accessible to the application, GPU (graphics processing unit) access of the application, and/or screen area accessible to the application.
Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings.
The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards a technology in which an application that is not the primary user experience is able to continue running in a constrained mode (state), in which the application can do some work in parallel but is only allocated limited resources. Note that as used herein, “mode” and “state” are generally synonymous with respect to management of applications. While running an application in the constrained mode, another application (or another application instance) may run in a full state.
It should be understood that any of the examples herein are non-limiting. For one, example implementations and constrained applications are described in the context of a game console operating environment, however this is only for purposes of explanation, and other operating environments such as mobile device environments may benefit from the concept of a constrained application state as described herein. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing and application/process management in general.
As described herein, the shell 102 also provides a reduced amount of “constrained mode” resources 108 for access by a constrained application 110.
As will be understood, this allows the constrained application 110 to run in parallel with the full mode application 106 so as to perform some work. Note that it is feasible to have more than one constrained mode application, each performing some parallel work using reduced resources. For purposes of simplicity, the description hereinafter generally will be directed towards one constrained mode application.
As also exemplified in
As can be seen in
In one implementation in which each application has an associated object, the full and constrained states are facilitated by one or more properties/data in the object, and an event that is fired when a running application transitions between the full and constrained states. To disambiguate which state an application is in when it is activated or resuming, the application examines its associated application object.
To operate properly, an application that transitions from the full state 224 to the constrained state 226 needs to reduce its resource usage when possible (e.g., pause the game, switch to a minimal “glanceable” data view, and so forth). The platform guarantees correctness of execution when resources are reduced. Note however that some dedicated hardware APIs may return failure cases or simply no-op, for which a properly designed application needs to account. Further, the number of dedicated CPUs (cores) are reduced in the constrained mode, whereby the application also needs to ensure that its threading model and processor affinity stand up to thread migration. In one implementation, in the constrained mode, two physical cores are reclaimed, however the number of available threads (e.g., six) need not be reduced. In other implementations such as mobile devices that do not have multicore processors (or a sufficient number of cores to reserve them in an appropriate way), CPU access can be limited. GPU cycles may be limited, and network and hard disk I/O requests may be lowered in priority. Still further, the application should attempt to reduce its resource utilization, often by taking into consideration the fact that being in constrained mode indicates that the user's attention has moved to elsewhere.
Suspending refers to another process lifetime management event that indicates to an application that the application will soon be transitioned to the suspended state 228. The application needs to persist state in preparation for the possibility of thereafter being moved to the terminated state 230. A notification and some reasonable time is given for the application to persist state, because once an application is suspended, the application is frozen, and the application may later be terminated to recover resources, without any opportunity for the application to execute further instructions.
Resuming is an event which indicates to an application that it is returning from the suspended state, which as shown in
It should be noted that in one implementation, an application model has different types of high-level applications, namely exclusive resource applications (ERAs) and shared resource applications (SRAs). In such an implementation, an application's resource model (exclusive resource application or shared resource application) is a static attribute of the application declared by each application as part of its application metadata. Exclusive resource applications have access to a larger amount of system resources (CPU, GPU, memory and so forth) as well as stronger guarantees on the availability of those resources. An effect of exclusive resource application resource guarantees is that in one implementation, only one exclusive resource application can be running as a full mode application at any given time. Shared resource applications have less access to resources, but are capable of running concurrently with other applications. Notwithstanding, full mode and constrained mode concepts apply both to exclusive resource applications and shared resource applications. However, the resources allocated to a full mode exclusive resource application need not be (and typically are not) the same as the resources allocated to a constrained mode exclusive resource application, nor are the resources allocated to a full mode shared resource application typically the same as the resources allocated to a constrained mode shared resource application.
Exclusive resource applications are designed with the ability to run in different active resource states, in which each state has access to different amounts of hardware resources. State transitions are imposed on the application by the system in response to user control. In one example implementation, in the full state, also referred to as the “full screen” state, the application occupies the majority of the screen real estate and has access to the bulk of the hardware resources. This is the state in which the application provides its full experience.
In the constrained state, an exclusive resource application occupies a smaller area of the screen and has access to less CPU and GPU resources relative to the full state. The application is expected to suspend its primary experience and switch to more of an animated pause screen, for example. Transitions between this mode and full-screen are intended to be relatively fast. Note that the constrained mode does not equate to picture-in-picture (PIP), as constrained is an actual mode of an exclusive resource application whereas a PIP is a form of limited shared resource application.
Shared resource applications may be run in the full-screen state in which the application occupies the majority of the screen real estate and has more access to hardware resources, or in the constrained state, in which the application occupies a reduced area of the screen than full-screen. Shared resource applications are notified regarding the state changes in the same way as exclusive resource applications, e.g., via notification mechanisms.
Note that other states, such as “non-visible,” also may exist, e.g., for exclusive resource applications. For example, in a non-visible state, an application may be completely non-visible with respect to screen access, with access to significantly reduced hardware resources. An example purpose of such a state is to allow multiplayer games to maintain their simulation in order to allow seamless transitions back to the constrained or full-screen states. Shared resource applications may not have an exclusive non-visible mode, however certain shared resource applications such as video chat may be allowed to run in a non-visible/background mode for audio and communication functions.
The following table sets forth an example of how resources may be allocated among states and application types in one example embodiment; note that the following symbols are used for certain meanings, namely: (*) Stream may be subdivided; (**) CPUs is only at ˜70% of clock speed; (***) 10% GPU is reserved to allow for certain scenarios; (+) DVD player app is granted access to optical disk drive (ODD); (++) it may be possible to plumb Windows® frameworks for only one plane; and (+++) for certain “wireless display” scenarios, hardware reserve all of the video encoder resources
In some embodiments, with respect to GPU usage, when an exclusive resource application is constrained, a constrained shared resource application that is running concurrently has access to approximately forty-five percent of the GPU. This allows for full-size 1080p rendering with significant complexity. DrawPrim-granularity GPU preemption may be used and based off a timer, whereby the reservation is not tied to the game's frame-rate. The constrained shared resource application is guaranteed constant, consistent performance. Constrained shared resource applications are able to have background rendering that can extend over multiple frames while still updating the screen at sixty Hz.
Step 306 moves the application to the constrained state, where its resources are limited in some way. Note that for robustness, the system ensures to the extent possible that an application does not actually have to change its behavior when the application receives a state-change notification (although the application developer is encouraged to write the application to change its behavior). However, the system does to an extent enforce the constrained mode (step 308) with respect to resource access, e.g., by reducing cores and GPU access, by denying requests for more memory than allowed, by masking the screen so that the constrained mode application cannot draw outside of a certain area, and so forth.
As previously shown in
If instead step 310 determines that the application is to be suspended, step 312 notifies the application, providing the application with time to preserve its state as mentioned above. Step 314 represents moving the application to the suspended state, where it may be terminated, or resumed to its previous running state, which in this example was constrained. Note however that it is feasible to have a constrained mode application suspended, and resumed to the full state.
Returning to step 316, if a constrained application is to be moved back to the full state, step 318 provides the notification, along with an appropriate amount of time for the application to prepare for the transition. Step 320 represents moving the application to the full state, restoring the full amount of resources.
As can be seen, applications running in the full mode are typically the active target of user interaction and draw to (substantially) the full screen. Full mode applications have access to a dedicated amount of resources (typically the largest amount of memory and CPU time). Resource allocation is guaranteed in the case of an exclusive resource application. Applications running in the constrained mode may only draw to a reduced screen area. Constrained mode applications have less resource allocation than what they have the full state.
It can be readily appreciated that the above-described implementation and its alternatives may be implemented on any suitable computing device, including a gaming system, personal computer, tablet, DVR, set-top box, smartphone and/or the like. Combinations of such devices are also feasible when multiple such devices are linked together. For purposes of description, a gaming (including media) system is described as one exemplary operating environment hereinafter.
The CPU 402, the memory controller 403, and various memory devices are interconnected via one or more buses (not shown). The details of the bus that is used in this implementation are not particularly relevant to understanding the subject matter of interest being discussed herein. However, it will be understood that such a bus may include one or more of serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus, using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus also known as a Mezzanine bus.
In one implementation, the CPU 402, the memory controller 403, the ROM 404, and the RAM 406 are integrated onto a common module 414. In this implementation, the ROM 404 is configured as a flash ROM that is connected to the memory controller 403 via a Peripheral Component Interconnect (PCI) bus or the like and a ROM bus or the like (neither of which are shown). The RAM 406 may be configured as multiple Double Data Rate Synchronous Dynamic RAM (DDR SDRAM) modules that are independently controlled by the memory controller 403 via separate buses (not shown). The hard disk drive 408 and the portable media drive 409 are shown connected to the memory controller 403 via the PCI bus and an AT Attachment (ATA) bus 416. However, in other implementations, dedicated data bus structures of different types can also be applied in the alternative.
A three-dimensional graphics processing unit 420 and a video encoder 422 form a video processing pipeline for high speed and high resolution (e.g., High Definition) graphics processing. Data are carried from the graphics processing unit 420 to the video encoder 422 via a digital video bus (not shown). An audio processing unit 424 and an audio codec (coder/decoder) 426 form a corresponding audio processing pipeline for multi-channel audio processing of various digital audio formats. Audio data are carried between the audio processing unit 424 and the audio codec 426 via a communication link (not shown). The video and audio processing pipelines output data to an A/V (audio/video) port 428 for transmission to a television or other display/speakers. In the illustrated implementation, the video and audio processing components 420, 422, 424, 426 and 428 are mounted on the module 414.
In the example implementation depicted in
Memory units (MUs) 450(1) and 450(2) are illustrated as being connectable to MU ports “A” 452(1) and “B” 452(2), respectively. Each MU 450 offers additional storage on which games, game parameters, and other data may be stored. In some implementations, the other data can include one or more of a digital game component, an executable gaming application, an instruction set for expanding a gaming application, and a media file. When inserted into the console 401, each MU 450 can be accessed by the memory controller 403.
A system power supply module 454 provides power to the components of the gaming system 400. A fan 456 cools the circuitry within the console 401.
An application 460 comprising machine instructions is typically stored on the hard disk drive 408. When the console 401 is powered on, various portions of the application 460 are loaded into the RAM 406, and/or the caches 410 and 412, for execution on the CPU 402. In general, the application 460 can include one or more program modules for performing various display functions, such as controlling dialog screens for presentation on a display (e.g., high definition monitor), controlling transactions based on user inputs and controlling data transmission and reception between the console 401 and externally connected devices.
The gaming system 400 may be operated as a standalone system by connecting the system to high definition monitor, a television, a video projector, or other display device. In this standalone mode, the gaming system 400 enables one or more players to play games, or enjoy digital media, e.g., by watching movies, or listening to music. However, with the integration of broadband connectivity made available through the network interface 432, gaming system 400 may further be operated as a participating component in a larger network gaming community or system.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
The present application claims priority to U.S. provisional patent application serial no. 61/599373, filed Feb. 15, 2012
| Number | Date | Country | |
|---|---|---|---|
| 61599373 | Feb 2012 | US |
