GPU性能瓶颈的确定方法、装置、终端及存储介质

摘要

本申请公开了一种GPU性能瓶颈的确定方法、装置、终端及存储介质，属于终端技术领域。所述方法包括：在目标应用程序运行过程中，获取预定时长内GPU的GPU运行频率；若GPU运行频率满足预设条件，则获取预定时长内GPU的GPU单帧渲染时长，GPU单帧渲染时长为单帧图像渲染过程中GPU的运行时长；根据GPU单帧渲染时长确定GPU是否达到性能瓶颈。本申请实施例中，终端基于GPU运行频率以及单帧图像渲染过程的GPU单帧渲染时长进行GPU性能瓶颈判断，无需借助驱动进行复杂的GPU负载计算，在保证GPU性能瓶颈检测准确性的同时，降低了性能瓶颈检测的复杂度，并提高了性能瓶颈检测效率。

说明书

技术领域

本申请实施例涉及终端技术领域，特别涉及一种GPU性能瓶颈的确定方法、装置、终端及存储介质。

背景技术

对于视频应用、游戏应用一类需要进行动态画面渲染的应用程序，其运行质量与图形处理器(Graphic Processor Unit，GPU)的性能密切相关。

相关技术中，为了实现GPU负载监控，终端中需要安装GPU对应的驱动，从而通过驱动计算GPU的实时负载，进而判断应用程序运行过程中GPU是否达到了性能瓶颈。

发明内容

本申请实施例提供了一种GPU性能瓶颈的确定方法、装置、终端及存储介质，可以用于解决相关技术中需要通过驱动计算GPU的实时负载，从而根据实时负载判断GPU是否达到性能瓶颈，导致性能瓶颈确定过程繁琐的问题，技术方案如下：

一方面，提供了一种GPU性能瓶颈的确定方法，所述方法包括：

在目标应用程序运行过程中，获取预定时长内GPU的GPU运行频率；

若所述GPU运行频率满足预设条件，则获取所述预定时长内所述GPU的GPU单帧渲染时长，所述GPU单帧渲染时长为单帧图像渲染过程中所述GPU的运行时长；

根据所述GPU单帧渲染时长确定所述GPU是否达到性能瓶颈。

另一方面，提供了一种GPU性能瓶颈的确定装置，所述装置包括：

第一获取模块，用于在目标应用程序运行过程中，获取预定时长内GPU的GPU运行频率；

第二获取模块，用于当所述GPU运行频率满足预设条件时，获取所述预定时长内所述GPU的GPU单帧渲染时长，所述GPU单帧渲染时长为单帧图像渲染过程中所述GPU的运行时长；

确定模块，用于根据所述GPU单帧渲染时长确定所述GPU是否达到性能瓶颈。

另一方面，提供了一种终端，所述终端包括处理器、与所述处理器相连的存储器，以及存储在所述存储器上的程序指令，所述处理器执行所述程序指令时实现如上述方面所述的GPU性能瓶颈的确定方法。

另一方面，提供了一种计算机可读存储介质，其上存储有程序指令，所述程序指令被处理器执行时实现如上述方面所述的GPU性能瓶颈的确定方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

通过获取预定时长内GPU的GPU运行频率，并在GPU运行频率满足预设条件时，进一步获取预定时长内GPU的GPU单帧渲染时长，从而根据GPU单帧渲染时长确定目标应用程序运行过程中GPU是否达到性能瓶颈；本申请实施例中，终端基于GPU运行频率以及单帧图像渲染过程的GPU单帧渲染时长进行GPU性能瓶颈判断，无需借助驱动进行复杂的GPU负载计算，在保证GPU性能瓶颈检测准确性的同时，降低了性能瓶颈检测的复杂度，提高了性能瓶颈检测的效率。

附图说明

图1是本申请一个示例性实施例所提供的终端的结构示意图；

图2是Android系统中图形显示过程的原理示意图；

图3是缓冲区四种状态的状态转换图；

图4示出了本申请一个示例性实施例提供的GPU性能瓶颈的确定方法的方法流程图；

图5示出了本申请另一个示例性实施例提供的GPU性能瓶颈的确定方法的方法流程图；

图6是入列过程开始时间点和结束时间点的分布示意图；

图7示出了本申请另一个示例性实施例提供的GPU性能瓶颈的确定方法的方法流程图；

