一种用于预测GPU性能的方法和相应的计算机系统与流程

文档序号:12596787阅读:1031来源:国知局
一种用于预测GPU性能的方法和相应的计算机系统与流程

本发明大体上涉及计算机处理单元。具体地说,本发明涉及一种用于评估和预测并行处理单元性能的方法,尤其是涉及一种用于评估和预测图形处理单元(GPU)性能的方法以及相应的计算机系统。



背景技术:

GPU性能评估和预测对于芯片架构设计来说非常关键。芯片架构设计人员、片上系统(SOC)团队、市场团队、驱动器团队和游戏开发人员都需要快速准确识别GPU芯片中的瓶颈并且针对不同芯片配置和不同实际应用程序例如游戏台标志、典型游戏以及工作站迹线预测芯片性能。不同的利益相关者对GPU芯片有特定的要求。例如,GPU架构团队必须识别GPU瓶颈并且在IP(知识产权)设计之前评估针对新的架构特征的性能增益,SOC团队必须在芯片设计之前针对不同芯片配置评估性能和功率,市场团队必须在流片(Tapeout)之前评估性能和功率,而驱动器团队/游戏开发人员必须在流片之后识别瓶颈并且评估目标性能。

但是,尽管RTL(Register Transfer Level:寄存器传输级)和AM(Architecture Model:架构模型)能够针对简单测试准确地预测GPU性能,但是它对于针对实际应用程序(数百帧)评价性能来说太慢了(1帧花费大约1周时间)。

一些可用的方法能够针对实际应用程序预测性能,但是这些方法都不准确。这些可用的方法提供大于20%的预测误差,这不能满足GPU设计人员的要求。

例如,一种公知的评估方法基于下列假设:

(ⅰ)GPU流水线是完全平行的。实际上,出于各种原因,所述GPU流水线可能被阻塞。

(ⅱ)绘制(draw)时间等于由瓶颈区块(bottleneck block)所花费的区块时间。

(ⅲ)总的应用程序时间等于一个应用程序中所有绘制的总和。没有考虑引起流水线阻塞的表面内存同步和背景切换。

(ⅳ)基于所估计的应用程序时间和参考芯片所花费的时间来计算相对的评分。

该方法的主要问题在于,它不能准确预测GPU性能。在大多数情况下,所评估的分数与实际硅芯片分数之间的预测误差大于20%。即使在优化之后,仍然有大约10%的预测误差。

需要新的方法和相应的计算机系统来快速、准确地预测GPU性能(甚至是功率)并且评估GPU性能。



技术实现要素:

为了快速、准确地评估和预测GPU性能并且克服现有方法或者模型的缺陷,本发明的各个方面提供一种用于评估和预测GPU性能的方法以及相应的计算机系统,它们使用所捕获的性能计数器和芯片配置作为输入来识别GPU芯片中的瓶颈并且预测GPU性能。

根据本发明的一个方面,提供一种用于在设计阶段评估和预测GPU性能的方法,其包括:

-在有待评估的GPU芯片中运行一组测试应用程序;

-捕获一组标量性能计数器和向量性能计数器;

-基于所捕获的标量性能计数器和向量性能计数器针对不同芯片配置创建用于评估和预测GPU性能的模型;以及

-预测GPU芯片的性能分数并且识别GPU流水线中的瓶颈。

在一个方面,所述基于所捕获的标量性能计数器和向量性能计数器针对不同芯片配置创建用于评估和预测GPU性能的模型包括:

(ⅰ)在通过GPU流水线的多个区块执行绘制的时候,对GPU流水线中每个区块所花费的周期(cycle)进行模型化,其中,一个测试应用程序包括多个绘制;

(ⅱ)对每个绘制所花费的周期进行模型化,并且识别GPU芯片的不同层级中的瓶颈;

(ⅲ)通过累加一个指令缓存器中每个绘制所花费的周期来获得执行一个指令缓存器中的所有绘制所花费的总的绘制周期,其中,在运行所述测试应用程序时,测试应用程序的绘制存储在多个指令缓存器中;

(ⅳ)将所述执行一个指令缓存器中的所有绘制所花费的总的绘制周期关联到针对GPU芯片的每个指令缓存器的per-CMB周期;

(ⅴ)通过累加所述针对GPU芯片的每个指令缓存器的per-CMB周期来获得执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期;

(ⅵ)将所述执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期关联到针对在GPU芯片中运行的一个测试应用程序的per-Test周期;

(ⅶ)计算GPU芯片的性能分数。

根据本发明的一个方面,提供了一种用于在设计阶段评估和预测GPU性能的计算机系统,其中,所述计算机系统配置为实施根据本发明所述的方法。

根据本发明的另一个方面,提供了一种用于在设计阶段评估和预测GPU性能的计算机系统,其包括:

-用于在有待评估的GPU芯片中运行一组测试应用程序的装置;

-用于捕获一组标量性能计数器和向量性能计数器的装置;

-用于基于所捕获的标量性能计数器和向量性能计数器针对不同芯片配置创建用于评估和预测GPU性能的模型的装置;以及

