具有QOS保证的可缩放多媒体计算机系统体系结构

摘要

本发明涉及具有QOS保证的可缩放多媒体计算机系统体系结构。描述了各种版本的多媒体计算机系统体系结构，这些多媒体计算机系统体系结构满足对诸如游戏应用之类的多媒体应用的服务质量(QoS)保证，同时允许平台资源，尤其是硬件资源，随时间放大或缩小。将计算机系统的计算资源划分成平台分区和应用分区，每一分区都包括其自己的中央处理单元(CPU)和可选的图形处理单元(GPU)。为了改善资源的放大或缩小，平台分区包括只能被多媒体应用通过软件接口访问的一个或多个硬件资源。另外，在这些分区的外面可存在被这些分区共享或者提供通用计算资源的其他资源。

说明书

技术领域

本发明涉及多媒体计算机系统体系结构。

背景技术

通常向在多媒体计算机系统上执行的多媒体软件应用提供有关计算机系 统的诸如硬件、固件或软件组件之类的计算资源的分配的某种服务质量(QoS) 保证。这对游戏尤其成立。例如，可存在可用于每一个游戏的所分配的存储器 分配大小。多媒体计算机系统也可确保诸如游戏之类的应用的先前版本仍将运 行，所以Qos保证可存在很多年。

多媒体计算机系统，尤其是游戏控制台，现在一般提供作为其平台的服务 的一部分的常见功能。平台的示例是索尼的Playstation或任天堂 的常见功能是许多类型的游戏或其他应用使用的服务，或与这些应用 相兼容的服务。  常见的平台功能的一些示例是显示平面混合、显示输出记录、 视频编解码器编码、用户设备音乐解码和混音、基于自动相机的玩家标识等。 另外，平台服务可包括独立于多媒体应用但与多媒体应同时运行的功能。  由 于许多游戏和其他多媒体应用现在可通过因特网来进行交互，因此平台服务可 处理因特网协议消息，可提供在线聊天、朋友邀请、电子邮件，并可支持社交 联网服务。  平台和应用两者可使用共有的资源来执行它们相应的功能。

由于支持交互性游戏和其他多媒体内容的网络连接性的形式一直在进步， 并且应用的某些处理方面变成标准，因此随着时间的推移，平台为各种应用提 供了越来越多的服务，而仍服从针对这些多媒体应用的相同的Qos保证，由此 增加了对共享资源的争用。

发明内容

本技术为多媒体应用提供了满足服务质量(QoS)标准的多媒体计算机系 统体系结构，同时允许平台服务随时间而缩放的各种实施例。随时间而缩放可 允许新的服务或增强的当前服务。平台服务也可随着时间而缩小。

在用于根据一个或多个服务质量(QoS)保证来为正执行的多媒体应用提 供一致的性能的多媒体计算机系统的一实施例中，该系统包括计算资源的平台 分区、计算资源的应用分区和至少一个共享资源。平台分区包括含平台中央处 理单元(CPU)和平台图形处理单元(GPU)的计算资源。应用分区包括含应 用CPU和应用GPU的计算资源。在一些实施例中，应用处理单元执行除平台 服务应用的指令以外的处理。

在一些实施例中，系统还包括可被平台分区资源和应用分区资源访问的共 享资源。

在多媒体计算机系统的一些实施例中，为了增强对资源的放大或缩小，平 台分区包括对一个或多个平台服务应用和多媒体应用执行处理的一个或多个 资源，但是仅可多媒体应用可通过软件接口来访问该平台分区。

此外，一个或多个共享计算资源可包括可执行平台服务应用或多媒体软件 应用的指令的附加的CPU，以基于针对多媒体应用的一个或多个QoS保证来提 供多媒体应用的一致性能。在一些实施例中，附加的CPU可执行通用操作系统。

