具有qos保证的可缩放多媒体计算机系统体系结构的制作方法

专利名称：具有qos保证的可缩放多媒体计算机系统体系结构的制作方法
技术领域：
本发明涉及多媒体计算机系统体系结构。
背景技术：
通常向在多媒体计算机系统上执行的多媒体软件应用提供有关计算机系统的诸如硬件、固件或软件组件之类的计算资源的分配的某种服务质量(QoS)保证。这对游戏尤其成立。例如，可存在可用于每一个游戏的所分配的存储器分配大小。多媒体计算机系统也可确保诸如游戏之类的应用的先前版本仍将运行，所以Qos保证可存在很多年。多媒体计算机系统，尤其是游戏控制台，现在一般提供作为其平台的服务的一部分的常见功能。平台的示例是XBOX 、索尼的Playstation3 或任天堂的Wii 。常见功能是许多类型的游戏或其他应用使用的服务，或与这些应用相兼容的服务。常见的平台功能的一些示例是显示平面混合、显示输出记录、视频编解码器编码、用户设备音乐解码和混音、基于自动相机的玩家标识等。另外，平台服务可包括独立于多媒体应用但与多媒体应同时运行的功能。由于许多游戏和其他多媒体应用现在可通过因特网来进行交互，因此平台服务可处理因特网协议消息，可提供在线聊天、朋友邀请、电子邮件，并可支持社交联网服务。平台和应用两者可使用共有的资源来执行它们相应的功能。由于支持交互性游戏和其他多媒体内容的网络连接性的形式一直在进步，并且应用的某些处理方面变成标准，因此随着时间的推移，平台为各种应用提供了越来越多的服务，而仍服从针对这些多媒体应用的相同的Qos保证，由此增加了对共享资源的争用。

发明内容
本技术为多媒体应用提供了满足服务质量(QoS)标准的多媒体计算机系统体系结构，同时允许平台服务随时间而缩放的各种实施例。随时间而缩放可允许新的服务或增强的当前服务。平台服务也可随着时间而缩小。在用于根据一个或多个服务质量(QoS)保证来为正执行的多媒体应用提供一致的性能的多媒体计算机系统的一实施例中，该系统包括计算资源的平台分区、计算资源的应用分区和至少一个共享资源。平台分区包括含平台中央处理单元(CPU)和平台图形处理单元(GPU)的计算资源。应用分区包括含应用CPU和应用GPU的计算资源。在一些实施例中，应用处理单元执行除平台服务应用的指令以外的处理。在一些实施例中，系统还包括可被平台分区资源和应用分区资源访问的共享资源。在多媒体计算机系统的一些实施例中，为了增强对资源的放大或缩小，平台分区包括对一个或多个平台服务应用和多媒体应用执行处理的一个或多个资源，但是仅可多媒体应用可通过软件接口来访问该平台分区。此外，一个或多个共享计算资源可包括可执行平台服务应用或多媒体软件应用的指令的附加的CPU，以基于针对多媒体应用的一个或多个QoS保证来提供多媒体应用的一致性能。在一些实施例中，附加的CPU可执行通用操作系统。还提供了具有软件编码在其上的一个或多个计算机可读存储的实施例，该软件在被处理器执行时，使得处理器执行一种用于在与一个或多个平台服务应用同时执行的多媒体应用之间分配计算资源以基于一个或多个QoS保证来提供多媒体应用的一致性能的方法。提供本发明内容以便以简化的形式介绍将在以下具体实施方式
中进一步描述的一些概念。本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。