-用于预测GPU芯片的性能分数并且评估GPU流水线中的瓶颈的装置。

在一个方面,所述用于基于所捕获的标量性能计数器和向量性能计数器针对不同芯片配置创建用于评估和预测GPU性能的模型的装置包括:

(ⅰ)用于在通过GPU流水线的多个区块执行绘制的时候对GPU流水线中每个区块所花费的周期进行模型化的机构,其中,一个测试应用程序包括多个绘制;

(ⅱ)用于对每个绘制所花费的周期进行模型化并且识别GPU芯片的不同层级中的瓶颈的机构;

(ⅲ)用于通过累加一个指令缓存器中每个绘制所花费的周期来获得执行一个指令缓存器中的所有绘制所花费的总的绘制周期的机构,其中,在运行所述测试应用程序时,测试应用程序的绘制存储在多个指令缓存器中;

(ⅳ)用于将所述执行一个指令缓存器中的所有绘制所花费的总的绘制周期关联到针对GPU芯片的每个指令缓存器的per-CMB周期的机构;

(ⅴ)用于通过累加所述针对GPU芯片的每个指令缓存器的per-CMB周期来获得执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期的机构;

(ⅵ)用于将所述执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期关联到针对在GPU芯片中运行的一个测试应用程序的per-Test周期的机构;

(ⅶ)用于计算GPU芯片的性能分数的机构。

根据本发明所述的用于在设计阶段评估和预测GPU性能的方法以及用于在设计阶段评估和预测GPU性能的计算机系统至少具有如下优点:(ⅰ)更加准确地预测针对不同芯片配置的性能;(ⅱ)预测 具有不同架构和特征的芯片配置;(ⅲ)预测非常接近真实芯片中的FPS(Frame Per Second:帧每秒)的FPS;(ⅳ)快速对所捕获的数据进行预处理。

结合附图在考虑下面的详细描述的情况下更好地理解本发明。对本领域技术人员来说,从下面的说明书中可以明确获知的是,通过图解说明用于实施本发明的最佳方式来示出和描述本发明的实施方式。如将会意识到的那样,本发明包括其他实施方式并且其某些细节包括很多改进方案和变形方案,它们都没有离开本发明的范围。相应地,附图和详细的说明书应该被认为是对实质的解释而并非限制。

附图说明

下面参考附图通过举例的方式(但并不限于此)阐述本发明,其中:

图1示出根据本发明的用于评估和预测GPU性能的方法的流程图。

图2示出根据本发明的用于评估和预测GPU性能的方法的一个步骤的流程图。

图3示出根据本发明的GPU流水线的一种实施方式。

图4示出根据本发明的GPU流水线的PA(Primitive Assembler:基本汇编编译器)接口的一种实施方式。

图5示出根据本发明的GPU流水线的一种示意性划分,其中,所述GPU流水线被分成前端流水线和后端流水线。

图6示出根据本发明的对绘制周期进行模型化的一种实施方式,其中,所述前端与所述后端没有重叠。

图7示出根据本发明的对绘制周期进行模型化的一种实施方式,其中,所述前端与所述后端有重叠。

图8示出用于将执行一个指令缓存器中的所有绘制所花费的总的绘制周期关联到针对GPU芯片的每个指令缓存器的per-CMB周期的一种示例。

图9示例性示出在实施本发明时GPU芯片中的不同层级。

在本说明书和附图中,附图标记的重复使用意在标示本发明的相同或相似的特征或元件。

具体实施方式

现在参考附图中所示的几个优选实施例来详细描述一些实施方式,以便更好地理解本发明。在下面的说明书中,许多具体细节都是用来提供对具体实施方式的完全理解。但是,对本领域技术人员来说显而易见的是,所述实施方式能够以不带有一些或全部具体细节的方式实施。在其他情况下,公知的步骤和/或结构并未进行详细阐述,以免不必要地造成具体实施方式难于理解。本领域技术人员能理解的是,本次讨论仅仅是对示例性实施方式的描述,其用意并不在于限制本发明在示例性结构中具体实施的较宽范围。

图1示例性示出根据本发明的用于在设计阶段评估和预测GPU性能的方法的流程图。如图1中所示,用于在设计阶段评估和预测GPU性能的方法10以简单的方式被示出并且包括多个步骤。首先,在步骤11中,在有待评估的GPU芯片中运行一组测试应用程序。然后,在步骤12中,在所述测试应用程序运行期间,捕获一组标量性能计数器和向量性能计数器。基于所捕获的标量性能计数器和向量性能计数器,随后在步骤13中,能够针对不同芯片配置创建用于评估和预测GPU性能的模型。所述模型使用所捕获的性能计数器和有待评估的GPU芯片的芯片配置作为输入来评估和预测GPU性能。最后,在步骤14中,测试人员可以预测GPU芯片的性能分数并且识别GPU流水线中的瓶颈。