还提供了具有软件编码在其上的一个或多个计算机可读存储的实施例，该 软件在被处理器执行时，使得处理器执行一种用于在与一个或多个平台服务应 用同时执行的多媒体应用之间分配计算资源以基于一个或多个QoS保证来提 供多媒体应用的一致性能的方法。

提供本发明内容以便以简化的形式介绍将在以下具体实施方式中进一步 描述的一些概念。本发明内容并非旨在标识所要求保护的主题的关键特征或必 要特征，也不旨在用于帮助确定所要求保护的主题的范围。

附图说明

图1示出了具有用户参与到游戏中的目标识别、分析和跟踪系统的示例实 施例。

图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)中，多媒体应用在具有 较少或没有任何远程连接性的游戏控制台上执行。通常，应用本身具有用于 执行创建用户体验所需的所有任务的代码。

计算资源的平台提供了标准化构架来供多媒体应用开发者进行开发。计算 资源可以是硬件、固件、软件、或这些中的两个或多个的组合。由于为想要与 多媒体应用一起交互的远程用户开发了常规功能并开发了连接性需求，像 索尼的Playstation或任天堂的等较近批 次的多媒体控制台提供平台服务软件和其他平台服务应用，平台服务软件提供 在这些计算机系统上执行的所有多媒体应用的常规功能，而其他平台服务应用 独立于多媒体应用地运行服务。平台服务和多媒体应用常常同时执行。各应 用之间的资源的争用可引起削弱用户体验的降低的性能。

平台服务应用增强了用户的多媒体体验。平台服务应用不是操作系统或系 统管理程序的功能。如同多媒体应用一样，平台服务应用可与操作系统或系 统管理程序或系统软件一起工作。平台服务的示例是用于基于因特网的功能 (如，电子邮件、社交联网、即时消息收发和聊天)和对这些功能的显示(包 括现场语音聊天和现场视频共享)的因特网协议处理，诸如将数据打包在标准 消息格式中。常规功能的其他示例是维护用户简档以及呈现独立于特定多媒体 应用的菜单。将数据格式化成可被多媒体计算机系统所支持的所有应用使用的 格式。平台提供标准化界面，多媒体开发者通过该界面来编程他们的多媒体 应用。这种接口的一个示例是应用编程接口(API)。

为了确保多媒体应用随时间的生存能力并促进各种系列的多媒体应用，对 多媒体应用(尤其是对游戏控制台)的特征和性能的服务质量(QoS)保证在 多媒体计算机系统设计中实现。与如个人计算机和蜂窝电话等其他硬件设备 相比，这是所定义的多媒体控制台的高级特征中的一个。一般说来，确保在 已装的第一控制台上运行的多媒体应用的代码的相同版本能在以后用相同的 用户可辨别的性能在已装的最后控制台上运行例如4-10年。

QoS保证的一些示例涉及实时等待时间和带宽需求。例如，可确保存储 器读取在某一时窗内完成。在另一示例中，可确保对总线带宽的分配用于某 些数据传输。随着时间的推移，由于数据和处理工作的量的增加，多媒体应用 具有更多的存储器和带宽需求，以实时地提供越来越逼真的用户体验。此外， 平台提供新服务来支持新形式的连接性和社交网络，以增强用户体验，以及支 持使用它们来进行传输的数据的新带宽和等待时间需求。平台服务还提供新 的常规功能或改进当前功能的性能，以在用户体验中支持多媒体改进。

为了一般基于有关特征和性能(例如，带宽和等待时间)的QoS保证提供 多媒体应用随时间的一致性能，并允许平台服务缩放，可使用可减少争用并改 进性能的不同体系结构技术。例如，专用硬件可被分开地分配给硬件资源的平 台和应用资源，而它们在先前的系统中会经历非常高的并发利用率。在其他示 例中，诸如为了带宽和等待时间保证，某些硬件资源(如总线和存储器)可能 会被过度构建，这意味着资源具有超过对该资源的期望和保证使用的容量。这 个方法还为平台服务的扩展或保证中的改变提供了增长的缓冲。在其他示例 中，QoS软件根据用于在一个或多个平台服务应用之间分配资源的方法来执行， 且多媒体应用根据用于基于可应用的QoS保证来提供多媒体应用的一致性能 的标准来执行。

