Vulkan及OpenGL ES每秒的模型环境

用于PowerVR Rogue GPU的 Vulkan驱动程序已发布一段时间。自其发布以来,我们的PowerVR驱动及图像演示团队一直努力与标准规格保持同步,并使之发展为产品的最终形式。

今天,我们能将一直致力开发的全新演示版展示在您面前,着实非常兴奋。新的演示版对产品的优势进行了突出强调,这也是我们认为此API应该给开发人员和设备带来的优势。

Gnome Horde中的Vulkan与OpenGL ES使用对比

新演示版称为Gnome Horde,在Android环境下基于英特尔处理器的Nexus Player上运行。它是一款集成了PowerVR G6430 GPU的消费型设备,使用最新的用于PowerVR GPU的Vulkan API原型驱动器(最终性能可能有所差异)。

左边视频展示的是Vulkan,右边则是OpenGL® ES 3.0。我们尝试着让两个版本运行相同的代码,且二者的运行均没有扩展。演示版本均不使用实例,每个绘制调用可使用不同材料或结构的几何纹理,且其CPU性能将非常相似。

在继续浏览文章之前,请注意,这是谈到的是一个夸张的场景,目的是为了突出Vulkan的优势。但这并非从不利的角度来展示OpenGL ES——我们故意不使用OpenGL ES设计的方式。我们旨在使用Vulkan API来绑定GPU,这就意味着GPU和CPU的使用需尽可能有效。对于开发人员和厂商而言,这是一桩幸事。

实施细则

使用Vulkan时,我们将绘制调用分批处理为拼贴,并将拼贴同时呈现。每当拼贴淡出视图时,进入视图或改变命令缓冲区的细节层次(稍后详述)。相比OpenGL ES,我们通过避免命令缓冲区发生改变,大大降低了CPU的总体使用率。
详细阐释如下。

排列式成像

排列式成像

在OpenGL ES中,所有的绘制调用根据视图中的拼贴进行了动态提交,没有机会来缓存已经执行的调用。

较低的CPU使用率

正如你所见,左下端展示CPU使用情况的图片中,CPU在第一个模型的许多绘制调用中使用率非常低。在最高的缩放级别中,绘图为每秒400,000 gnomes(及其他对象)。每个对象有不同的变形,且有许多不同的材料、结构、混合模式和着色器被使用。

OpenGL ES API排斥这些任务的原因在于,OpenGL ES要求很多调用进入内核模式,以在应用程序进入循环使用时改变驱动器的状态并确认状态及幕后仍需进行的额外工作。

这与预生成这些命令的Vulkan形成鲜明对比。在Vulkan中执行预生成命令非常快速,且几乎没有CPU开销,也不需要驱动在渲染循环内确认或编译任何东西。这些预生成的命令被称为命令缓冲区。

用于Gnome Horde的Vulkan CPU使用率(左边)及OpenGL ES的CPU使用率(右边)

用于Gnome Horde的Vulkan CPU使用率(左边)及OpenGL ES的CPU使用率(右边)

较低的一条线指的是处理器CPU的使用率,上端的线表示系统CPU的使用率。两条线在Vulkan中都有所下降,这基于提交之前处理命令缓冲区的能力。

命令缓冲区的再次使用

经证明,能够再次使用命令缓冲区在某些情况下是非常有用的。这项功能虽非万能,但却可以在游戏及其他应用中对其大量使用。我们决议,在这个特定的实例中,再次使用每拼贴的命令缓冲区,这将降低CPU整体的使用率。

在两种API中绘图之前,驱动器需要编译一组GPU的执行命令,且除了验证这些命令,还需要做其他工作——所有工作应在启动GPU之前完成。使用OpenGL ES就需要在渲染循环过程中为每个绘制调用执行上述工作。而在Vulkan中,我们可以提前编译及确认命令单,随后使GPU执行这些预生成的命令。