例如,测试人员可以使用可用的工具来捕获数据文件,所述数据文件涵盖了从用户模型驱动器发送到内核模型驱动器的所有数据包。然后,测试人员可以在可用的GPU芯片上运行所述数据文件,以捕获所有要求的性能计数器,如Ttrace(Thread trace:线程迹线)、状态/背景等等。随后,为了使性能评估和预测加速,测试人员对所捕获的性能计数器进行预处理,以便创建具有csv(comma separated value:逗号隔开值)格式的所有需要的数据。最后,测试人员创建用于GPU性能评估和预测的模块,它使用所捕获的性能计数器和有待评估的GPU芯片的芯片配置作为输入来评估瓶颈并且预测GPU性能。

在一个方面,上述步骤13,即基于所捕获的标量性能计数器和向量性能计数器针对不同芯片配置创建用于评估和预测GPU性能的模型,可以包括多个子步骤131至137。图2示例性地示出用于在设计阶段评估和预测GPU性能的方法的步骤13的流程图,所述步骤13包括这些子步骤。如图2所示,在子步骤131中,测试人员在通过GPU流水线的多个区块执行绘制的时候对GPU流水线中每个区块所花费的周期进行模型化,其中,一个测试应用程序包括多个绘制。例如,针对GPU流水线的前端着色器,其包括VS(Vertex Shader:顶点着色器)、GS(Geometry Shader:几何着色器)、LS(Local Shader:局部着色器)、HS(Hull Shader:壳着色器)和DS(Domain Shader:域着色器),测试人员可以引入Ttrace数据(其是一种用在前端着色器中的向量性能计数器)以仿真延迟(latency)。然后,在子步骤132中,测试人员对每个绘制所花费的周期进行模型化,并且识别GPU芯片的不同层级中的瓶颈。在一个方面,测试人员基于多组参数对每个绘制所花费的周期进行模型化。更进一步,在子步骤133中,测试人员通过累加一个指令缓存器(CMB)中每个绘制所花费的周期来获得执行一个指令缓存器中的所有绘制所花费的总的绘制周期,其中,在运行所述测试应用程序时,测试应用程序的绘制存储在多个指令缓存器中。在GPU中,绝大多数绘制都是并行工作而非逐个工作。因此,一个指令缓存器中所有绘制所花费的累加的时间不能真正代表GPU性能。随 后,在子步骤134中,测试人员需要将所述执行一个指令缓存器中的所有绘制所花费的总的绘制周期关联到或者映射到针对GPU芯片的每个指令缓存器的per-CMB周期。在所述子步骤134中,将会考虑表面内存同步和背景切换。基于所述针对GPU芯片的每个指令缓存器的per-CMB周期,在子步骤135中,测试人员可以通过累加所述针对GPU芯片的每个指令缓存器的per-CMB周期来获得执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期。类似于子步骤134,在子步骤136中,测试人员可以进一步将所述执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期关联到或者映射到针对在GPU芯片中运行的一个测试应用程序的per-Test周期。然后,测试人员获得在GPU芯片中运行的一个测试应用程序所花费的总时间。在子步骤136中,将会考虑了显示器和CPU开支。最后,在子步骤137中,测试人员可以基于针对在GPU芯片中运行的一个测试应用程序的总的per-Test周期计算GPU芯片的性能分数。在一个方面,测试人员计算相对于参考芯片的性能分数。对于本领域技术人员来说,显而易见的是,测试人员可以通过运行不同的测试应用程序来获得GPU芯片的性能分数。根据性能分数和GPU芯片不同层级中的瓶颈识别,设计人员可以完成并且优化GPU的架构设计以满足GPU芯片的特定要求。

下面的段落将详细描述上述各个子步骤中的每一个子步骤。

为了在设计阶段评估和预测GPU性能,针对GPU流水线的每个区块(即在GPU的区块层级中),测试人员可以基于下列项中的至少一项来创建参数周期模型:(ⅰ)性能计数器和寄存器状态;(ⅱ)Ttrace,其是主要在前端着色器中用来描述针对每个着色器类型和波阵面(wavefront)的延迟的向量性能计数器;以及(ⅲ)有待评估的GPU的芯片配置参数。这些芯片配置参数必须在GPU芯片设计中加以限定并且能够在GPU芯片设计期间根据特定要求加以调整。

图3示出根据本发明的GPU流水线的一种实施方式。通常,GPU流水线包含固定功能区块、前端着色器、后端着色器和内存区块等等。

如图3中示例性所示,GPU流水线30包括固定功能区块、前端着色器310、后端着色器311和MC(Memory Controller:内存控制器)312,其中,所述固定功能区块包含CP(Command Parser:指令解析器)301、VGT(Vertex,Geometry and Tessellation:顶点、几何和细分)302、PA(Primitive Assembler)303、SC(Scan Convertor:扫描变换器)304、DB(Depth Block:深度区块)305、CB(Color Block:颜色区块)306、TA/TD(Texture Addressing/Texture Data:纹理寻址/纹理数据)307、TCP(Texture Cache per Pipe:每个管道的纹理高速缓存)308和TCC(Texture Cache per Channel:每个频道的纹理高速缓存)309。在一种实施方式中,基于性能计数器、寄存器状态和芯片配置参数,可以将针对固定功能区块的参数周期模型模型化成:Cycle_block=F(Peak_rate,Sclk,…)。由此可见,在本实施方式中,所述区块所花费的周期被表示为至少Peak_rate和Sclk的函数。