图8示出了本申请另一个示例性实施例提供的GPU性能瓶颈的确定方法的方法流程图；

图9是本申请一个实施例提供的GPU性能瓶颈的确定装置的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。在本申请的描述中，需要说明的是，除非另有明确的规定和限定，术语“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

在对本申请实施例进行解释说明之前，首先对本申请实施例的应用场景进行说明。图1示出了本申请一个示例性实施例所提供的终端的结构示意图。

该终端100是安装有目标应用程序的电子设备。该目标应用程序可以是系统程序或者第三方应用程序。其中，第三方应用程序是除了用户和操作系统之外的第三方制作的应用程序。比如，该目标应用程序可以是游戏应用程序或视频播放应用程序。

可选的，该终端100中包括：处理器120和存储器140。

处理器120可以包括一个或者多个处理核心。处理器120利用各种接口和线路连接整个终端100内的各个部分，通过运行或执行存储在存储器140内的指令、程序、代码集或指令集，以及调用存储在存储器140内的数据，执行终端100的各种功能和处理数据。可选的，处理器120可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable LogicArray，PLA)中的至少一种硬件形式来实现。处理器120可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器120中，单独通过一块芯片进行实现。

存储器140可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory)。可选的，该存储器140包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器140可用于存储指令、程序、代码、代码集或指令集。存储器140可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等；存储数据区可存储下面各个方法实施例中涉及到的数据等。

本申请实施例中的终端120还包括显示屏160。可选的，显示屏160是触摸显示屏，用于接收用户使用手指、触摸笔等任何适合的物体在其上或附近的触摸操作，以及显示各个应用程序的用户界面。显示屏160通常设置在终端100的前面板，或者，同时设置在终端100的前面板和后面板。显示屏160可被设计成为全面屏、曲面屏或异型屏。显示屏160还可被设计成为全面屏与曲面屏的结合，异型屏与曲面屏的结合，本实施例对此不加以限定。

除此之外，本领域技术人员可以理解，上述附图所示出的终端100的结构并不构成对终端100的限定，终端可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。比如，终端100中还包括射频电路、输入单元、传感器、音频电路、无线保真(Wireless Fidelity，WiFi)模块、电源、蓝牙模块等部件，在此不再赘述。

为了便于理解，下面首先对终端中的图形显示系统进行说明，且下述实施例以安卓(Android)图形显示系统为例进行示意性说明。

如图2所示，显示屏21中显示的内容是从硬件帧缓冲区中读取，且读取的过程为：从硬件帧缓冲区的起始地址开始，按照从上往下，从左往右的顺序进行扫描，从而将扫描到的内容映射在显示屏上。

由于显示屏21中显示的内容需要不断更新，若在同一硬件帧缓冲区内进行读取和写入操作，将会导致显示屏21中同时显示多帧内容，因此，终端采用双缓冲机制，其中，双缓冲区中的一个缓冲区用于内容读取显示，而另一个缓冲区用于后台图形合成和写入。

示意性的，如图2所示，前缓冲区22为显示屏所要显示内容的帧缓冲区，后缓冲区23为用于合成下一帧图形的帧缓冲区。当前一帧显示完毕，后一帧写入完毕时，显示屏21即读取后缓冲区23中的内容，相应的，前缓冲区22中即进行下一帧图形的合成(前后缓冲区角色互换)。

SurfaceFlinger作为图形的合成者，用于对上层传递的多个图形(surface)进行合成，并提交到显示屏的硬件缓冲区中，供显示屏21读取显示。如图2所示，后缓冲区23中的内容由SurfaceFlinger对多个surface 24合成而成。其中，每个surface对应上层的一个窗口(window)，比如对话框、状态栏、活动(Activity)。

图形的传递以缓冲区(buffer)为载体，而surface则是对buffer的进一步封装。为了实现对surface中多个buffer的管理，如图3所示，surface内部提供了缓冲区队列(BufferQueue)，与上层和SurfaceFlinger形成生产者消费者模型。其中，上层为生产者(Producer)，SurfaceFlinger为消费者(Consumer)。

对于BufferQueue中的各个buffer，其包含空闲状态(Free)、出列状态(Dequeued)、入列状态(Queued)状态以及获取状态(Acquired)。其中，空闲状态下，buffer可以被上层使用；出列状态下，buffer正在被上层使用；入列状态下，buffer经过上层使用(绘制渲染完成)，等待被SurfaceFlinger合成；获取状态下，SurfaceFlinger正在根据buffer进行合成。并且，不同状态之间可以通过缓冲区出列(dequeueBuffer)和缓冲区入列(queueBuffer)操作进行转换，其转换过程如图3所示。

