第一个，其实真的下一条命令去绘制，是经过很多层。我们厂商开发的驱动程序本身也是一种程序，只是在更底层怎么去工作。如果说这个API本身比较复杂，比较陈旧就不能反映最新硬件的特性。我们在开发这个驱动的时候不可避免一些不必要的复杂性。我们有全新的API就可以减少这部分的消耗。另外一方面，硬件最大的变化是什么？手机的核数越来越多，CPU、GPU都变成多核的。多核代表多线程，如果只是单线程的话，没有办法。所以，我们提供一个更好的多性能的支持，变得非常紧要。然后CPU我刚刚说了有大核小核，大核小核的计算能力不一样。如果说你把小核的任务给大核分配，可能又会浪费一些资源，怎么样做一个动态的配置任务呢。这是一个很有挑战性的技术问题。这个在Vulkan上面得到了相对比较完善的解决。这个解决实际上效果怎么样，还是要开发者提高。

　　好，刚才我大抵说了一下Vulkan API的背景，我后面再给大家详细地介绍一下使用Vulkan API会带来哪些潜在的好处呢？这边是一个很简单很简单的图，把复杂的API抽象成几个模块，这里面是Appllcation，是大家自己去写的代码，或者是一部分的逻辑。我先不讲这里面的内容，我先看这几个方块里面，最大的就是绿色的这一块。最大的复杂性现在被移到了上层，APP的层面。后面的编译层等等都会变得比较小，比较轻。为什么要这样做呢？这里面有一个最关键的一点，也就是说，atv，作为开发者其实只有你心中有数，这一步要做什么，下一步要做什么。底层接受命令的层面，要么是被动去执行，要么通过内在的逻辑去猜测你要执行什么。有时候需要你去作弊，以前你听过一个故事，在某某跑分软件里面，你把名字改一下，跑分就不一样了，这就是猜测逻辑。开发者和最后的客户，他们也面对很复杂的场景。我想买一台真正很好性能的手机，其实很难挑对。其实这个里面，也代表了机会，虽然问题非常复杂，但是终于找到一个正确的方向。一个就是说简化这个driver，第二个就是多核多线程的支持做得更顺畅，方便上层的人使用。然后可以更好地保护知识产权。如果说你是内部做开发测试版本的话，你又可以非常方便地去一步一步地调试。这样各种新的特性都使这个API变成一个全新的平台。

　　这里面最大的特性就是Multi-threading和multicore efficiency。当你绘制的场景里面有很多物体有很多并发的事件的时候，它提供的帮助非常多。反过来，你的场景卡住了，它能提供的帮助要有限一些。大家看一下你面对的实际最大的挑战是什么，来决定采用什么样的方式去做优化。

　　后面的Multi-passrendering会跟大家介绍一下。它是非常具有巨大潜力的东西。现在到了Vulkan的时代，跟OpenGL的时代不一样。GPU第一念头是显卡而不是电脑或者手机。而今天看来，一定是移动设备占了大多数。一开始在蓝图上面就把移动芯片全部考虑进去，现在可以通过Vulkan，可以更好地发挥它的潜能。我后面会介绍一下它是怎么样的潜能，为什么会有这么的高效。目前Unity对于Multi-pass还在起步阶段，可能在不久的将来会逐渐成熟的一个feature。

　　Multi-pass简单来说，如果你想要画一个比较复杂的，接近真实的光的场景的话，你要做很多很多子步骤。在这里面，我图上画的是一个有光照的场景的renderpass，通过几轮渲染以后合成出一个非常非常逼真的场景。这种算法解决方案，它有一个最大的挑战就来自带宽。你每一次做完显然以后，你会需要前一次的结果，把后面的结果跟它做一个后面的运算。这就不可避免地带来大量数据的写入和写出。这个带宽现在硬件的进步变得非常非常高，但是高带宽带来的是高功耗以及高成本，在移动设备上面是非常禁忌的事情。我们又想实现一样的效果怎么样呢？其实天无绝人之路，我们确实有一些主流的GPU都没有的特性。这个就是Tile-based，Tile就是马赛克。我们在绘制画面的时候，也是采取一样的策略，把这个问题由大变小，把屏幕划分成小区域，然后一块一块去处理。绿色的上面有一个一个小方块，这个箭头代表着频繁访问，高速访问的流程。它和我们其他总线的输出和写入是不一样的。它基本上没有任何cocos，非常非常快。所以在移动平台上面，我渲染完一帧以后，是把很多Tile组合在一起。这个做完以后，做另一个Tile。但是如果这个画面上绘制好几遍，最后再合成一个好的画面的话，每一次上面那个Tile绘制完以后的话，我直接缓存下来跟后面结合一起，就可以省出一部分时间。这就有一个很大的帮助。随着将来给你的支持逐渐完善，你就有办法做很多很多超过总带宽值所允许的工作。