在这里,测试人员将PA作为示例来解释如何创建针对PA的参数周期模型,其中,PA主要充当顶点剪辑/筛选和边缘等式设定。

图4示出根据本发明的GPU流水线的PA接口403的一种实施方式。如图4中所示,PA包括PA剪辑/筛选(PA Clip/Cull)313和PA设定(PA Setup)323,并且利用多个区块例如VGT 302、SX 314和SC 304来连接。在PA中,测试人员可以捕获多个性能计数器,例如:(ⅰ)PA输入图元的数量;(ⅱ)PA至SX请求的数量;(ⅲ)PA至SC图元的数量;(ⅳ)针对不同剪辑平面的PA剪辑/筛选的图元的数量;(ⅴ)PA设定输入图元的数量;(ⅵ)PA输出图元的数量。同时,在PA中使用的芯片配置参数包含:(ⅰ)SE的数量;(ⅱ)从VGT输入PA的峰值比例(rate);(ⅲ)PA输出到SC的峰值比例; (ⅳ)PA输出到SX的峰值比例;(ⅴ)针对PA剪辑/筛选/设定模块的峰值比例;(ⅵ)Sclk:PA引擎时钟;(ⅶ)由针对不同剪辑平面的PA剪辑算法所花费的周期。

基于上述性能计数器和芯片配置参数,测试人员可以计算在图4中所示的由该接口和PA内部模块处理单元所花费的周期。由PA所花费的周期可以通过获取由所有接口和相关区块所花费的最大周期来得到。总的来说,针对PA的周期模型可以描述为:Cycle_PA=F(se_num,vgt_pa_peak_rate,pa_sx_peak_rate,pa_sc_peak_rate,pa_clip_rate,pa_cull_rate,pa_setup_rate,sclk…)。

返回到图3,前端着色器310也被包含在GPU流水线30中。所述前端着色器310可以至少包含:VS(Vertex Shader)、ES(Export Shader:输出着色器)、GS(Geometry Shader)、LS(Local Shader)和HS(Hull Shader)。所有这些着色器都能在通用计算单元中以并行的方式运行。如果测试人员仅仅捕获指令数量、指令发出时间和波数,难以仅仅使用这些性能计数器来准确地对前端着色器延迟进行模型化。根据本发明,提出了一种新的方法来通过使用被称为Ttrace的向量性能计数器来对前端着色器延迟进行模型化。所述Ttrace记录了对每个波的处理,包括开始时间和结束时间,其中,每个绘制包含多个波。Ttrace可以与上面提到的标量性能计数器一起使用以创建参数周期模型,可以将其描述为:Cycle_FE=F(Wave_num,CU_num,SE_num,Sclk,Mclk,…)。由此可见,在本实施方式中,所述前端着色器310所花费的周期被表示为至少Wave_num、CU_num、SE_num、Sclk和Mclk的函数。

在图3中,后端着色器311也被包含在GPU流水线30中。在一种实施方式中,后端着色器311通常是指PS(Pixel Shader:像素着色器)。在PS中,测试人员可以从GPU芯片中捕获多个性能计数器,例如:(ⅰ)不同指令类型如Vmem、Smem、Valu、Salu、LDS、GDS等等的数量;(ⅱ)不同指令类型的发出周期;(ⅲ)PS波阵面的数 量;(ⅳ)指令高速缓存命中率;(ⅴ)数据高速缓存命中率;(ⅵ)针对不同组的参数的内存延迟。同时,相应的芯片配置参数包含:(ⅰ)SE的数量;(ⅱ)CU的数量;(ⅲ)SIMD的数量;(ⅳ)Sclk。因此,在一种实施方式中,测试人员可以将针对PS的参数周期模型创建为:Cycle_PS=F(se_num,cu_num,simd_num,sclk…)。

在图3中,MC312也被包含在GPU流水线30中。在一种实施方式中,可以通过使用内存相关的性能计数器和内存相关的芯片配置来对MC312所花费的周期进行模型化。所述内存相关的性能计数器包括:(ⅰ)读请求;(ⅱ)写请求;(ⅲ)存储体非隐藏预充周期;(ⅳ)存储体非隐藏激活周期;(ⅴ)读转向写的内存等待周期;(ⅵ)写转向读的内存等待周期。同时,相应的芯片配置参数包括:(ⅰ)内存通道;(ⅱ)内存带宽;(ⅲ)Mclk:内存时钟;(ⅳ)Sclk:引擎时钟;(ⅴ)内存管脚比例(Memory pin rate)。因此,在一种实施方式中,测试人员可以将针对MC的参数周期模型创建为:Cycle_Mem=F(mem_channel,mem_bandwidth,mclk,sclk,mem_pinrate…)。通过这种方式,测试人员可以使用所创建的模型来计算针对不同芯片配置的区块周期。