请参考图4，其示出了本申请一个示例性实施例提供的GPU性能瓶颈的确定方法的方法流程图。该方法可以包括如下步骤。

步骤401，在目标应用程序运行过程中，获取预定时长内GPU的GPU运行频率。

在一种可能的实施方式中，目标应用程序对GPU的性能需求高于其他应用程序对GPU的性能需求，且目标应用程序是终端根据已安装应用程序的应用程序类型确定，或者，目标应用程序由用户手动设置。

可选的，目标应用程序是需要进行动态画面渲染的应用程序，该应用程序可以是视频播放类应用程序，也可以是游戏类应用程序。比如，该目标应用程序包括虚拟现实应用程序、三维地图程序、军事仿真程序、第三人称射击游戏(Third-Personal Shooting Game，TPS)、第一人称射击游戏(First-person shooting game，FPS)、MOBA游戏、多人枪战类生存游戏中的任意一种。本申请并不对目标应用程序的具体类型进行限定。

由于目标应用程序运行过程中，GPU运行频率会不断发生变化，因此为了提高后续GPU性能瓶颈检测的准确性，在一种可能的实施方式中，在预定时长内，终端每隔预定时间间隔获取一次GPU运行频率，从而获取预定时长内的多个GPU运行频率。比如，该预定时长为10s，时间间隔为100ms。

对于同一目标应用程序，不同运行场景下对GPU的性能需求可能不同，比如，游戏应用程序中，游戏启动场景、游戏加载场景、游戏主界面场景下对GPU的性能需求低于游戏进行场景下对GPU的性能需求。因此，在一种可能的实施方式中，终端在目标应用程序运行至目标运行场景时，执行获取GPU运行频率的步骤。其中，目标运行场景的场景信息由目标应用程序通过与终端操作系统之间的数据通道传输。

步骤402，若GPU运行频率满足预设条件，则获取预定时长内GPU的GPU单帧渲染时长，GPU单帧渲染时长为单帧图像渲染过程中GPU的运行时长。

进一步的，终端检测获取到的GPU运行频率是否满足预设条件，若满足，则确定存在达到GPU性能瓶颈的概率，并执行获取预定时长内GPU的GPU单帧渲染时长的步骤；若不满足，则继续获取GPU运行频率。

可选的，该预设条件为GPU运行频率大于频率阈值。比如，该频率阈值为80％×GPU运行频率上限。

图像渲染由中央处理器(Central Processing Unit，CPU)和GPU共同完成，CPU和GPU共同渲染一帧图像的时间被称为单帧渲染时间，相应的，单帧图像渲染过程中GPU的运行时长即为GPU单帧渲染时长，单帧图像渲染过程中CPU的运行时长即为CPU单帧渲染时长。由于后续需要判断GPU是否到达性能瓶颈，因此终端仅获取GPU单帧渲染时长。

由于渲染不同画面所耗费时长存在差异，因此在一种可能的实施方式中，终端获取预定时长内各帧图像对应的GPU单帧渲染时长，或者，终端获取预定时长内指定图像帧对应的GPU单帧渲染时长。

步骤403，根据GPU单帧渲染时长确定GPU是否达到性能瓶颈。

渲染相同图像帧时，GPU单帧渲染时长越长，表明GPU的渲染速度越慢，相应的GPU的性能越差，在一种可能的实施方式中，终端检测GPU单帧渲染时长是否大于时长阈值，若大于，则确定GPU达到性能瓶颈，反之，确定GPU未达到性能瓶颈。

由于GPU运行频率以及GPU单帧渲染时长易于获取，因此相较于通过额外的驱动进行复杂的GPU负载计算，根据GPU的运行频率以及GPU单帧渲染时长确定GPU是否达到性能瓶颈的难度更低，并能够简化GPU性能瓶颈的检测流程，为后续开发和优化提供数据支持。