图I示出了具有用户参与到游戏中的目标识别、分析和跟踪系统的示例实施例。图2示出了与捕捉设备通信地耦合的控制台计算系统的示例性实施例。图3A是向QoS多媒体保证提供可缩放平台服务的多媒体计算机系统体系结构的一实施例的框图。图3B是多媒体计算机系统体系结构的另一个实施例的框图，该多媒体计算机系统体系结构如同图3A中的多媒体计算机系统体系结构具有附加的共享CPU和GPU。图3C是用于在多媒体模式和通用计算模式之间改变至少一个处理单元的操作模式的方法的一实施例的流程图。图4示出了诸如可以在控制台中实现的多媒体计算系统的另一个示例实施例。图5A是向Qos多媒体保证提供可缩放平台服务的多媒体计算机系统体系结构的一实施例的框图。图5B是图5A的提供QoS多媒体保证的多媒体计算机系统体系结构的实施例的另一个版本的框图。图6是描述了用于基于对多媒体应用的一个或多个服务质量(QoS)保证在多媒体应用和平台服务应用之间分配计算资源的方法的一个实施例的流程图。图7是描述了实现优先级的过程作为针对等待时间保证的QoS保证处理技术的一个实施例的流程图。图8是示出用于基于用于提供一致的实时性能的准则来处理存储器请求的QoS保证方法的示例的流程图。
具体实施例方式多媒体内容可以包括从诸如内容提供方、宽带、卫星和有线电视公司、广告代理、 因特网或来自web服务器的视频流之类的媒体内容源接收的任何类型的音频、视频和/或图像媒体内容。如此处所描述的那样，多媒体内容可包括录制的视频内容、视频点播内容、 电视内容、电视节目、公告、广告片、音乐、电影、视频剪辑，及其他点播媒体内容。其他多媒体内容可包括交互式游戏、基于网络的应用，以及任何其他内容或数据(例如，包括节目指南应用数据、用户界面数据、广告内容、隐藏字幕、内容元数据、搜索结果和/或推荐等等)。诸如在多媒体计算机系统上执行的交互式游戏之类的多媒体应用通过高度复杂的现场显示器的实时更新来向用户体验提供响应于用户输入的3D图形。例如，游戏应用需要实时地更新化身、其他动画角色和移动对象的快速走动的动作。另外，还需要更新复杂的背景和视觉效果。在较早批次的多媒体控制台(即，通过多媒体多维数据集和PS2的Atari 2600)中，多媒体应用在具有较少或没有任何远程连接性的游戏控制台上执行。通常，应用本身具有用于执行创建用户体验所需的所有任务的代码。计算资源的平台提供了标准化构架来供多媒体应用开发者进行开发。计算资源可以是硬件、固件、软件、或这些中的两个或多个的组合。由于为想要与多媒体应用一起交互的远程用户开发了常规功能并开发了连接性需求，像XBox 、XBOX360 、 Kinect 、 索尼的Playstation 3 或任天堂的Wii 等较近批次的多媒体控制台提供平台服务软件和其他平台服务应用，平台服务软件提供在这些计算机系统上执行的所有多媒体应用的常规功能，而其他平台服务应用独立于多媒体应用地运行服务。平台服务和多媒体应用常常同时执行。各应用之间的资源的争用可引起削弱用户体验的降低的性能。平台服务应用增强了用户的多媒体体验。平台服务应用不是操作系统或系统管理程序的功能。如同多媒体应用一样，平台服务应用可与操作系统或系统管理程序或系统软件一起工作。平台服务的示例是用于基于因特网的功能(如，电子邮件、社交联网、即时消息收发和聊天)和对这些功能的显示(包括现场语音聊天和现场视频共享)的因特网协议处理，诸如将数据打包在标准消息格式中。常规功能的其他示例是维护用户简档以及呈现独立于特定多媒体应用的菜单。将数据格式化成可被多媒体计算机系统所支持的所有应用使用的格式。平台提供标准化界面，多媒体开发者通过该界面来编程他们的多媒体应用。这种接口的一个示例是应用编程接口(API)。为了确保多媒体应用随时间的生存能力并促进各种系列的多媒体应用，对多媒体应用(尤其是对游戏控制台)的特征和性能的服务质量(QoS)保证在多媒体计算机系统设计中实现。与如个人计算机和蜂窝电话等其他硬件设备相比，这是所定义的多媒体控制台的高级特征中的一个。一般说来，确保在已装的第一控制台上运行的多媒体应用的代码的相同版本能在以后用相同的用户可辨别的性能在已装的最后控制台上运行例如4-10年。QoS保证的一些示例涉及实时等待时间和带宽需求。例如，可确保存储器读取在某一时窗内完成。在另一示例中，可确保对总线带宽的分配用于某些数据传输。随着时间的推移，由于数据和处理工作的量的增加，多媒体应用具有更多的存储器和带宽需求，以实时地提供越来越逼真的用户体验。此外，平台提供新服务来支持新形式的连接性和社交网络， 以增强用户体验，以及支持使用它们来进行传输的数据的新带宽和等待时间需求。平台服务还提供新的常规功能或改进当前功能的性能，以在用户体验中支持多媒体改进。为了一般基于有关特征和性能(例如，带宽和等待时间)的QoS保证提供多媒体应用随时间的一致性能，并允许平台服务缩放，可使用可减少争用并改进性能的不同体系结构技术。例如，专用硬件可被分开地分配给硬件资源的平台和应用资源，而它们在先前的系统中会经历非常高的并发利用率。在其他示例中，诸如为了带宽和等待时间保证，某些硬件资源(如总线和存储器)可能会被过度构建，这意味着资源具有超过对该资源的期望和保证使用的容量。这个方法还为平台服务的扩展或保证中的改变提供了增长的缓冲。在其他示例中，QoS软件根据用于在一个或多个平台服务应用之间分配资源的方法来执行，且多媒体应用根据用于基于可应用的QoS保证来提供多媒体应用的一致性能的标准来执行。图I提供了当前技术在其中可能有用的上下文示例。图I示出了本技术的各实施例可在其中操作的、其中用户正与正执行的多媒体应用进行交互的目标识别、分析和跟踪系统的示例实施例。在这个示例中，控制台计算环境12被示出。其他类型的多媒体计算机系统也可实现该技术。可实现该技术的其他类型的计算机系统的一些示例是机顶盒、个人计算机或如便携式计算机或手持式计算机设备的移动设备。目标识别、分析和跟踪系统10 可用来识别、分析和/或跟踪诸如用户18等的人类目标。目标识别、分析和跟踪系统10的各实施例包括用于执行游戏或其他应用的控制台计算环境12，以及用于从游戏或其他应用提供音频和视觉表示的视听设备16。系统10还包括用于在三个维度(3D)中捕捉位置和用户执行的移动的捕捉设备20，计算环境12接收、翻译并使用这些位置和移动来控制游戏或其他应用。控制台计算环境12的实施例可以包括硬件的计算资源、软件组件和/或固件组件，使得控制台12可以用于执行诸如游戏应用和非游戏应用之类的应用。在一个或多个实施例中，控制台计算机系统12可包括可执行存储在处理器可读存储设备上的用于执行此处描述的过程的指令的多个处理器，如标准化处理器、专用处理器、微处理器等。系统10还包括一个或多个捕捉设备20，用于捕捉与一个或多个用户有关的图像数据和/或由捕捉设备感测到的对象。在各实施例中，捕捉设备20可以用于捕捉与一个或多个用户的移动和姿势相关的信息，所述信息被计算环境接收并且被用于呈现游戏或其他应用程序的各方面、与所述各方面交互和/或控制所述各方面。下面更详细地解释控制台计算环境12和捕捉设备20的示例。目标识别、分析和跟踪系统10的实施例可以连接到具有显示器14的音频/视觉设备16。设备16例如可以是可向用户提供游戏或应用视觉和/或音频的电视机、监视器、 高清电视机(HDTV)等。例如，控制台计算环境12可包括可提供与游戏或其他应用相关联的音频/视觉信号的GPU和/或音频处理硬件和固件或在通用GPU上运行的音频软件。音频/视觉设备16可以从控制台计算环境12接收音频/视觉信号，并且然后可以向用户18 输出与该音频/视觉信号相关联的游戏或应用视觉和/或音频。根据一个实施例，音频/ 视觉设备16可经由例如S-视频电缆、同轴电缆、HDMI电缆、DVI电缆、VGA电缆、分量视频电缆、显示端口兼容电缆等连接至控制台计算环境12。在一示例实施例中，在控制台计算环境12上执行的应用可以是具有实时交互的游戏，诸如用户18可能正在玩的拳击游戏。例如，控制台计算环境12可使用视听设备16 来向用户18提供拳击对手22的视觉表示。控制台计算环境12还可使用视听设备16来提供用户18可通过他的或她的移动来控制的玩家化身24的视觉表示。例如，用户18可在物理空间中挥拳猛击，这使得玩家化身24在游戏空间中挥拳猛击。由此，根据一示例实施例， 捕捉设备20使用此处描述的技术来捕捉物理空间中重拳的3D表示。捕捉设备20中的处理器(参见图2A)和目标识别、分析和跟踪系统10的控制台计算环境12可用于识别并分析用户18在物理空间中的重拳，从而使得该重拳可被实时地翻译成玩家化身24在游戏空间中的姿势或游戏控制。多媒体控制台12可通过将该系统简单地连接到电视机或其他显示器而作为独立系统来操作。在该独立模式中，多媒体控制台12允许一个或多个用户与该系统交互、看电影、或听音乐。然而，随着通过网络接口或无线适配器可用的宽带连接的集成，多媒体控制台12还可作为较大网络社区中的参与者来操作。
图2示出了与捕捉设备通信地耦合的控制台计算系统的示例性实施例。根据一示例性实施例，捕捉设备20可被配置为通过可包括例如飞行时间、结构化光、立体图像等在内的任何合适的技术来捕捉包括深度图像的带有深度信息的视频，该深度图像可包括深度值。根据一实施例，捕捉设备20可将深度信息组织为“Z层”或者可与从深度相机沿其视线延伸的Z轴垂直的层。如图2所示，捕捉设备20可以包括相机组件423。根据一示例性实施例，相机组件 423可以是或者可以包括可捕捉场景的深度图像的深度相机。深度图像可包括所捕捉的场景的二维(2-D)像素区域，其中2-D像素区域中的每个像素都可以表示深度值，比如所捕捉的场景中的物体与相机相距的例如以厘米、毫米等为单位的距离。相机组件423可以包括可用于捕捉场景的深度图像的红外(IR)光组件425、三维 (3D)相机426、以及RGB (视觉图像)相机428。例如，在飞行时间分析中，捕捉设备20的IR 光组件425可以将红外光发射到场景上，并且然后可以使用传感器(在一些实施例中包括未示出的传感器)、例如使用3-D相机326和/或RGB相机428来检测从场景中的一个或多个目标和物体的表面后向散射的光。在某些实施例中，可以使用脉冲红外光，使得可以测量出射光脉冲和相应的入射光脉冲之间的时间差或相移并将其用于确定从捕捉设备20到场景中的目标或物体上的特定位置的物理距离。根据另一实施例，捕捉设备20可包括两个或更多物理上分开的相机，这些相机可从不同角度查看场景以获得视觉立体数据，该视觉立体数据可被解析以生成深度信息。也可使用其他类型的深度图像传感器来创建深度图像。捕捉设备20还可以包括话筒430，所述话筒430包括可以接收声音并将其转换成电信号的换能器或传感器。话筒430可用于接收也可提供给控制台计算系统12的音频信号。在一示例实施例中，捕捉设备20还可包括可与图像相机组件423进行通信的处理器432。处理器432可包括可执行指令的标准处理器、专用处理器、微处理器等，这些指令例如包括用于接收深度图像、生成合适的数据格式(例如，帧)以及将数据传送给控制台计算系统12的指令。 捕捉设备20还可包括存储器434，该存储器434可存储由处理器432执行的指令、 由3-D相机和/或RGB相机所捕捉的图像或图像帧、或任何其他合适的信息、图像等等。根据一示例实施例，存储器434可包括随机存取存储器(RAM)、只读存储器(ROM)、高速缓存、 闪存、硬盘或任何其他合适的存储组件。如图2所示，在一个实施例中，存储器434可以是与图像捕捉组件423和处理器432进行通信的单独组件。根据另一实施例，存储器组件434 可被集成到处理器432和/或图像捕捉组件422中。捕捉设备20通过通信链路436与控制台计算系统12通信。通信链路436可以是包括例如USB连接、火线连接、以太网电缆连接等的有线连接和/或诸如无线802. lib、 802. llg、802. Ila或802. Iln连接等的无线连接。根据一个实施例，控制台计算系统12可以通过通信链路436向捕捉设备20提供可用于确定例如何时捕捉场景的时钟。附加地，捕捉设备20经由通信链路436将由例如3-D相机426和/或RGB相机428捕捉的深度信息和视觉(例如RGB)图像提供给控制台计算系统12。在一个实施例中，深度图像和视觉图像以每秒30帧的速率来传送，但是可以使用其他帧速率。控制台计算系统12然后可以创建模型并使用模型、深度信息、以及所捕捉的图像来例如控制诸如游戏或文字处理程序等的CN 102591418 A
书
明
说
6/16 页
应用和/或使化身或屏上人物动画化。控制台计算系统12包括深度图像处理和骨架跟踪模块450，该模块使用深度图像来跟踪可被捕捉设备20的深度相机功能检测到的一个或多个人。深度图像处理和骨架跟踪模块450向应用452提供跟踪信息，该应用可以是视频游戏、生产性应用、通信应用或其他软件应用等。还可将音频数据和视觉图像数据提供给应用452以及深度图像处理和骨架跟踪模块450。应用452将跟踪信息、音频数据和视觉图像数据提供给识别器引擎454。在另一实施例中，识别器引擎454从深度图像处理和骨架跟踪模块450直接接收跟踪信息，并从捕捉设备20直接接收音频数据和视觉图像数据。在一些实施例中，深度图像处理和骨架跟踪模块450可以被认为是共享资源，且在其他实施例中它也可被认为是执行多媒体应用的处理的平台资源。识别器引擎454与过滤器460、462、464、……、466的集合相关联，每一过滤器包括关于可由捕捉设备20检测的任何人或物体执行的姿势、动作或状况的信息。例如，来自捕捉设备20的数据可由过滤器460、462、464、……、466来处理，以便标识一个用户或一组用户何时执行了一个或多个姿势或其他动作。这些姿势可与应用452的各种控制、对象或状况相关联。因此，控制台计算系统12可以将识别器引擎454和过滤器一起用于解释和跟踪对象(包括人)的移动。捕捉设备20向控制台计算系统12提供RGB图像(或其他格式或色彩空间的视觉图像)和深度图像。深度图像可以是多个观测到的像素，其中每个观测到的像素具有观测到的深度值。例如，深度图像可包括所捕捉的场景的二维(2-D)像素区域，其中该2-D像素区域中的每个像素都可具有深度值，诸如所捕捉的场景中的物体与捕捉设备相距的距离。 控制台计算系统12将使用RGB图像和深度图像来跟踪用户或对象的移动。例如，系统将使用深度图像来跟踪人的骨架。可以使用许多方法以通过使用深度图像来跟踪人的骨架。 使用深度图像来跟踪骨架的一个合适的示例在Craig等人2009年10月21日提交的美国专利申请12/603，437 “Pose Tracking Pipeline (姿态跟踪流水线)”(以下称为’ 437申请)中提供，该申请的全部内容通过引用结合于此。‘437申请的过程包括获得深度图像； 对数据进行降采样；移除和/或平滑化高方差噪声数据；标识并移除背景；以及将前景像素中的每个分配给身体的不同部位。基于这些步骤，系统将使一模型拟合到该数据并创建骨架。该骨架将包括一组关节和这些关节之间的连接。也可使用用于跟踪的其他方法。在下列四个美国专利申请中还公开了合适的跟踪技术，所述专利的全部内容都通过引用并入本文于2009年5月29日提交的美国专利申请12/475，308 “Device for Identifying and Tracking Multiple Humans Over Time (用于随时间标识和跟踪多个人类的设备)”；于 2010 年 I 月 29 日提交的美国专利申请 12/696，282“Visual Based Identity Tracking(基于视觉的身份跟踪)”；于2009年12月18日提交的美国专利申请12/641,788 “Motion Detection Using Depth Images (使用深度图像的运动检测)”；以及于2009年10月7日提交的美国专利申请12/575，388 “Human Tracking System(人类跟踪系统)”。识别器引擎454包括多个过滤器460、462、464、......、466来确定姿势或动作。过
滤器包括定义姿势、动作或状况以及该姿势、动作或状况的参数或元数据的信息。例如，包括一只手从身体背后经过身体前方的运动的投掷可被实现为包括表示用户的一只手从身体背后经过身体前方的运动的信息的姿势，因为该运动将由深度相机来捕捉。然后可为该姿势设定参数。当姿势是投掷时，参数可以是该手必须达到的阈值速度、该手必须行进的距离(绝对的，或相对于用户的整体大小)、以及识别器引擎对发生了该姿势的置信度评级。 用于姿势的这些参数可以随时间在各应用之间、在单个应用的各上下文之间、或在一个应用的一个上下文内变化。应用452可使用识别器引擎454所提供的过滤器460、462、464、……、466，或者它可提供其自己的、插入到识别器引擎454中的过滤器。在一个实施例中，所有过滤器具有启用该插入特性的通用接口。此外，所有过滤器可利用参数，因此可使用以下单个姿势工具来诊断并调节整个过滤器系统。关于识别器引擎454的更多信息可在2009年4月13日提交的美国专利申请 12/422, 661 “Gesture Recognizer System Architecture (姿势识别器系统架构)”中找到，该申请的全部内容通过引用结合于此。关于识别姿势的更多信息可在2009年2月23 日提交的美国专利申请12/391，150 “Standard Gestures (标准姿势)”；以及2009年5月 29日提交的美国专利申请12/474，655“Gesture Tool (姿势工具)”中找到，这两个申请的全部内容都通过引用结合于此。图3A至图5B公开了提供多媒体应用QoS保证同时允许计算资源支持平台服务应用随时间进行缩放的多媒体计算机体系结构的实施例。在一些实施例中，QoS保证可以由软件控制的硬件资源分配机制来实施。硬件机制在资源分配必须发生或者资源分配必须在非常精细粒度的时间基础上(即，每一个时钟周期到十个时钟周期)更新以确保用户感知到的性能的一致性时通常是必需的(与软件机制相反)。除了通常由第三方开发的针对多媒体应用的QoS保证之外，还可存在例如与计算机系统上运行的所有应用(例如，平台、多媒体或其他)或大多数应用可用的等待时间和带宽有关的系统标准。例如，即使单个平台服务正在运行，而没有如游戏之类的任何其他多媒体应用在运行，系统还可执行与系统通信构造(例如，总线或纵横互连)的带宽和等待时间有关的系统标准。如以下附图所示，多媒体计算机系统的各所示实施例中的一些计算资源，尤其是硬件资源，被包括在平台分区或应用分区中。为了便于描述，平台分区中的计算资源成为平台资源，且应用分区中的计算资源成为应用资源。这些分区是逻辑分区。图3A是向QoS多媒体应用保证提供可缩放平台服务的多媒体计算机系统体系结构的一实施例的框图。平台服务应用327和多媒体应用329中的每一个都依赖于主要用于处理它们的相应功能的硬件。平台分区包括诸如中央处理单元(CPU) 302和图形处理单元 (GPU) 306之类的资源以及其他平台资源332。平台CPU 302可以是单核处理器或多核处理器。平台CPU302包括高速缓存305。可以为应用CPU的高速缓存305和高速缓存303实现各种高速缓存设计。高速缓存临时地存储数据，并因此减少了存储器存取周期的数量，从而改进了处理速度和吞吐量。平台CPU 302还包括闪速ROM(只读存储器)340，该闪速ROM 340可存储在多媒体计算机系统12通电时在引导进程的初始阶段期间加载的可执行代码。 GPU 306以及以下的应用GPU 308可具有嵌入式存储器来用于其数据处理。其他平台资源332的一些示例在以下附图中示出。这种平台资源332可包括向输入和输出单元320提供输入和输出接口，平台资源332的一些示例是用户输入设备(用户移动、游戏控制器、定点设备)、显示器、如相机20图之类的像捕捉设备、可移动介质(例如，存储棒、DVD、存储器驱动器)、打印机以及可经由通用串行总线(USB)、路由器和以太网电缆来连接的其他设备。平台资源332可提供的资源的一些示例包括诸如视听I/O单元之类的端口输入和输出硬件及驱动器、USB端口控制器、以太网端口或其他因特网或网络连接接口，诸如WiFi或其他无线协议。此外，平台资源332可包括可移动介质的接口，诸如用于访问例如热插拔的、高密度的大容量存储闪存的串行高级技术附连SATA (ODD和HDD两者) 接口。应用分区包括CPU 304、GPU 308和其他应用资源330。CPU 304还可包括一个或多个处理核，并可包括表示通常与一个或多个核的处理单元相关联的一个或多个高速缓存等级的高速缓存303。在其较低成本的实施例中，可存在不同的应用和平台CPU，但可存在使其资源通过软件和硬件机制来分配的共享GPU。应用GPU 304还包括闪存ROM 304，该闪存ROM 304可存储在多媒体控制台12通电时在引导进程的初始阶段期间加载的可执行代码。应用资源330可包括仅可被应用处理单元访问的高速闪存。在一些实施例中，在一个或多个平台服务应用在所述平台处理单元中的至少一个上以及所述多媒体应用在所述应用处理单元中的至少一个上的并发执行期间，应用处理单元并不执行所述一个或多个平台服务应用。换言之，应用处理单元执行除平台服务应用的指令以外的处理。应用处理单元将执行操作系统、系统管理程序和如标准系统功能的代码， 但它们被解除适用于CPU和GPU的先前系统的QoS保证，诸如并发的平台服务应用的执行的处理时间的百分比。在为平台服务和多媒体应用提供分开的处理单元的各实施例中，相应处理单元的高速缓存和嵌入式RAM在相应分区中是不被共享的；并且因此，它们不会因为在平台服务应用和多媒体应用之间切换的应用而颠簸(thrash)。另外，通过分区计算机系统的资源，平台资源可以独立于QoS保证中的至少一些操作，或者可以随着时间的推移而增长以尤其在因硬件改进而提供了更多的平台服务时减少该保证的影响。例如，可用的对GPU处理的QoS保证可仅适用于应用GPU 308但不适用于平台GPU。一些实施例可能仍实施可使应用处理单元的处理时间的某一百分比专用于针对一个或多个平台服务应用的处理的QoS保证。这一保证帮助保持多媒体应用的操作随时间的一致性。该保证可通过插入延迟线程以占据处理时间的百分比的方式来实施。平台服务应用优选地被调度为在预定时间并以预定时间间隔在CPU 308上运行，以便为该应用提供一致的系统资源视图。进行调度是为了把由在控制台上运行的游戏应用所引起的高速缓存中断最小化。提供系统存储器331来存储在引导过程期间加载的软件代码和数据。在这个示例中，系统存储器331存储平台服务应用327的平台处理单元302和306可加载的代码。在这个实施例中，QoS保证软件333及优先级方案333也被存储在系统存储器中。QoS保证软件可实现在对资源的请求的排定优先级时可用的一个或多个优先级方案。例如，可向资源执行系统关键功能(如存储器刷新)和影响用户体验的具有实时要求的那些执行功能分配优先级，并且可向如多媒体应用和平台服务应用等不同的应用分配较低的优先级。影响用户体验的具有实时要求的各功能的一些示例是使用带宽和高等待时间来避免TV或监视器处的含假信号的视频或者来自话筒的可听流行乐曲的视频输出处理和其他实时的数据分发情况。
此外，QoS保证软件333在执行时可实现一种有关存储器基于用于提供一致的实时性能或一致的用户体验的标准来请求的QoS保证方法。这种标准的一些示例是每一个处理单元的执行效率；以及存储器通道效率。处理单元不会很好地忍受等待时间。未使用的时钟周期代表CPU或GUP的低效的执行效率。对存储器通道的低效使用的一示例是一次激活太多的存储器排(memory bank)。另一示例是使一个存储器通道超载，同时另一个存储器通道是空闲的。另外，由平台处理单元302和306、在其他平台资源332或共享资源312中的其他逻辑或控制单元从系统存储器331执行一个或多个软件虚拟化接口 328(在这个示例中被实现为应用编程接口(API))。在一些实施例中，虚拟化接口 328中的一个或多个也可对资源的处理请求中实现优先级方案333。每一硬件资源具有伴随来自相应的硬件资源的请求的客户机标识(ID)。在一些实施例中，适用于请求的QoS保证或系统标准可由提出请求的硬件资源的客户机ID来标识出。在一些实施例中，平台分区包括被虚拟化成正执行的多媒体应用的硬件设备。在一些情况下，多媒体应用通过正在平台处理单元或共享处理单元上执行的软件虚拟化接口来访问这一平台硬件设备。因此，随着实际硬件正实现所请求的处理或资源，并不需要考虑该应用分区，并且资源看见了平台或共享设备的客户机ID。此外，可适用于虚拟化资源的QoS保证(例如，显示处理的速度)可为应用而保持不变，而平台分区中的视频编码器被升级成能处理更多技术的更快的视频编码器。系统存储器331还包括分区分配软件334。在一些实施例中，多媒体计算机系统可以是共享处理单元资源的较大计算机系统中的多个计算机中的一个。在一些实施例中， 多媒体计算机系统可包括比图3A中示出的代表性处理单元更多的处理单元。由于这些分区是逻辑性的，分区分配软件334在执行时可在平台和各应用分区之间动态地分配计算机资源。例如，在云计算示例中，由于更多的用户加入在线交互游戏，分区分配软件334可通过网络从云中的另一个计算机处接收消息，以将其平台CPU和GPU重新分配为应用CPU和 GPU。在这一示例中，在应用分区中指定比在平台服务分区中多的处理单元可更为高效，使得存在更多的处理单元可用于多媒体应用的不同执行实例。系统管理控制器325提供涉及确保多媒体计算机系统12的可用性的各种服务功能。当多媒体计算机系统12通电时，可从系统存储器331加载平台应用数据327以供平台处理单元302、306执行。平台应用可呈现用于在导航到多媒体计算机系统12上可用的不同媒体类型时提供一致的用户体验的图形用户界面。在操作中，可将多媒体应用329从计算机系统内置的非易失性存储器322或从多媒体应用329从其开始和播放的外置的媒体驱动器320处加载非易失性存储器322。每一处理单元302、304、306和308与通信结构310进行交互。系统的通信结构 310是可被任一分区的资源直接访问的共享计算资源312的一个示例。在通信结构的一些示例是总线或互连结构。在一些实施例中，通信结构310可具有适应多媒体应用的一个或多个等待时间QoS保证，并在相同时间基于与该结构的带宽或等待时间有关的系统标准来满足来自一个或多个平台服务应用的总线访问请求的额外带宽容量。由于该带宽超过了请求量，存在可以忽略的争用。这确实允许其他平台服务应用随着时间的推移而增加，这将减少额外的开销。在另一个实施例中，每一分区处理单元或至少每一分区CPU在纵横方案中可具有虚拟的私有总线通道。在其他示例中，每一分区处理单元或一分区的处理单元可具有其自己的物理上分开的总线。除了额外的容量方案以外，如果不能满足同时发生的请求， 则至少部分地基于QoS保证的优先级方案可用于定量配给(ration)访问。共享资源312还包括用于访问存储器322的存储器控制器314，存储器322可包括应用可访问的非易失性存储器、易失性存储器或两者。在一个实施例中，存储器322具有超过针对多媒体应用的一个或多个QoS保证的需求的有效带宽和等待时间性能，且一个或多个标准量限制在相同时间执行的平台服务的数目。这个有效带宽和等待时间性能可以用额外的存储器大小和用于访问存储器的更多的通道来实现。例如，通常同时执行的一组或多组平台服务应用的模型可基于不同的用户使用场景来开发。存储器的有效带宽和等待时间性能的量可以超过在该组平台应用的运行时期间使用的有效带宽和等待时间性能，因为在该组平台应用的运行时期间要求存储器的最多的有效带宽和等待时间性能，并要求由针对多媒体应用的QoS保证所需的有效性能，以便避免用户可感知到的多媒体应用的性能改变。在一个示例中，多媒体应用可能存在所分配的量或百分比的有效存储器性能，并且来自平台或其他系统服务的请求满足未被分配的带宽和等待时间资源。在另一实例中，不同的操作场景、系统标准或QoS保证或这些的组合可用作用于对可在运行时期间被分配的存储器的有效带宽和等待时间性能设定限制的准则的基础，该准则作为QoS保证或系统标准的一部分。存储器控制器314可随后利用存储器322的未被分配的容量来满足针对多媒体应用的一个或多个QoS保证。图3B是多媒体计算机系统体系结构的另一个实施例的框图，该多媒体计算机系统体系结构如同图3A中的多媒体计算机系统体系结构具有附加的共享CPU和GPU。在这个实施例中，存在由系统12提供的另一个CPU和GPU、共享的GPU 309和共享的CPU 307。在一示例中，这些系统处理单元307、309可执行API 328，这些API 328与两个分区的处理单元进行交互来处理对位于平台服务分区或共享资源312中的资源的请求。这允许平台服务处理单元302、306不用对应用单元的请求进行处理。在另一个实施例中，共享的GPU 309 和共享的CPU可基于QoS保证为平台服务应用的执行指令、多媒体应用的指令或两者提供附加的处理资源。在又一实施例中，共享的CPU 307、共享的GPU 309或两者可执行不同的通用操作系统(例如，Windows )，或提供由平台服务或这多媒体应用提供的功能之外的附加的功能。例如，这些处理单元307、309可运行标准的个人计算机(PC)操作系统及其相关联的图形用户界面，并可运行该PC OS提供的或与其兼容的应用和服务，诸如通过浏览器的因特网访问、文子处理、生产力、内容生成和视听应用。在图3A中，系统存储器还可存储模式改变软件335。这是针对不同的实施例的，其中代替具有用于以通用模式来执行多媒体计算机系统的分开的CPU和GPU，该软件切换出各分区中的一个分区的CPU(如应用CPU)来以通用计算机模式进行执行。分区的GPU也可以被切换出。为了便于描述，多媒体应用(如游戏)对平台服务执行的模式是指定的多媒体模式，并且通用操作系统正执行的操作模式称为通用计算机模式。用于可经由输入设备来提供指示他或她期望在各模式之间进行切换的输入。当在模式之间进行切换时，处于当前执行模式中的系统的状态被设为休眠。在一些示例中，CPU和GPU加载有指令，并且数据在被执行其他模式所需要时被加载到运行时存储器中。(为了便于描述该讨论仅说明了在两个模式之间进行切换，但是可以在多于两个模式之间改变模式。)在一些实施例中，如果被切换到的模式先前具有正在运行的其他应用，则这些应用的状态可被恢复成所切换的模式的点。图3C是用于在多媒体模式和通用计算模式之间改变至少一个处理单元的操作模式的方法的一实施例的流程图。在步骤402模式改变软件335将至少一个处理单元的当前模式执行状态数据存储在存储器(例如，322)中，并在步骤404将正在至少一个处理单元上执行的任何应用的当前运行时存储器内容存储在存储器中。执行状态数据的一些示例是指令队列的当前内容，和在处理单元本地的CPU或GPU寄存器、高速缓存、嵌入式RAM或任何其他存储器的内容，和操作系统、当前模式的显示以及其他系统功能的状态数据。运行时存储器内容的一些示例是处理信息，和任何正在执行的应用的由系统在该应用的当前执行实例期间存储在易失性或非易失性存储器中的数据。在步骤406，模式改变软件335为至少一个处理单元加载所请求的模式(即，被改变成的模式)的先前存储的执行状态数据，并在步骤408为先前以所请求的模式在至少一个处理单元上执行的任何应用加载先前存储的运行时存储器内容。图4示出了向QoS多媒体保证提供可缩放的平台服务的多媒体计算机系统的计算系统体系结构的另一示例实施例。多媒体控制台100具有平台CPU 302和应用CPU 304。 为了便于附图中的连接，这些CPU在用一模块中被示出；然而，它们是分开的单元且并不共享任何高速缓存或ROM。平台CPU 302可以是单核处理器或多核处理器。在这个示例中，平台CPU 302具有一级(LI)高速缓存305 (I)和二级(L2)高速缓存305 (2)和闪速ROM(只读存储器)304。多媒体控制台100还包括用于执行多媒体应用功能的应用CPU 304。CPU304还可包括一个或多个处理核。在这个示例中，应用CPU 304具有一级高速缓存303 (I)和二级高速缓存303 (2)和闪速ROM (只读存储器)342。多媒体控制台100还包括平台图形处理单元(GPU) 306和应用图形处理单元 (GPU) 308 0为了便于附图中的连接，这些CPU在用一模块中被示出；然而，它们是分开的单元且并不共享任何存储器结构。每一 GPU具有其自己的嵌入式RAM 311、313。多媒体控制台100内的CPU 302,CPU 304,GPU 306,GPU 308、存储器控制器314、 和各个其他组件经由一条或多条总线互连，这些总线包括串行和并行总线、存储器总线、外围总线、和使用各种总线架构中任一种的处理器或局部总线。作为示例，这些体系结构可包括用于到IO芯片的连接和/或作为将来的IO扩展的连接器的外围组件互联(PCI)总线、 快速PCI总线等。通信结构310代表各种总线或通信链路中的一个或多个，该通信结构310 也可如对图3A中的通信结构310所讨论的具有额外容量。在这个实施例中，每一 GPU和视频编码器/视频编解码器(编码器/解码器)345 形成用于高速和高分辨率图形处理的视频处理流水线。来自GPU 306、308的嵌入式RAM 311、313的数据被存储在存储器322中。视频编码器/视频编解码器345经由通信结构310 来访问存储器322中的数据。视频处理流水线向A/V(音频/视频)端口 344输出数据，以便传输到电视机或其他显示器。由例如平台聊天应用之类的应用生成的轻量消息(例如，弹出框)是通过使用GPU 来调度用于将弹出框呈现在覆盖视频平面中的代码来创建的。覆盖平面所使用的存储器量取决于覆盖区域大小，并且该覆盖图较佳地与屏幕分辨率成比例缩放。在并发平台服务应用使用完整用户界面的情况下，优选使用独立于应用分辨率的分辨率。定标器可用于设置该分辨率，从而消除了对改变频率并弓I起τν重新同步的需求。存储器控制器314促进处理器访问各种类型的存储器322，诸如但不限于，一个或多个DRAM(动态随机存取存储器)通道。多媒体控制台100包括较佳地在模块318上实现的I/O控制器348、系统管理控制器325、音频处理单元323、网络接口控制器324、第一 USB主控制器349、第二 USB控制器 351和前面板I/O子部件350。USB控制器349和351用作外围控制器352 (I) -352 (2)、无线适配器358、和外置存储器设备356 (例如闪存、外置⑶/DVD ROM驱动器、记忆棒、可移动介质等)的主机。网络接口 324和/或无线适配器358提供对网络(例如，因特网、家庭网络等)的访问并且可以是包括以太网设备、调制解调器、蓝牙模块、电缆调制解调器等的各种不同的有线或无线适配器组件中任何一种。提供系统存储器331来存储在引导过程期间加载的应用数据。提供媒体驱动器 360且其可包括DVD/⑶驱动器、蓝光驱动器、硬盘驱动器、或其它可移动媒体驱动器等。媒体驱动器360可以内置或外置于多媒体控制台100。应用数据可经由媒体驱动器360访问， 以由多媒体控制台100执行、回放等。媒体驱动器360经由诸如串行ATA总线或其他高速连接(例如IEEE 1394)等总线连接到I/O控制器348。系统管理控制器325提供涉及确保多媒体控制台100的可用性的各种服务功能。 音频处理单元323和音频编解码器346形成具有高保真度和立体声处理的对应的音频处理流水线。音频数据被存储在存储器322中，并被通过高保真立体声和多通道音频处理来形成相应的音频处理流水线的音频处理单元323和音频输入/输出单元346访问。当并发平台服务应用需要音频时，则由于时间敏感性而将音频处理异步地调度给游戏应用。音频处理流水线将数据输出到A/V端口 344以供外部音频用户或具有音频能力的设备再现。前面板I/O子部件350支持暴露在多媒体控制台100的外表面上的电源按钮351 和弹出按钮353以及任何LED(发光二极管)或其他指示器的功能。系统供电模块362向多媒体控制台100的组件供电。风扇364冷却多媒体控制台100内的电路。多媒体控制台100可通过将该系统简单地连接到电视机或其他显示器而作为独立系统来操作。在该独立模式中，多媒体控制台100允许一个或多个用户与该系统交互、看电影、或听音乐。然而，随着通过网络接口 324或无线适配器358可用的宽带连接的集成， 多媒体控制台100还可作为较大网络社区中的参与者来操作。在多媒体控制台100引导且系统资源被保留之后，执行并发平台服务应用来提供平台功能。平台功能被封装在上述所保留的系统资源中执行的一组平台应用中。操作系统内核标识是平台服务应用线程而非游戏应用线程的线程。任选的输入设备(例如，控制器352(1)和352(2))由游戏应用和系统应用共享。 输入设备要在平台应用和游戏应用之间切换，使得其各自具有设备的焦点。I/O管理器348 较佳地控制输入流的切换，且驱动程序维护关于焦点切换的状态信息。捕捉设备20可以通过USB控制器349或其他接口来为控制台100定义附加的输入设备。图5A是向QoS多媒体保证提供可缩放平台服务的游戏控制台计算机系统12体系结构的一实施例的框图。每一个样本处理单元与共享资源通信结构310的一实施例进行交互，在本案中该共享资源通信结构310是互连结构310。结构310可以是片上总线。存储器控制器314控制用于经由多个存储器通道316中的一个或多个来访问共享存储器(此处所示的示例为一种形式的DRAM)的存储器总线315。在这个实施例中，存在三个CPU和两个GPU。平台GPU 306被示为具有嵌入式RAM 313。应用GPU 308也被示为具有嵌入式RAM 311。如以上所提到的，在一些实施例中，GPU 可以不具有嵌入式存储器。平台CPU 302用高速缓存305作为一般用于指令和用于数据的一级高速缓存和二级高速缓存的一实施例来示出。应用CPU 304用高速缓存306作为一般用于指令和用于数据的一级高速缓存、二级高速缓存和三级(L3)高速缓存的一实施例来示出。用高速缓存506作为一级和二级高速缓存的一实施例来将共享的CPU 307示为多核 CPU。模块519示出了多个输入和输出控制器。音频处理单元542和544说明了专用硬件方法。应用音频处理器单元542在这个示例中是应用硬件分区的一部分并且不必为平台服务应用执行音频处理。平台音频处理器544为一个或多个平台服务应用执行音频处理， 并为通过平台服务软件API 328来请求的一些多媒体应用音频任务执行音频处理。每一音频处理器单元可包括用于编码和解码从平台AV I/O控制器510接收或者向其输出的音频数据的硬件或数字信号处理器(DSP)或CPU执行固件。可在不同的通道上并行地输入和输出不同的音频。例如，玩游戏的用户可在一个通道上具有他们的音频，而游戏的音频正在其他通道上播放。所共享的专用处理器550可提供额外的计算资源。专用处理器550可支持的处理的一些示例是音频和视频处理、传感器处理和图像数据处理。除了共享专用处理器550以外，其他所示的I/O控制器是在平台服务分区中多媒体应用通过软件虚拟化接口 328(例如，API)来进行访问的资源的示例。这些资源中的一些用于具有较少性能影响的共享硬件设备，诸如用户输入和输出设备(例如，游戏控制器、键盘、定点设备)。要么它们是较底的带宽，要么当前所需的等待时间(为了满足用户体验需求)非常长，或者它们具有固有的重试能力。这些类型的硬件设备(它们并不是时间关键的)的其他示例包括但不限于以太网、WiFi、SATA (ODD和HDD)、高密度大容量存储闪存、USB (用于许多设备类型)等。存在将从游戏应用分区的观点来进行虚拟化的另一种分类的资源，并且平台服务分区将充分地隐藏性能保证，即使存在实时等待时间和BW需求时也是这样。这些资源的示例包括如平台显示控制器540视频解码器/编码器(即，VC-I、H. 264、MPEG-2、MPEG-4等)、 视频质量框(即，运动自适应解交织、光斑减少、抖动减少等)、平台I/O控制器348(例如， 快速PCI-e接口)和平台视听(AV)输入/输出接口控制器510(例如，其接收相机输入552) 的硬件资源。这些框与实时视频直接相关，其对用户体验具有关键的实时需求。在这些情况中，软件API328被游戏应用329用来进行访问。针对一致的实时性能的使用模块用于避免由于作为整个总平台中的下溢/溢出或其他低级QoS问题而引起的退出或错误。平台视听控制器510控制与视听设备或分开的显示和音频输出设备的视听输入/输出接口。可使用的接口的示例包括某一版本的显示端口(DP)、高清晰度多媒体接口(HDMI)和数字音频信号的索尼/飞利浦数字互连格式(S/PDIF)。图5B是向QoS多媒体保证提供可缩放的平台服务的多媒体控制台体系结构的另一实施例的框图，该框图类似于图5A，除了在这个实施例中应用分区还包括高速、随机存取闪速存储器控制器572，该闪速存储器控制器572用于控制在闪存接口 574的一个或多个通道518上的传输以访问高速、随机存取闪存536。在这个示例中，分区分配软件334已经映射了应用程序单元304、408以允许它们访问高速随机存取闪存536而非访问平台处理单元 306,302ο图2至图5Β中示出的示例计算机系统包括计算机可读存储介质的示例。这样的介质可包括以用于存储诸如计算机可读指令、数据结构、程序模块、或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括，但不限于，RAM、ROM、EEPR0M、高速缓存、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD) 或其他光盘存储、记忆棒或卡、磁带盒、磁带、媒体驱动器、硬盘、磁盘存储或其他磁性存储设备、或能用于存储所需信息且可以由计算机访问的任何其他介质。图6是描述了用于基于对多媒体应用的一个或多个服务质量(QoS)保证在多媒体应用和平台服务应用之间分配计算资源的过程的一个实施例的流程图。在步骤702软件接口 API 328接收对处理的请求，并在步骤703确定该请求是否是对执行影响用户体验的关键实时处理的资源的请求。如果是，则在步骤705相对于其他实时关键请求来处理该请求。 例如，可根据对显示器的视频数据的存储器读取来排定DRAM刷新的优先级。如果该请求不是对执行关键实时用户体验处理的资源的请求，则在步骤704软件API 328确定该请求是否是对多媒体应用的请求。在一个实施例中，客户机ID可标识来自应用分区资源的请求。 在另一个示例中，该请求可来自平台资源但包括指示它是对多媒体应用执行的请求的数据段。响应于该请求是对除多媒体应用329以外的应用的请求，资源在步骤706基于在多媒体计算机系统12中的资源的当前条件来处理该请求。当前条件一般指计算机系统以及当前正在执行的特定资源的当前操作状态。例如，多媒体应用可被加到运行时存储器中并执行，但是由于用户已切换到了平台服务应用的菜单屏或者已点击了 “暂停”因此它处于“暂停”状态。这种操作状态将可能降低对应用的请求的优先级。按照图3A中的所存储的优先级方案333，还可存在如DRAM刷新或高安全威胁之类的并发系统功能，这些并发系统功能在优先级上比对资源的应用请求更高，因为它们会影响计算机本身的操作的完整性。还可存在因其关键的实时性能窗口而比多媒体应用请求优先处理的平台服务，这些关键的实时性能窗口会不利地影响用户体验。一些示例将是音频输出处理和混音。另一示例是需要在微秒的时间段内更新显示的视频显示输出， 否则显示上的一些像素将因为显示数据未及时更新而是黑色区域。在一些实例中，自然用户界面(NUI)系统的相机图像数据可比来自应用CPU 304的一种类型的请求具有相对更高的优先级。此外,诸如QoS保证软件333之类的软件可基于优先级方案333将请求的优先级重新安排在不同资源的可编程队列中。如果请求是对多媒体应用的请求，则软件接口 328在步骤708确定在请求资源的当前条件下QoS保证参数是否被满足。例如，视频编码器345在对多媒体应用的请求先前可具有两个请求，但每个请求都具有使对发送多媒体应用的流传输视频的QoS等待时间保证仍被满足的数据大小。当请求可在资源的当前条件下被满足时，在步骤710资源基于当前条件处理请求。如果可适用的QoS保证参数在当前的资源条件下不能被满足，则资源分配控制单元620在步骤712在处理请求时应用QoS保证处理技术。图7和图8提供应用图6的过程的QoS保证处理技术的实现实例。
图7是描述了实现优先级的过程作为针对等待时间保证的QoS保证处理技术的一个实施例的流程图。步骤702至706如以上对图6所讨论的那样执行。如果请求是对多媒体应用的请求，则API在步骤808确定在资源当前条件下针对处理的QoS保证的上限或最大限制是否可被满足。上限的示例是用于处理存储器存取请求的最大时间量。上限的另一示例是基于显示刷新率的时间限制。例如，游戏应用通常基于30Hz或60Hz的实际时间， 并且在每一帧时间内存在许多性能关键部分，这在限制了 QoS在其上执行的时间窗口的上限。如果请求在当前条件下不能满足QoS保证等待时间上限，则在步骤816中API 328分配可用于多媒体应用请求的最高优先级。例如，带着满足上限的目标，可在请求队列中提升该请求。例如按照存储在系统存储器311中的优先级方案333，优先级值的范围可能是可用于多媒体应用的。如果在步骤808确定在当前条件下针对处理的QoS等待时间保证的上限可被满足，则在步骤810软件API 328确定在当前条件下可适用的等待时间QoS保证的下限是否可被满足。对于一些资源，可存在下限，例如关于时间窗口的下限，以便在QoS实现中具有稳定的行为。下限可防止或减少QoS主动干涉，以免其发生得过多，QoS主动干涉将在整个计算机系统控制台上削弱其他性能的增加。例如，如用户输入设备之类的硬件设备由于它们较低的带宽使用、与其他资源相比有较长的等待时间保证或者它们具有固定的重试能力，因此它们具有较少的性能影响。如果在资源的当前条件下也满足下限或最小限制，则在步骤814资源基于当前条件来处理请求。如果在当前条件下不能满足对针处理的QoS保证的下限，则软件API 328在步骤812将延迟插入到处理中以满足下限或最小限制要求。在一些实施例中，上等待时间或下等待时间可申请例如I/O设备或诸如因特网连接之类的其他接口，其中输入或数据即使在第一时间没有被处理也可能会被再次发送。图8是示出用于基于用于提供一致的实时性能的准则来处理存储器请求的QoS保证方法的示例的流程图。在步骤922，存储器的QoS保证软件333或者存储器的API 328接收存储器存取请求。按照先前讨论的步骤703和705，如果该请求是对执行对用户体验的实时处理的资源的请求,则相对于其他实时关键请求来处理该请求。在步骤704，存储器的QoS保证软件333或存储器API 328确定请求是否来自执行对正执行的多媒体应用的处理的资源。如果请求是对多媒体应用的请求，则存储器QoS保证软件333、328在步骤926基于针对一致性能的准则和当前条件来确定由QoS所分配的存储器资源处理该请求的时间。如对图3A所讨论地，针对一致性能的准则的一些示例包括每一个处理单元的执行效率和存储器通道效率。按照当前的条件，可存在来自执行关键的实时处理的资源的请求，其为在对多媒体应用的请求前面的那个事件提供一致的用户体验和一致的计算机系统性能。另外，存储器请求的系统标准可以是当前条件的一部分。响应于请求不是对多媒体应用的请求，在步骤930QoS保证软件333或者存储器控制器API 328基于并非被分配用于针对多媒体应用的QoS保证请求的存储器资源的当前条件来处理该请求。在一些实施例中，对用于QoS请求的存储器资源的分配在执行期间可以是完全动态的或部分动态的。在其他实施例中，当多媒体应用正在执行时，用于QoS请求的存储器资源的分配可以是用于QoS保证请求的预留存储器。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。更确切而言，上述具体特征和动作是作为实现权利要求的示例形式公开的。
权利要求
1.一种用于执行服从针对多媒体软件应用的一个或多个服务质量(QoS)保证的处理的多媒体计算机系统，包括平台计算资源分区，它包括平台中央处理单元(CPU)和平台图形处理单元(GPU);以及应用计算资源分区，它包括应用CPU和应用GPU ；以及可被平台分区资源和应用分区资源访问的共享资源。
2.如权利要求I所述的多媒体计算机系统，其特征在于所述应用CPU和所述平台CPU是不具有任何共享的高速缓存存储器的分开的处理器。
3.如权利要求I所述的多媒体计算机系统，其特征在于所述应用GPU和所述平台GPU是不具有任何共享的嵌入式RAM存储器的分开的处理器。
4.如权利要求I所述的多媒体计算机系统，其特征在于，还包括具有被编码在其上的指令一个或多个计算机存储介质，所述指令用于使所述处理单元中的至少一个在平台和应用分区之间动态地分配计算资源。
5.如权利要求I所述的多媒体计算机系统，其特征在于在一个或多个平台服务应用在所述平台处理单元中的至少一个上以及所述多媒体应用在所述应用处理单元中的至少一个上的并发执行期间，所述应用处理单元并不执行所述一个或多个平台服务应用。
6.如权利要求I所述的多媒体计算机系统，其特征在于所述共享资源是可被所述平台CPU、所述平台GPU、所述应用CPU和所述应用GPU访问的存储器；并且所述系统还包括具有被编码在其上的指令的一个或多个计算机存储介质，所述指令用于使处理器基于以下准则来相对于所述存储器执行基于针对所述多媒体应用的一个或多个服务质量(QoS) 保证的QoS保证方法，所述准则包括所述处理单元中的每一个的执行效率；以及存储器通道效率。
7.如权利要求I所述的多媒体计算机系统，其特征在于，还包括所述平台分区包括对一个或多个平台服务应用和所述多媒体应用执行处理、但仅可被所述多媒体应用经由软件接口来访问的一个或多个硬件资源。
8.如权利要求I所述的多媒体计算机系统，其特征在于，还包括具有被编码在其上的指令的一个或多个计算机存储介质，所述指令用于使处理器执行基于针对多媒体应用的一个或多个服务质量(QoS)保证的QoS等待时间保证功能，所述方法包括确定是否针对所述多媒体应用的处理的QoS等待时间保证的上限不能被满足；以及响应于所述QoS等待时间保证的上限没有被满足，基于当前条件来分配可用于所述处理的最闻优先级。确定是否针对所述多媒体应用的处理的QoS等待时间保证的下限不能被满足；以及响应于所述QoS等待时间保证的所述下限没有被满足，将延迟插入到所述处理中以满足所述下等待时间限制。
9.一种用于执行服从针对多媒体软件应用的一个或多个服务质量(QoS)保证的处理的多媒体计算机系统，包括平台计算资源分区，它包括平台中央处理单元(CPU)和平台图形处理单元(GPU)；应用计算资源分区，它包括应用CPU和应用GPU ；可被所述处理单元中的每一个访问的存储器；以及具有被编码在其上的指令的一个或多个计算机存储介质，所述指令用于使所述处理单元中的至少一个执行一种用于在多媒体模式和通用计算机模式之间将操作模式改变成至少一个处理单元的所请求的模式。
10.如权利要求9所述的多媒体计算机系统，其特征在于，用于在多媒体模式和通用计算机模式之间改变所述至少一个处理单元的操作模式的方法包括将所述至少一个处理单元的当前模式执行状态数据存储在所述存储器中；将在所述至少一个处理单元上执行的任何应用的当前运行时存储器内容存储在所述存储器中。为所述至少一个处理单元加载所请求的模式的先前存储的执行状态数据；以及为先前在所述至少一个处理单元上以所请求的模式执行的任何应用加载先前存储的运行时存储器内容。
全文摘要
本发明涉及具有QOS保证的可缩放多媒体计算机系统体系结构。描述了各种版本的多媒体计算机系统体系结构，这些多媒体计算机系统体系结构满足对诸如游戏应用之类的多媒体应用的服务质量(QoS)保证，同时允许平台资源，尤其是硬件资源，随时间放大或缩小。将计算机系统的计算资源划分成平台分区和应用分区，每一分区都包括其自己的中央处理单元(CPU)和可选的图形处理单元(GPU)。为了改善资源的放大或缩小，平台分区包括只能被多媒体应用通过软件接口访问的一个或多个硬件资源。另外，在这些分区的外面可存在被这些分区共享或者提供通用计算资源的其他资源。
文档编号G06F1/16GK102591418SQ20111044011
公开日2012年7月18日 申请日期2011年12月15日 优先权日2010年12月16日
发明者J·V·塞尔, J·塔迪夫, J·安德鲁斯, M·S·格罗斯曼, N·R·贝克, S·卡丽 申请人:微软公司