对于本领域技术人员来说,公知的是,GPU流水线很长,这不同于CPU。在一种实施方式中,为了准确地对绘制周期进行模型化,测试人员首先将GPU流水线分成前端流水线和后端流水线。

图5示出GPU流水线的一种示意性划分,其中,所述GPU流水线被分成前端流水线51和后端流水线52。如图5所示,所述前端流水线51包含多个模块,包括CP、VGT、SPI、用于VS/ES/GS/LS/HS/DS着色器的CU(包括SQ、SQC、SP、LDS)、PA、TA-FE、TD-FE、TCP-FE、TCC-FE、MCS-FE等等。基于不同组的参数,CU模块可以被进一步分成FE_VSPS、FE_ESGSVSPS、FE_LSHSDSPS、FE_LSHSESGSVSPS等等。所述后端流水线52包含多个模块,包括SC、CU PS、内存后端(Memory Back End)、DB、 CB、PS、TA-BE、TD-BE、TCP-BE、TCC-BE、MC-Client、MCS-BE等等。在一种实施方式中,针对仅CS绘制,GPU流水线只包含CP、用于CS的CU、MCS、MC-Client等等。

在通过GPU流水线的多个区块执行绘制的时候,前端流水线51所花费的时间(周期)可以被描述为:Bottleneck_FE=Max(Block_time[0],Block_time[1],…,Block_time[FE_Block_num-1]),其中,FE_Block_num-1代表了所述前端流水线51中所包含的区块的数量,后端流水线52所花费的时间(周期)可以被描述为:Bottleneck_BE=Max(Block_time[0],Block_time[1],…,Block_time[BE_Block_num-1]),其中,BE_Block_num-1代表了所述后端流水线52中所包含的区块的数量。如从上述等式中可以看到的那样,前端流水线51所花费的时间(周期)等于前端流水线51中区块所花费的最大周期,后端流水线52所花费的时间(周期)等于后端流水线52中区块所花费的最大周期。

在一种实施方式中,测试人员可以使用向量性能计数器如Ttrace与上面提到的性能计数器一起来对绘制时序进行模型化。所述向量性能计数器能够针对CU中运行的每个波记录开始时间和结束时间,这非常有助于对前端着色器的时序进行模型化。在一种实施方式中,Ttrace代表了主要在所述前端着色器中用来描述针对每个着色器类型和波阵面的延迟的向量性能计数器,并且Ttrace记录了对每个波的处理,其包括开始时间和结束时间。

基于向量性能计数器,测试人员可以首先导出下列变量:

(ⅰ)vs_vs1_ratio=vs_latency/vs_1st_wave_latency;

(ⅱ)front_end_shader_time=ls_1st_wave_latency

+hs_1st_wave_latency

+es_1st_wave_latency

+gs_1st_wave_latency

+vs_latency;

(ⅲ)fe_draw_ratio=front_end_shader_time/total_draw_ttrace_latency;

(ⅳ)out_perf_ratio=(Bottleneck_FE+Bottleneck_BE)/total_draw_ttrace_latency;

(ⅴ)febe_ratio=(Bottleneck_FE+Bottleneck_BE)/perDraw_logged_cycles.

在上述等式中,vs_vs1_ratio代表了vs_latency与vs_1st_wave_latency的比率(ratio),vs_latency代表了vertex shader wave(顶点着色器波)的延迟,vs_1st_wave_latency代表了第一个vertex shader wave的延迟,ls_1st_wave_latency代表了第一个local shader wave的延迟,hs_1st_wave_latency代表了第一个hull shader wave的延迟,es_1st_wave_latency代表了第一个export shader wave的延迟,gs_1st_wave_latency代表了第一个geometry shader wave的延迟。

基于每个绘制的不同组的参数,测试人员能够以如下方式对绘制周期进行模型化:

如果所述前端51与所述后端52没有重叠(如图6所示),那么在满足下列条件之一的情况下将运用等式Time_perdraw=Bottleneck_FE+Bottleneck_BE来计算通过GPU流水线所执行的每个绘制所花费的时间:

(ⅰ)每个SE(Shader Engine:着色器引擎)中前端着色器的波数小于2;

(ⅱ)vs_vs1_ratio<1.1;

(ⅲ)febe_ratio<1.1;

如果所述前端51与所述后端52有重叠(如图7所示),那么在满足下列条件之一的情况下将运用等式Time_perdraw=Max(Bottleneck_FE,Bottleneck_BE+FE_Fill_Latency)来计算通过GPU流水线所执行的每个绘制所花费的时间:

(ⅰ)vs_vs1_ratio>1.1和fe_draw_ratio>=0.9;

(ⅱ)fe_draw_ratio>0.9或者Bottleneck_BE>0.8*total_draw_ttrace_latency;

如果未满足上述条件中的任一条件,那么能够从下列等式中导出per-draw时间(每次绘制时间):Time_perdraw=(Bottleneck_FE+Bottleneck_BE)/out_perf_ratio。

在GPU流水线中,每个区块能够以并行的方式工作。GPU流水线中的瓶颈是阻碍流水线并行工作或者使流水线搁置的区块。如果能够识别GPU流水线中的瓶颈,将会有助于评估和预测GPU性能。