综上所述，本申请实施例中，通过获取预定时长内GPU的GPU运行频率，并在GPU运行频率满足预设条件时，进一步获取预定时长内GPU的GPU单帧渲染时长，从而根据GPU单帧渲染时长确定目标应用程序运行过程中GPU是否达到性能瓶颈；本申请实施例中，终端基于GPU运行频率以及单帧图像渲染过程的GPU单帧渲染时长进行GPU性能瓶颈判断，无需借助驱动进行复杂的GPU负载计算，在保证GPU性能瓶颈检测准确性的同时，降低了性能瓶颈检测的复杂度，提高了性能瓶颈检测的效率。

请参考图5，其示出了本申请另一个示例性实施例提供的GPU性能瓶颈的确定方法的方法流程图。该方法可以包括如下步骤。

步骤501，在目标应用程序运行过程中，获取预定时长内GPU的GPU运行频率。

本步骤的实施方式可以参考上述步骤401，本实施例在此不再赘述。

步骤502，根据GPU运行频率计算预定时长内GPU的平均运行频率。

由于GPU运行频率会不断发生变化，因此仅基于单一的GPU运行频率确定是否满足预设条件，将影响结果的准确性。在一种可能的实施方式中，终端获取到预定时长内不同时间点对应的GPU运行频率，从而根据多个GPU运行频率计算预定时长内GPU的平均运行频率。

在一个示意性的例子中，终端每隔1s采集一次CPU运行频率，从而获取到10s内的10个CPU运行频率，分别为1550MHz、1570MHz、1625MHz、1650MHz、1655MHz、1600MHz、1650MHz、1650MHz、1600MHz、1650MHz，并进一步计算得到平均运行频率为1620MHz。

需要说明的是，终端(操作系统)可以通过预设接口(比如devfreq)实时获取GPU工作频率，本申请实施例对获取GPU运行频率的方式不做限定。

步骤503，若平均运行频率大于频率阈值，则确定GPU运行频率满足预设条件，频率阈值小于GPU的运行频率上限。

当GPU满负荷运行时(负载大)，从频率上看，GPU运行频率趋近于GPU运行频率上限的，因此，本申请实施例中，终端检测预定时长内GPU的平均运行频率是否大于频率阈值，若大于，则确定GPU运行频率满足预设条件(可能达到GPU性能瓶颈)；若小于，则确定GPU运行频率不满足预设条件。

在一种可能的实施方式中，终端预先设置有运行频率比值上限，当GPU的平均运行频率/GPU最大运行频率大于该比值上限时，确定GPU运行频率满足预设条件。比如，该比值上限为0.8。

结合上述步骤中的示例，当频率阈值为0.8×运行频率上限，且运行频率上限制为2000MHz时，由于GPU的平均运行频率为1620MHz＞1600MHz，因此终端确定GPU运行频率满足预设条件。

在其他可能的实施方式中，对于终端获取到的多个连续GPU运行频率，终端检测GPU运行频率大于频率阈值的时长是否大于时长阈值，若大于，则确定GPU运行频率满足预设条件，若小于，则确定GPU运行频率不满足预设条件。即终端检测GPU的运行频率是否长时间趋近于GPU最大运行频率。

步骤504，若GPU运行频率满足预设条件，则获取预定时长内各次入列过程的开始时间点和结束时间点，入列过程是指将经过图像渲染的buffer放回BufferQueue的过程。

如图3所示，每一帧图像的都渲染需要经过出列(Dequeque)过程和入列(Enqueue)过程，其中，出列过程是指上层从BufferQueue中申请一个空闲buffer以进行渲染的过程(即图3中buffer由Free状态变为Dequeued状态的过程)，而入列过程则是指将将渲染得到的数据写入buffer并放回BufferQueue，等待SurfaceFlinger进行合成的过程(即图3中buffer由Dequeued状态变为Queued状态)。

并且，从执行主体来看，出列过程由CPU执行，且在出列过程中，CPU进测量view的宽高(即measure)、设置view的宽高位置(即layout)、创建显示列表并绘制(即draw)以及生成多边形及纹理，并将生成纹理和多边形发送至GPU；入列过程则由GPU执行，且在入列过程中，GPU对CPU生成的纹理以及多边形进行栅格化和合成(即进行图像渲染)，并将渲染得到的数据写入buffer中。

因此，基于图像帧的渲染过程，在一种可能的实施方式中，终端记录预定时长内各次入列过程的开始时间点以及结束时间点，以便后续基于开始时间点和结束时间点计算每次入列过程的时长。

可选的，入列过程的开始时间点为CPU向GPU发送多边形及纹理的时间点，而入列过程的结束时间点为经过图像渲染的buffer完成入列的时间点。