图1提供了当前技术在其中可能有用的上下文示例。图1示出了本技术的 各实施例可在其中操作的、其中用户正与正执行的多媒体应用进行交互的目标 识别、分析和跟踪系统的示例实施例。在这个示例中，控制台计算环境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.11b、802.11g、802.11a或802.11n连接等的无线连接。根据一个实 施例，控制台计算系统12可以通过通信链路436向捕捉设备20提供可用于确 定例如何时捕捉场景的时钟。附加地，捕捉设备20经由通信链路436将由例 如3-D相机426和/或RGB相机428捕捉的深度信息和视觉(例如RGB)图像 提供给控制台计算系统12。在一个实施例中，深度图像和视觉图像以每秒30 帧的速率来传送，但是可以使用其他帧速率。控制台计算系统12然后可以创 建模型并使用模型、深度信息、以及所捕捉的图像来例如控制诸如游戏或文字 处理程序等的应用和/或使化身或屏上人物动画化。

控制台计算系统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年1月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或两者可执行不同的 通用操作系统(例如，)，或提供由平台服务或这多媒体应用提供的 功能之外的附加的功能。例如，这些处理单元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具有一级(L1)高 速缓存305(1)和二级(L2)高速缓存305(2)和闪速ROM(只读存储器) 304。

多媒体控制台100还包括用于执行多媒体应用功能的应用CPU 304。CPU 304还可包括一个或多个处理核。在这个示例中，应用CPU 304具有一级高速 缓存303(1)和二级高速缓存303(2)和闪速ROM(只读存储器)342。

多媒体控制台100还包括平台图形处理单元(GPU)306和应用图形处理 单元(GPU)308。为了便于附图中的连接，这些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来调度用于将弹出框呈现在覆盖视频平面中的代码来创建的。覆盖 平面所使用的存储器量取决于覆盖区域大小，并且该覆盖图较佳地与屏幕分辨 率成比例缩放。在并发平台服务应用使用完整用户界面的情况下，优选使用独 立于应用分辨率的分辨率。定标器可用于设置该分辨率，从而消除了对改变频 率并引起TV重新同步的需求。

存储器控制器314促进处理器访问各种类型的存储器322，诸如但不限于， 一个或多个DRAM(动态随机存取存储器)通道。

多媒体控制台100包括较佳地在模块318上实现的I/O控制器348、系统 管理控制器325、音频处理单元323、网络接口控制器324、第一USB主控制 器349、第二USB控制器351和前面板I/O子部件350。USB控制器349和351 用作外围控制器352(1)-352(2)、无线适配器358、和外置存储器设备356(例如 闪存、外置CD/DVD ROM驱动器、记忆棒、可移动介质等)的主机。网络接 口324和/或无线适配器358提供对网络(例如，因特网、家庭网络等)的访问 并且可以是包括以太网设备、调制解调器、蓝牙模块、电缆调制解调器等的各 种不同的有线或无线适配器组件中任何一种。

提供系统存储器331来存储在引导过程期间加载的应用数据。提供媒体驱 动器360且其可包括DVD/CD驱动器、蓝光驱动器、硬盘驱动器、或其它可移 动媒体驱动器等。媒体驱动器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-1、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至图5B中示出的示例计算机系统包括计算机可读存储介质的示例。 这样的介质可包括以用于存储诸如计算机可读指令、数据结构、程序模块、或 其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移 动介质。计算机存储介质包括，但不限于，RAM、ROM、EEPROM、高速缓 存、闪存或其他存储器技术、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保证请求的预留存储器。

尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所 附权利要求书中定义的主题不必限于上述具体特征或动作。更确切而言，上述 具体特征和动作是作为实现权利要求的示例形式公开的。