在测试人员使用参数周期模型来预测针对限定在GPU芯片内的每个区块的周期之后,他能够将所述瓶颈识别为GPU流水线中具有最大周期的区块。因此,假设所述GPU流水线由n个区块组成,那么针对瓶颈区块的周期将会是:Bottleneck_time=Max(block_0,block_1,block_2,…,block_n-1)。在一种实施方式中,针对每个应用程序,测试人员能够对GPU流水线中的前五个瓶颈进行数据统计,其从一个方面反映了GPU性能。

基于每个绘制所花费的周期,测试人员能够通过累加一个指令缓存器中每个绘制所花费的周期来获得执行一个指令缓存器中的所有绘制所花费的总的绘制周期,其中,在运行所述测试应用程序时,测试应用程序的绘制存储在多个指令缓存器中。

在一种实施方式中,测试人员获得针对一个指令缓存器中的每个绘制的时间或周期Time_draw[cmb_id][draw_id],因此,测试人员能够通过如下方式导出执行一个指令缓存器中的所有绘制所花费的总时间:

<mrow> <mi>S</mi> <mi>u</mi> <mi>m</mi> <mo>_</mo> <mi>p</mi> <mi>e</mi> <mi>r</mi> <mi>c</mi> <mi>m</mi> <mi>b</mi> <mo>&lsqb;</mo> <mi>c</mi> <mi>m</mi> <mi>b</mi> <mo>_</mo> <mi>i</mi> <mi>d</mi> <mo>&rsqb;</mo> <munderover> <mo>&Sigma;</mo> <mn>0</mn> <mrow> <mi>d</mi> <mi>r</mi> <mi>a</mi> <mi>w</mi> <mo>_</mo> <mi>n</mi> <mi>u</mi> <mi>m</mi> <mo>-</mo> <mn>1</mn> </mrow> </munderover> <mrow> <mi>T</mi> <mi>i</mi> <mi>m</mi> <mi>e</mi> <mo>_</mo> <mi>p</mi> <mi>e</mi> <mi>r</mi> <mi>d</mi> <mi>r</mi> <mi>a</mi> <mi>w</mi> <mo>&lsqb;</mo> <mi>c</mi> <mi>m</mi> <mi>b</mi> <mo>_</mo> <mi>i</mi> <mi>d</mi> <mo>&rsqb;</mo> <mo>&lsqb;</mo> <mi>d</mi> <mi>r</mi> <mi>a</mi> <mi>w</mi> <mo>_</mo> <mi>i</mi> <mi>d</mi> <mo>&rsqb;</mo> </mrow> </mrow>

,其中,Time_perdraw[cmb_id][draw_id]代表了一个指令缓存器中每个绘制所花费的时间或者周期,draw_num代表了一个指令缓存器中绘制的数量,cmb_id代表了一个指令缓存器的标识。

由于在GPU中绝大多数绘制都是并行工作而非逐个工作的,所以一个应用程序中所有绘制的相加时间不能真正代表GPU性能。GPU通过指令缓存器和多个背景为并行工作提供支持。在每个指令缓 存器中,多个绘制(高达1000个)以批量的方式供给GPU。因此,测试人员需要将总的per-draw时间映射成总的per-CMB时间。映射函数可以被称为per-draw至per-CMB关联性。将执行一个指令缓存器中的所有绘制所花费的总的绘制周期关联到或者映射到针对GPU芯片的每个指令缓存器的per-CMB周期的一个示例在图8中示出。Per-CMB关联性将一个指令缓存器中的总的绘制周期映射到per-CMB周期中。

图8图解式示出执行一个指令缓存器中的所有绘制所花费的总的绘制周期到针对GPU芯片的每个指令缓存器的per-CMB周期的关联或者映射。如图8的上半部分所示,五个绘制Draw-0、Draw-1、Draw-2、Draw-3和Draw-4图解式存储在GPU的一个指令缓存器中。相应地,执行该指令缓存器中的这五个绘制所花费的总的绘制周期等于逐个执行这五个绘制所花费的总时间,其可以通过累加这五个绘制中的每个绘制所花费的周期来获得。由于GPU以并行的方式处理数据,而不是以串行的方式处理数据,所以执行这五个绘制所花费的总的累加的绘制周期不能真正反映GPU的真实性能。如图8的下半部分所示,五个绘制Draw-0、Draw-1、Draw-2、Draw-3和Draw-4实际上以并行的方式执行。就这点而言,为了计算在GPU中执行这五个绘制所花费的真实时间,需要将执行这个指令缓存器中的所有这五个绘制所花费的总的绘制周期关联或者映射成针对这个指令缓存器的per-CMB周期,其可以由per-CMB关联来实现。

在一种实施方式中,将执行一个指令缓存器中的所有绘制所花费的总的绘制周期关联到或者映射到针对GPU芯片的每个指令缓存器的per-CMB周期通过使用映射函数来实现。为了得到所述映射函数,测试人员不得不进行标定(calibration)以导出所述映射函数的函数参数。在参考芯片中,针对不同的sclk、mclk和不同的芯片配置,测试人员转存针对每个绘制的per-draw周期和针对每个指令缓存器的per-CMB周期。利用这些数据,测试人员可以建立一组等式以求解映射函数的函数参数。