示意性的，图像渲染过程中，入列过程的开始时间点和结束时间点分布如图6所示。其中，每一帧图像绘制过程中，斜线填充部分为CPU运行时段(前半部是CPU进行测量、设置、纹理及多边形生成，后半部是CPU进行资源清理)，而黑色填充部分为GPU运行时段(根据CPU发送的纹理和多边形进行绘制)。

步骤505，根据开始时间点和结束时间点计算GPU单帧渲染时长。

由于图像渲染过程中，GPU的运行时间主要集中在入列过程，因此，终端可以根据每次入列过程的开始时间点以及结束时间点计算图像渲染过程中的GPU单帧渲染时长。在一种可能的实施方式中，本步骤可以包括如下步骤。

一、对于每次入列过程，计算开始时间点和结束时间点之间的第一时间间隔。

对于预定时长内的每次入列过程，终端计算开始时间点和结束时间点之间的第一时间间隔，该第一时间间隔即为入列时长的耗时。

并且，由于预定时长内包含多帧图像渲染，即包含多次入列过程，因此终端重复本步骤，得到多个第一时间间隔。

在一个示意性的例子中，终端计算得到10次入列过程对应的第一时间间隔，分别为：6ms、5ms、6ms、7ms、6ms、6ms、5ms、6ms、7ms、6ms。

二、将预定时长内各次入列过程对应第一时间间隔的平均值确定为GPU单帧渲染时长。

为了避免根据单个第一时间间隔确定GPU单帧渲染时长造成的结果不准确，本实施例中，终端计算预定时长内各次入列过程对应第一时间间隔的平均值，从而将该平均值确定为预定时长内GPU的GPU单帧渲染时长。

结合上述步骤中的示例，终端根据10次入列过程对应的第一时间间隔，计算得到平均值为6ms，从而将GPU单帧渲染时长确定为6ms。

需要说明的是，在其他可能的实施方式中，终端可以采用抽样的方式根据采样得到的若干个第一时间间隔确定GPU单帧渲染时长，本申请实施例对此不做限定。

步骤506，获取预定时长内的单帧渲染时长，单帧渲染时长为渲染单帧图像的时长。

图像渲染过程中，GPU满负荷运行时(负载大)的另一个表现是GPU运行时间所占比重增加，因此终端可以通过计算GPU单帧渲染时长占单帧图像总渲染时长的比例，确定GPU是否满负荷(达到性能瓶颈)。

在图5的基础上，如图7所示，本步骤还可以包括如下步骤。

步骤506A，获取预定时长内各次入列过程的开始时间点和结束时间点。

其中，获取入列过程的开始时间点和结束时间点的过程可以参考上述步骤504，本实施例在此不再赘述。

步骤506B，计算相邻两次入列过程的结束时间点之间的第二时间间隔。

由于每次图像渲染都包括入列过程，因此，终端可以根据相邻两次入列过程的结束时间点之间的时间间隔，或者，根据相邻两次入列过程的开始时间点之间的时间间隔，确定单帧图像渲染时长。

在一种可能的实施方式中，第二时间间隔＝第i+1结束时间点-第i结束时间点，i≥1，或者，第二时间间隔＝第i+1开始时间点-第i开始时间点，i≥1

示意性的，如图6所示，终端根据第2帧图像对应的结束时间点以及第1帧图像对应的结束时间点，计算得到第二时间间隔；根据第3帧图像对应的结束时间点以及第2帧图像对应的结束时间点，计算得到第二时间间隔，以此类推。

在一个示意性的例子中，终端计算得到10个第二时间间隔均为16ms。

在其他可能的实施方式中，由于每次图像渲染都包括出列过程，因此，终端还可以根据相邻两次出列过程的结束时间点之间的时间间隔，或者，根据相邻两次出列过程的开始时间点之间的时间间隔，确定单帧图像渲染时长，本实施例对此不做限定。

步骤506C，将预定时长内各个第二时间间隔的平均值确定为单帧渲染时长。

为了避免根据单个第二时间间隔确定单帧渲染时长造成的结果不准确，本实施例中，终端计算预定时长内各个第二时间间隔的平均值，从而将该平均值确定为预定时长内图像帧的单帧渲染时长。

结合上述步骤中的示例，由于计算得到的第二时间间隔均为16ms，因此，终端确定预定时长内的单帧渲染时长为16ms。