Vulkan在运作: Gnome Horde演示截图

Vulkan在运作: Gnome Horde演示截图

这个截图含有300个拼贴,大约共有13500个绘图调用正以每帧30秒运行,CPU使用率非常低。这种方法每秒将近有50万个绘图调用。

并行命令缓冲区的产生

在接下来的演示模型中,注意观察CPU图。从该图可以看到,保持较低CPU使用率的同时,也几乎可以使用整个CPU的内核。这是因为,相机的移动速度非常快,因此需要再次频繁地生成命令缓冲区(有点不切实际的用例)。在OpenGL ES中,我们绑定了CPU,且GPU中没有足够的命令。然而在Vulkan中,则有机会将再次生成的拼贴命令缓冲区分配给不同的线程。OpenGL ES不可能具有此项功能,因为在多线程广泛应用之前,OpenGL ES便已设计成型。在现实的应用中,工作负荷通常介于动态绘图调用和静态绘图调用这两种极端的调用之间。

这种情况下,我们牺牲了CPU使用率,以换取内存使用率。我们可以在内存中储存整个场景的命令缓冲区。然而在移动设备中,由于内存量有限,我们仅可储存视见体的命令缓冲区。使用Vulkan时,便可以绑定GPU性能。这表示,我们可有效地使用CPU,且保证GPU具有足够的命令。

Vulkan CPU vs OpenGL ES CPU:注意OpenGL ES不能处理多线程

Vulkan CPU vs OpenGL ES CPU:注意OpenGL ES不能处理多线程

为保持等效性能,Vulkan演示版使CPU以更低的时钟频率运行,相比OpenGL ES,这大量提升了效率及电池的使用寿命。

在这个模式中,CPU内核之间大约每帧分配了80个再次生成的命令缓冲区。每个命令缓冲区有45个绘图调用及其它状态设置信息。若这些工作顺利进行,可以看到,帧速率与先前模式中的相同。

内存分配策略

相比OpenGL ES,使用Vulkan的一大优势在于,开发人员可以分配更多具有可见性的内存。使用OpenGL ES时,驱动器要处理大量的分配任务,且对于开发人员来说,这些任务通常是隐藏的。使用Vulkan时,驱动器分配的内存量非常小,开发人员可以使用不同的内存分配策略。例如,如果图像不是被GPU使用,则开发人员可以使用此内存来完成其它工作,如上传纹理数据。

渲染层——像素的本地存储

Vulkan中有一个结构被称为渲染层。每个渲染层有一个或更多的子层。可以对子层加以开发,利用像素的本地存储来储存子层之间的着色器。

作为基于拼贴的延迟渲染器,PowerVR可以使用快速片内存储有效地在FBO内为相同的像素执行多个着色器。渲染技术如延迟渲染是很好的方法。其优势在于,在给主内存编写中间值时可以避免浪费,并节省带宽及功率。然而,此功能对于OpenGL ES而言是一项扩展功能,需要编写更多的代码来确认是否扩展存在。

在Vulkan中,此功能则为核心的功能,有利于保持电池使用寿命及应用和设备的效率。Vulkan也允许驱动器通过使用延迟渲染和瞬态内存来处理内存不足的问题。

总结

上述所有的功能均要求实现代码,因此相比OpenGL ES,使用Vulkan不会增加代码的复杂性。不过,Imagination公司将在未来相当长的一段时间内全力支持OpenGL ES,同时为PowerVR Rogue GPU开发新的Vulkan API驱动器。

使用新款Vulkan API的设备将有机会优化,并可加大程序开发人员的使用效率。

如果你将参加本周举办的2015年SIGGRAPH会,请顺道参加周三举行的Khronos集团同行交流会。你将有机会现场观看演示版,并了解其下一步的工作。请关注博客,更多详细资讯将呈现给您!

原文链接:
http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-and-opengl-es

--电子创新网--
粤ICP备12070055号