在一种实施方式中,所述执行一个指令缓存器中的所有绘制所花费的总的绘制周期到针对GPU芯片的每个指令缓存器的per-CMB周期的关联或者映射通过使用差来实现。对本领域技术人员来说,公知的是,一个指令缓存器中所有绘制的相加的时间与真实测量的per-CMB时间之间存在差异,所述差异是:Delta_cmb[cmb_id]=(Logged_cycles_percmb[cmb_id]–Logged_cycles_perDraw[cmb_id])*Ratio[cmb_id],其中,Ratio[cmb_id]=Sum_percmb[cmb_id]/Logged_cycles_perDraw[cmb_id],Delta_cmb[cmb_id]代表了所述执行一个指令缓存器中的所有绘制所花费的总的绘制周期与所述针对GPU芯片的每个指令缓存器的真实测量的per-CMB周期之间的差,Logged_cycles_percmb[cmb_id]代表了记录在GPU内存中的per-CMB周期,Logged_cycles_perDraw[cmb_id]代表了记录在GPU内存中的per-Draw周期,其中,Logged_cycles_percmb[cmb_id]和Logged_cycles_perDraw[cmb_id]在参考芯片中测得。

Delta_cmb[cmb_id]依赖于sclk和mclk,因此测试人员可以通过使用不同的sclk和mclk来捕获参考芯片中的Delta_cmb[cmb_id],然后将它们插入(interpolate)以获得针对所预测的芯片配置的理想的值。Delta_cmb[cmb_id]的依赖性可以描述为:Delta_cmb(chip_config,sclk,mclk)=Function(Delta_cmb[cmb_id],mclk,sclk)。

因此,在测试人员得到Sum_percmb[cmb_id]之后,测试人员可以进行关联以得到一个指令缓存器的per-CMB相加的时间如下:Sum_percmb_correlated=Sum_percmb[cmb_id]–Delta_cmb[cmb_id]。

基于所述针对GPU芯片的每个指令缓存器的per-CMB周期,测试人员可以通过累加所述针对GPU芯片的每个指令缓存器的per-CMB周期来获得执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期。在一种实施方式中,所述通过累加所述针对GPU芯片的每个指令缓存器的per-CMB周期来获得执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期包括:通过使用下列等式来计算所述执行一个测试 应用程序的存储在有待评估的GPU芯片的多个指令缓存器中的所有绘制所花费的总的per-CMB周期:

<mrow> <mi>S</mi> <mi>u</mi> <mi>m</mi> <mo>_</mo> <mi>t</mi> <mi>i</mi> <mi>m</mi> <mi>e</mi> <mo>_</mo> <mi>p</mi> <mi>e</mi> <mi>r</mi> <mi>t</mi> <mi>e</mi> <mi>s</mi> <mi>t</mi> <mo>=</mo> <munderover> <mo>&Sigma;</mo> <mn>0</mn> <mrow> <mi>c</mi> <mi>m</mi> <mi>b</mi> <mo>_</mo> <mi>n</mi> <mi>u</mi> <mi>m</mi> <mo>-</mo> <mn>1</mn> </mrow> </munderover> <mrow> <mi>S</mi> <mi>u</mi> <mi>m</mi> <mo>_</mo> <mi>p</mi> <mi>e</mi> <mi>r</mi> <mi>c</mi> <mi>m</mi> <mi>b</mi> <mo>_</mo> <mi>c</mi> <mi>o</mi> <mi>r</mi> <mi>r</mi> <mi>e</mi> <mi>l</mi> <mi>a</mi> <mi>t</mi> <mi>e</mi> <mi>d</mi> <mo>&lsqb;</mo> <mi>c</mi> <mi>m</mi> <mi>b</mi> <mo>_</mo> <mi>i</mi> <mi>d</mi> <mo>&rsqb;</mo> </mrow> </mrow>

其中,cmb_num代表了在执行一个测试应用程序期间所用到的指令缓存器的总数量,Sum_time_pertest代表了针对在有待评估的GPU芯片中的运行的一个测试应用程序的总的per-Test周期。

鉴于GPU的并行工作,测试人员需要进一步将执行GPU的所有指令缓存器中的绘制所花费的总的per-CMB周期关联到针对在GPU芯片中运行的一个测试应用程序的per-Test周期。

在per-Test周期关联中,测试人员可以类似地进行从per-CMB周期到per-Test周期的关联或者映射。这种方式类似于从per-Draw到per-CMB的关联。但是,它主要考虑CPU和显示器对GPU芯片中的应用程序的性能的影响。