步骤507，根据GPU单帧渲染时长和单帧渲染时长确定GPU是否达到性能瓶颈。

进一步的，终端根据计算得到的GPU单帧渲染时长和单帧渲染时长，确定预定时长内GPU是否达到性能瓶颈。如图7所示，本步骤可以包括如下步骤。

步骤507A，计算GPU单帧渲染时长与单帧渲染时长的比值。

其中，比值＝GPU单帧渲染时长/单帧渲染时长。

结合上述步骤中的示例，当GPU单帧渲染时长为6ms，且单帧渲染时长为16ms时，该比值为6/16＝0.375。

进一步的，终端检测该比值是否大于预设数值，若大于，则确定图像渲染过程中GPU运行时间所占比重较大，即GPU达到性能瓶颈；若小于，则确定GPU未达到性能瓶颈。

步骤507B，若比值大于预设数值，则确定GPU达到性能瓶颈。

结合上述步骤中的示例，当预设比值为0.3时，由于0.375＞0.3，因此终端确定CPU达到性能瓶颈。

步骤507C，若比值小于预设数值，则确定GPU未达到性能瓶颈。

本实施例中，终端根据图像渲染中入列过程的开始时间点以及结束时间点，计算单帧图像的单帧渲染时长以及GPU单帧渲染时长，并进一步根据单帧渲染时长和GPU单帧渲染时长的比值确定GPU是否达到性能瓶颈，降低了检测过程中的计算复杂度，并保证检测结果的准确性。

在一种可能的实施方式中，当确定GPU达到性能瓶颈时，为了保证目标应用程序的画面显示质量，在图5的基础上，如图8所示，步骤507之后还包括如下步骤。

步骤508，若GPU达到性能瓶颈，则获取当前帧率。

针对获取当前帧率的方式，在一种可能的实施方式中，终端根据上述步骤中获取到的单帧渲染时长，计算当前帧率，其中当前帧率＝1s/单帧渲染时长。比如，当单帧渲染时长为16ms时，终端计算得到当前帧率为62fps。

进一步的，终端获取目标应用程序的目标帧率，并检测当前帧率是否达到目标帧率，若达到，则确定目标应用程序的画面未发生卡顿；若未达到，则确定目标应用程序的画面发生卡顿，并执行下述步骤509或510。

可选的，目标应用程序的目标帧率由终端操作系统通过与目标应用程序之间的数据通道获取。

步骤509，若当前帧率未达到目标应用程序的目标帧率，且平均运行频率小于GPU的运行频率上限，则上调GPU的运行参数。

在一种可能的实施方式中，当当前帧率未达到目标帧率时，终端获取平均运行频率(步骤502中计算得到)，并检测平均运行频率是否达到GPU的运行频率上限。若未达到，表明GPU的性能存在提升空间，终端则上调GPU的运行参数。比如，终端在平均运行频率的基础上，根据预定上调幅度逐步上调至运行频率上限，以提高GPU的渲染性能。

在一个示意性的例子中，GPU的平均运行频率为1620MHz，而GPU的运行频率上限为2000MHz，终端按照预定上调幅度50Mhz，在1620MHz的基础上逐步上调GPU的运行频率。

步骤510，若当前帧率未达到目标应用程序的目标帧率，且平均运行频率达到GPU的运行频率上限，则调整目标应用程序的图像质量。

当当前帧率未达到目标帧率时，且平均运行帧率已达到GPU的运行频率上限时，为了保证画面的显示质量，终端调整(比如下调)目标应用程序的图像质量，从而降低GPU的图像渲染难度。

本实施例中，终端检测到GPU到达性能瓶颈后，进一步判断画面是否发生卡顿，并在发生卡顿时，基于GPU的平均运行频率与运行频率上限，调整GPU的运行频率或者调整目标应用程序的画面质量，从而提高目标应用程序的画面显示质量。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

请参考图9，其示出了本申请一个实施例提供的GPU性能瓶颈的确定装置的结构示意图。该装置可以通过专用硬件电路，或者，软硬件的结合实现成为图1中的终端的全部或一部分，该装置包括：

第一获取模块910，用于在目标应用程序运行过程中，获取预定时长内GPU的GPU运行频率；

第二获取模块920，用于当所述GPU运行频率满足预设条件时，获取所述预定时长内所述GPU的GPU单帧渲染时长，所述GPU单帧渲染时长为单帧图像渲染过程中所述GPU的运行时长；

