Vulkan:显示的操作和稳定的Frame Times(节选2)

续上篇

 Vulkan采用的是显示策略

Vulkan致力于为老式API面临的隐式操作模式问题提供一种显示操作的选择。不再会有任何隐式的依赖问题,内存分配完全靠应用程序来处理。API中所有模块都是显示机制的,只有这样的组合才会解决问题,任何孤立的一块都是无意义的。

 显示的内存分配

相比OpenGL ES,在Vulkan中资源的分配方法则更加的显示化。例如,如果想创建一幅图片并分配存储空间,如一下步骤:
1. 根据格式,大小等要求创建一个图片对象
2. 查询图片对象所需要的存储空间
3. 选取一块合适的内存空间/堆空间用于分配
4. 分配存储空间
5. 将此存储空间与图片对象绑定

以上步骤一点也不繁杂:例如你可以分配一块大的存储空间,然后将其分块与不同的资源进行绑定。像以往分配很多小的存储片区的方法对性能是有负面影响的。在一些平台上,你可以创建的存储空间片区数量是有限制的,否则会出现系统内存溢出等问题。

 显示的数据传输

与存储资源分配一样,实际的加载数据也是显示的。现在加载数据操作会根据直接的线性的存储空间(缓存,线性映射镜像)或者根据非线性的存储资源(器件优化后的镜像)空间映射的拷贝来执行。例如,如果想加载一个材质,以应该按一下操作步骤:
1.创建并绑定一块存储空间用于缓存
2.将此存储空间映射到CPU上
3.从磁盘读取材质数据,并存储刚映射的存储空间中
4.提交命令将材质数据从缓存中加载到图片对象上

如果你动态的去执行以上一系列操作,会有很多同步操作要处理,因为你对从机和主机的操作是完全异步的。如果你尝试从缓存中读取数据的同时又想往里面写数据,或者连续写入更多的数据,就要使用同步机制来进行协调,没有可能出现后台执行的操作——在Vulkan中数据的读写操作都是显示的。

 显示的依赖项和同步机制

几乎Vulkan的每一种操作都需要某种形式的同步。Vulkan不提供隐式的次序保证,也包括命令缓存中私有的一些命令。不同的架构的处理过程完全是不同的;TBDR(基于碎片的延迟渲染)型GPU在任何碎片处理器之前,执行完所有的定点处理操作,而IMR(立即型渲染)GPU会采用流水线一起执行所有操作。通过采用显示的声明,各个操作之间没有确定的执行次序,因此它能让应用程序的执行尽可能的快,同时可以根据用户要求,让用户请求确定的程序执行次序。

这与OpenGL ES是相反的,在OpenGL ES中可以假定任何事情都是有确定次序的,一个具体的应用实现不得不四处选择,才能实现优化效果。

对于CPU和GPU都是同样的,Vulkan能够让主机等待所有来自GPU的事件请求,以及能够直接触发GPU的一些事件。

 显示的提交结果

这是我最喜欢的话题!队列提交与命令模式相分开。由于很多原因我不能在此强调此API的这个特性是多么的重要,我也不能介绍更多的细节,因为在前期的文章中我已经介绍过了,再提一遍也没有多大帮助。Vulkan可以确保当你调用绘制函数时任何绘制相关的工作都将不会开始,只有这个调用操作被加入到命令缓存中后才会发生相关资源加载操作。
一旦你创建了命令缓存,当提交操作发生时你可以准确的控制将其提交到命令队列中。在加入命令队列之前GPU是不会启动任何工作的,应用程序可以收到显示的通知即GPU相关操作何时已经完成。

 显示的渲染打破限制

在OpenGL ES中有很多的隐式的刷新操作,尤其对于一些基于碎片的架构,存在此问题的原因是一个碎片只渲染了一半而发生了其他操作。Vulkan显示的限定了渲染过程的界限,借助这个信息,基于碎片型的GPU在就可以灵活的处理帧缓存空间中的过渡数据。

除了以上这个,Vulkan会禁止任何的内部操作,以防在渲染过程中引起刷新操作。这在实际应用中非常有用,它让应用开发者考虑当他们引入一个依赖项时他们想要做什么。更重要的是,它意味着对于一个应用来说碎片的加载和存储操作会有一个具体的点可依,所以基于碎片型的GPU会获取所有信息尽可能高效的处理过渡过程,而不是像在OpenGL ES中那样强制加载和存储所有东西。

这是一个相当宽泛的概述,除非你非常熟悉基于碎片型的架构GPU,否则你可能不能完全理解其中的意义。深入探讨此问题可能需要更多的篇幅——这个问题我将在此系列博客的终结篇中详细探讨,详细说明此API的渲染机制,以及其他架构上的优化和革新。

 结论

Vulkan提供很多显示操作机制,这些操作方法在OpenGL ES中还是隐藏的,或者是非常不合理的。但是这也是一把双刃剑:
• 一方面它允许应用更具表现力。反过来充分利用API会提升性能,这在以前老版本的API中是不可能的。
• 但是没有选择不这样做—它会强制应用去考虑怎么表现自己。这意味着如果一个应用执行错误操作,它们要么会由于没有正确表达它们的需求而获得不正确的结果,要么由于过载而是性能不佳。

总之它会让应用非常小心它们正在做什么—提升GPU性能的概率还是很大的,但是反过来降低其性能的概率也是相同的;对于完成一个良好性能的应用,性能与表现象协调如PVRTune是绝对至关重要的。

下一次更新前,记得在Twitter( @ImaginationPR , @PowerVRInsider )上关注我们,你可以及时获得PowerVR团队最新的消息和公告。

如果你想学习更多关于Vulkan的知识,现在就注册参加最后即将举办的研讨会:
 架构上的优势:在PowerVR GPU平台上Vulkan API是怎么工作的。

假如你错过了它们,你可以查看我的另一个关于Vulkan的系列博客和往期在线研讨会回放。

原文链接:
http://blog.imgtec.com/powervr/vulkan-explicit-operation-and-consistent-...

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