在一种实施方式中,将所述执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期关联到针对在GPU芯片中运行的一个测试应用程序的per-Test周期以类似于将所述执行一个指令缓存器中的所有绘制所花费的总的绘制周期关联到针对GPU芯片的每个指令缓存器的per-CMB周期的方式来实现。例如,将所述执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期关联到针对在GPU芯片中运行的一个测试应用程序的per-Test周期通过使用相关的映射函数或者所述执行一个测试应用程序的存储在多个指令缓存器中的所有绘制所花费的总的per-CMB周期与所述针对在GPU芯片中运行的一个测试应用程序的per-Test周期之间的差来实现,其考虑了CPU和显示器对于GPU芯片中的应用程序性能的影响。

为了更好地理解本发明,图9示例性示出在实施本发明时GPU芯片中的不同层级。如图9中所示,测试应用程序在应用程序层 级中运行并且在帧层级中包含多个帧,例如N个帧(N是整数)。在一种实施方式中,测试应用程序包含数百个帧。每个帧作为由GPU处理的数据被分割并且存储在指令缓存器层级(command buffer level)内的多个指令缓存器中,例如M个指令缓存器(M是整数)中。帧可以在绘制层级中被分成多个绘制,并因此理论上至少一个绘制可以被分配并且存储在一个指令缓存器中,实际上,一个指令缓存器可以存储几千个绘制。在图9中,单个指令缓存器可以存储至少一千个绘制。在区块层级中,GPU包括多个区块,例如CP(Command Parser)、VGT(Vertex,Geometry and Tessellation)、SPI(Shader Processor Interface:着色器处理器接口)、CU(Compute Unit:计算单元)、PA(Primitive Assembler)、SC(Scan Convertor)、DB(Depth Block)、CB(Color Block)、TA/TD(Texture Addressing/Texture Data)、TCP/TCC(Texture Cache per Pipe/Texture Cache per Channel)和MC(Memory Controller),其中,GPU的多个区块并行处理一个测试应用程序的数据。

在获得针对在GPU芯片中运行的一个测试应用程序的per-Test周期之后,测试人员可以计算GPU芯片的性能分数。在一种实施方式中,测试人员首先以如下方式导出针对参考芯片的FPS(Frame PerSecond:帧每秒):

其中,Frame_num代表了包含在所述测试应用程序中用于评估的帧数,Sum_time_pertestref代表了在参考芯片中用于评估的测试应用程序所花费的per-Test周期,sclkref代表了参考芯片的系统时钟频率。

在这种实施方式中,为了计算相对于参考芯片的性能分数,测试人员让由参考芯片所花费的周期为:Sum_time_pertestref,针对参考芯片的分数(Scoreref)为1.0。如果有待评估的芯片所花费的周期是

Sum_time_pertestchip的话(系统时钟频率是sclkchip),那么针对有待评估的芯片的分数(Scorechip)将会是:

其中,Sum_time_pertestchip代表了有待评估的芯片所花费的周期,sclkchip代表了系统时钟频率。就这点而言,针对有待评估的芯片的FPS将会是:

EPSchip=FPSref×Scorechip

如果测试人员可以精确测量参考芯片的FPS的话,对有待评估的芯片的FPS进行评估将会更加准确,并且通过下列等式来评估:

FPSchip=FPSref_measured×Scorechip

其中,FPSref_measured代表了参考芯片的所测得的FPS。FPSref_measured不同于FPSref,FPSref是基于系统时钟和所测量的perCMB GUI_ACTIVE性能计数器导出的。

测试人员提供GPU芯片的性能分数和GPU流水线中的瓶颈给GPU设计人员,从而设计人员可以在GPU芯片设计过程中根据具体的要求来调整芯片配置和架构。

同时,GPU流水线基本上对于不同代的芯片来说是相同的。但是,对于具有不同于参考芯片的配置参数的芯片来说,通常的情况是,可能添加了一些新的特征,更新了新的算法,或者更新了架构。为了实现针对这些情况的准确的性能预测,测试人员可以通过如下方式来予以支持:(ⅰ)首先更新区块周期模型以便仿真新的特征或者新的架构。由于大多数性能计数器都是与工作负荷相关的,所以它们不会随着芯片架构变化或者算法变化而变化。(ⅱ)基于新的架构或者算法,调整每个绘制周期模型来匹配架构变化。(ⅲ)使用相同的per-Draw到per-CMB关联和per-CMB到per-Test关联以导出新芯片中的周期。(ⅳ)评估新性能。使用上面所提到的方式,测试人员可以仿真一些新的特征,例如DCC、PC in L2、Attribute shading、Primitive Batch Binning等等。

多于130种真实的应用程序已经通过本发明被测试和验证过了,这些测试应用程序包含:(ⅰ)游戏台标志;(ⅱ)工作台迹线;(ⅲ)主流游戏。测试人员已经在不同芯片中验证了这些应用程序,部分结果显示如下:

从上述结果中可以看出,本发明的预测错误明显小于先前的方法的预测错误。

对本领域技术人员来说,显而易见的是,可以针对这里所描述的实施方式实现大量的改进方案和变形方案,而它们并未离开要求保护的主题的范围。因此,本说明书的用意在于,涵盖这里所描述的不同实施方式的改进方案和变形方案,只要所述改进方案和变形方案处于附加的权利要求和它们的等效方案的范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1