为什么UE需要封装RHI这么一层接口呢?原因我也不是很清楚,但是从我自己的感受来看这么封装相比于让上层直接调用API还是有一些好处的:各个平台比较通用的实现,在RHI层面就可能是一套,而比较专用的实现,用不同接口区分开。内部也可以在对外接口不变的情况下,做一些优化或适配方面的工作,同时还可以把调用原始API时候非常复杂的参数,缓存,多线程调度等细节都隐藏起来,让上层的渲染线程专心和RHI提供的接口打交道。总的来看对于使用者来说是更简单了,毕竟复杂又头疼的事情虚幻都做了。虽然官方说RHI封装的层次尽可能低,但其实底层还是隐藏了一大堆细节,比如贴图缓存池,着色器缓存池,RT缓存池,多线程提交等。对于引擎开发者来说,在原始的RHI接口函数不符合要求时,或者想做一些跟业务绑定的专有逻辑时,这一套非常深的封装反而是一个非常重的负担,因此我就根据自己阅读源码后的理解和开发经验,尝试总结梳理了一下RHI的脉络,方便大家能够更容易的了解源码背后的原理,当然本文也仅仅是RHI相关的内容,不涉及到上层各种渲染技术。
Vulkan API