确定模块930，用于根据所述GPU单帧渲染时长确定所述GPU是否达到性能瓶颈。

可选的，所述第二获取模块920，包括：

第一获取单元，用于获取所述预定时长内各次入列过程的开始时间点和结束时间点，所述入列过程是指将经过图像渲染的缓冲区buffer放回缓冲区队列BufferQueue的过程；

第一计算单元，用于根据所述开始时间点和所述结束时间点计算所述GPU单帧渲染时长。

可选的，所述第一计算单元，用于：

对于每次入列过程，计算所述开始时间点和所述结束时间点之间的第一时间间隔；

将所述预定时长内各次入列过程对应所述第一时间间隔的平均值确定为所述GPU单帧渲染时长。

可选的，所述确定模块930，包括：

第二获取单元，用于获取所述预定时长内的单帧渲染时长，所述单帧渲染时长为渲染单帧图像的时长；

确定单元，用于根据所述GPU单帧渲染时长和所述单帧渲染时长确定所述GPU是否达到性能瓶颈。

可选的，第二获取单元，用于：

获取所述预定时长内各次入列过程的开始时间点和结束时间点，所述入列过程是指将经过图像渲染的buffer放回BufferQueue的过程；

计算相邻两次入列过程的所述结束时间点之间的第二时间间隔；

将所述预定时长内各个所述第二时间间隔的平均值确定为所述单帧渲染时长。

可选的，确定单元，用于：

计算所述GPU单帧渲染时长与所述单帧渲染时长的比值，所述比值＝所述GPU单帧渲染时长/所述单帧渲染时长；

若所述比值大于预设数值，则确定所述GPU达到性能瓶颈；

若所述比值小于所述预设数值，则确定所述GPU未达到性能瓶颈。

可选的，所述装置还包括：

第一检测模块，用于根据所述GPU运行频率计算所述预定时长内所述GPU的平均运行频率；若所述平均运行频率大于频率阈值，则确定所述GPU运行频率满足所述预设条件，所述频率阈值小于所述GPU的运行频率上限；

或者，

第二检测模块，用于若所述GPU运行频率大于所述频率阈值的时长大于时长阈值，则确定所述GPU运行频率满足所述预设条件。

可选的，所述装置还包括：

第三获取模块，用于若所述GPU达到性能瓶颈，则获取当前帧率；

第一调整模块，用于若所述当前帧率未达到所述目标应用程序的目标帧率，且所述平均运行频率小于所述GPU的运行频率上限，则上调所述GPU的运行参数；

第二调整模块，用于若所述当前帧率未达到所述目标应用程序的所述目标帧率，且所述平均运行频率达到所述GPU的运行频率上限，则调整所述目标应用程序的图像质量。

综上所述，本申请实施例中，通过获取预定时长内GPU的GPU运行频率，并在GPU运行频率满足预设条件时，进一步获取预定时长内GPU的GPU单帧渲染时长，从而根据GPU单帧渲染时长确定目标应用程序运行过程中GPU是否达到性能瓶颈；本申请实施例中，终端基于GPU运行频率以及单帧图像渲染过程的GPU单帧渲染时长进行GPU性能瓶颈判断，无需借助驱动进行复杂的GPU负载计算，在保证GPU性能瓶颈检测准确性的同时，降低了性能瓶颈检测的复杂度，提高了性能瓶颈检测的效率。

本实施例中，终端根据图像渲染中入列过程的开始时间点以及结束时间点，计算单帧图像的单帧渲染时长以及GPU单帧渲染时长，并进一步根据单帧渲染时长和GPU单帧渲染时长的比值确定GPU是否达到性能瓶颈，降低了检测过程中的计算复杂度，并保证检测结果的准确性。

本实施例中，终端检测到GPU到达性能瓶颈后，进一步判断画面是否发生卡顿，并在发生卡顿时，基于GPU的平均运行频率与运行频率上限，调整GPU的运行频率或者调整目标应用程序的画面质量，从而提高目标应用程序的画面显示质量。

需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本申请还提供一种计算机可读介质，其上存储有程序指令，程序指令被处理器执行时实现上述各个方法实施例提供的GPU性能瓶颈的确定方法。

本申请还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各个实施例所述的GPU性能瓶颈的确定方法。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的帧率控制方法中全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。