求是设计会

作者：浩南兄，张宏鑫    单位：浙大CAD&CG实验室

以下内容来自浩南兄，张宏鑫，由浩南兄撰写完成。版权声明：文章版权归原作者所有，转载时请以超链接形式标明文章原始出处和作者信息。

在开始前

• 主要问题：开发者如何从用户需求的角度搭建、开发渲染农场软件。
• 主要介绍内容：渲染农场的基本概念和未来展望。
• 关于合作：如果你对开发和设计渲染农场管理软件有兴趣，也可以联系，或Email：yjl424@gmail.com，我们非常欢迎合作和交流。

对于用户而言，渲染农场的搭建，技术难度并不完全在可见硬件设备的上，而是整体工作流程的科学规划。通常用户关心的是：

• 渲染引擎的正常调用
• 在相同硬件和网络平台下，提交任务的速度和性能
• 渲染过程不丢失数据
• 系统扩展性能
• 失败任务修复
• 主流渲染软件的支持
• 能否支持静祯分割渲染
• 用户界面
• ……

对于传统的建筑特效公司、动画公司或者渲染服务提供商，稳定可靠往往是商业的第一选择。而对于一些研究机构，或者某些企业研发部门，开发出提高效率的新技术、新架构则是他们所关心的。本章，我们将讨论商业渲染管理软件的核心需求，而在下一章中，对未来有价值的新应用和研究方向提出一些观点。

软件架构

通常而言，渲染农场必要的部分包括如下三个：任务分发、渲染、文件存储。

任务分发节点，通常被叫做Master、Manager或者Dispather。负责中心调度，接受任务提交、分配、结果回收等。这部分一般做成系统服务，并提供众多控制台接口和网络接口，以便上层GUI调用。因为任务分发是整个系统的中心所在，所以很多其他部分也会放在这里，例如：渲染节点的管理，用户管理，日志等等。

渲染节点，一般被称为Slave、Node、Render Client等。当任务分发节点将任务（Job）分割并分派后，渲染节点是实际运行子任务（Task）的节点。这些节点一般是多核的高端机器，运行在节点上的软件一搬也作为系统服务。如前文所提到的，因为操作系统license的问题，渲染节点支持Linux是一个普遍的需求。

上图是一个常见的渲染农场管理软件架构，各个部件由交换机或者其他网络部件连接。

文件存储节点，叫做File repository。大部分的集群管理软件选择使用了局域网络共享协议，所以会将相关的文件夹共享，用来支持场景读取、图像存储等工作。文件存储节点，可以集成在Master机器上，可以单独的是一台PC机，在重量级的系统中，文件存储是单独的节点，一般为高性能磁盘阵列。

有了上述三个节点，整个系统就可以工作了。当然，用户不希望整个系统的使用沉溺在各种控制台命令之中。任务的提交，进度的查看，错误的分析，这些部分都是系统和用户之间沟通用的。

系统管理，一般叫Monitor、Web Monitor、Explore之类。成熟的系统中，用户界面和底层系统内部逻辑是完全分离的。甚至用户界面都是用脚本配置的，以便于系统的拓展。用户管理系统登录连接上Master机器，读取系统状态。用户关心的内容主要是：任务（Job）排队状态、当前任务运行状态、渲染节点工作状态、任务（Task）分配、结果查询。

渲染器支持

专业渲染管理软件和自带工具的最大区别在于，是否支持各种主流渲染器。举个例子，如果某个工作团队使用Maya做动画，用3DMax做建筑效果，用After Effect做后期合成特效，那么这个渲染农场系统至少要能同时为这三种任务做划分，然后并行渲染。显然，任何一个自带工具（如Vray distributed rendering、Backburner、Maya satellite）都是无法胜任的。

渲染器的支持有几种不同的方法。首先是调用渲染器的控制台程序，其次是用插件的形式在创作工具内部嵌入直接提交的功能。支持三方插件的软件，比如Maya和3DMax，都可以在程序中嵌入任务提交界面。

本质而言，无论支持何种渲染器，都是从调用控制台程序开始的。例如Maya的渲染控制台文件是”Render.exe”，按照Maya的命令行手册调用这个程序，就能在渲染节点渲染某个场景。调用”Render.exe”不会启动用户界面，所以会比较节省计算资源。

多渲染器的支持，需要做接口抽象，将所有渲染器的共同点提取出来。共通点包括：场景文件、起始帧、终止帧、结果存放文件夹等。定义了这些抽象的字段之后，实际上可以支持任意的渲染器，只要渲染器提供了相关的接口。将这些规则做成用户手册，指导用户按照一定的格式自己可以定制新渲染器支持，包括自行开发的渲染器。

任务分割

任务分割是并行发生的基本要素，是从Job细分到Task的过程。单帧量图像渲染，从屏幕空间对图像分割，每一块图像为一个子任务。动画任务由一系列的单帧组成。

屏幕空间的划分，在3DMax的建筑效果渲染任务中比较常见。但不是每一种渲染器都支持屏幕空间的划分，所以，这个特性不是通性，如果在渲染农场管理软件中很好的支持这一功能，有便捷的用户界面支持，也是一种“先进”之处。

更多的情况下，渲染农场处理的是动画任务，大部分的管理软件会把任务直接细分到单帧，也就是说每一个Task是一个动画帧，例如48帧动画中的第2帧就是一个Task。

这样的单帧任务划分方式，在一些应用下会降低整体渲染效率。例如100帧的动画，20台渲染节点，平均每台渲染节点需要处理5帧动画。如果5帧动画作为Task单独渲染，渲染节点需要不断的加载场景，关闭，再加载场景。如果给渲染节点直接分配连续5帧的动画，那么场景只需要加载一次，场景之间的一致性也会较高。

上图是一个10帧任务划分的例子，一种方式是划分为10个单独的Task，另外一种方式，对Task进行了捆绑，当然这种捆绑需要一定的原则。

调度方法

理想的状态下，Task的数量正好和Node节点的数量一致，并且每一个Node节点都是一样的机器，场景复杂度也一样，最终Task会同时完成。

不过这样的情况极少发生，场景的复杂度通常是不一样的，极端的时候渲染节点之间的性能差距很大，是一种异构环境。这个时候就需要调度算法，无论什么调度算法，从渲染农场整体利用率来看，是要让每一台机器都不空闲，最大程度的利用计算资源。从单个任务（Job）完成的角度来看，最快速度完成某一个任务也是一个评判标准。

一种简单有效的一种方式，叫做需求驱动。将所有的任务全部都细分为单帧Task，每当渲染节点空闲并可用时，叫像任务分发节点请求任务一个Task，完成之后，返回结果，再申请新的Task。

因为Task在计算的时候，总时间消耗是场景加载加上渲染。场景加载又分为网络读取、场景初始化两部分。假设一帧完成的时间是T，由网络读取时间tn，场景初始化ts，和渲染时间tr组成。有T = tn + ts + tr。一个任务有n帧，总时间 = n x (tn + ts + tr)。可以看到，n越大，消耗在不断的网络传输，场景加载上的时间越多，即使在本地保存副本，尽量省去tn这部分的重复工作，ts仍然造成了一定的资源浪费。

其他的调度方法，则更多的从任务本身的角度去考虑。如上一节中提到的任务分割方法，在已经知道能够使用的渲染节点的前提下，将任务“包装”起来，一并发送给指定的渲染节点。这种方式在tn和ts部分算法复杂度为O(1)，相比于上一种的O(n)，效率提高。但当某一台机器因为性能低，完成速度慢于其他机器时，负载不平衡的情况很容易出现，这个时候，再重新分派任务比较困难，如果重新分派，会造成重复计算。

可以发现，这两种方式，是用灵活度换取性能，还是牺牲性能获得调度自由的两难问题。那么理想的方式为，在第一种方法下取消ts这个障碍。正如Qube描述过的“动态划分”方法，如果能够控制渲染器在单帧结束后，不卸载场景数据，而是等待新的帧任务到来的话，性能将会有很大程度的提升。

假设能有这么一种“动态划分”的的算法存在，上图演示了一中利用连续场景之间的coherent，又能由自由调度的“两全其美”的方式。

N帧的动画任务，按照渲染节点的性能评价，不等份的将Task“打包”预指定给对应的Node节点。Job的渲染过程开始之后，将单帧Task发送到预定的Node节点，进行计算。因为有预定，每一个Node都会计算连续动画帧，coherent得到了发挥。如果发生了负载不平衡的情况，如上图所示的情况，已经完成的节点按照顺序去获取没有计算完成的帧，直到所有的Task都被完成。

这种方法仅仅预期能取得一些效率的提高，单个Job的完成时间将会得到减少。另外一点，关于异构集群的问题，从理论上来讲，异构集群对负载平衡是有害的。

文件共享方式

渲染农场的工作原理是将本地机器的工作提交给其他机器处理，那么本地场景还有一切的相关文件，都要能被其他机器访问到。

内部文件文件共享有多种方式，按照是否复制副本分为两类。复制副本的，一般用TCP/IP协议进行文件传输，或者直接用FTP协议实现，也有部分使用Http文件传输方式的（不适合大文件）。不复制副本的，则是局域网络文件共享协议。

在任务分发节点和渲染节点之间，涉及到数量众多的节点之间的通信，自行实现较为复杂，大多数的渲染农场管理系统选择使用局域网文件共享方式。在Windows操作系统中，协议为SMB，而在Linux和Max OS中，协议为Samba。Samba是模仿windows下的SMB的一种协议，这样这几种不同的操作系统就能局域网内互相分享文件。大部分的Linux和Mac OS的发布版本是带有Samba实现的，而SMB是Windows操作系统默认的部分。

在一些公司的实现方案中，存在中心文件服务器，美工从中心服务器读取场景，进行编辑，再保存回中心文件服务器。之后的渲染任务不需要从美工机器再次提交到分发节点。对于一些小公司而言，为了进行集群渲染，首先还是要将自己机器上的工程文件提交给文件服务器（通常和任务分发节点是同一台机器）。

渲染农场的各个部分之间场景文件传输的代价还是比较大的，在工程文件很大的情况下，会比较耗时。局域网中，一般情况下，FTP的速度不会超过10M每秒，1G的场景每次都需要将近2分钟来传输。渲染节点较多时，并发的对同一台机器产生传输申请，会造成网络压力。

用户界面

早期集群渲染系统没有太多GUI，许多功能需要调用控制台程序。随着对用户体验的重视程度越来越高，界面也逐渐人性化。各种软件的用户界面虽然各有特色，总体而言也遵从一些设计原则。

标识1，菜单栏，任务提交一般在这个栏目。

标识2，通常设计为一个筛选器，用来分类查看任务，或者分类查看渲染节点。

标识3，基本都是为Job运行情况预留的，这里用户查看Job的属性，是否开始计算，进度等等。

标识4，辅助界面，可以用多个Tab来显示关于任务运行的一些相关信息、渲染节点的运行情况等等。

标识5，第二辅助界面，通常显示一些log、统计信息、属性信息等。

界面设计有一些要点，例如Job的状态查看是最重要的，要放在显眼指出，而且每一个Job的Task完成情况也要有界面能方便的看到。当Job多了之后，就需要能够筛选和查询Job。任务提交界面无论是从菜单栏拉出，还是在标识5处提交，都要做到分类明确，并可以设置默认提交渲染器。

在拥有所有底层服务接口的基础上，界面和用户交互还有很多的选择。Web化，或者做成App。

Web界面在很久之前就在渲染农场管理软件中出现，因为一些操作系统的问题，某些管理界面不能在Linux下运行。在Flash或者silver-light等技术的支持下，用户还是能够有机会享受更好的交互体验的。

展望和趋势

小作坊式的渲染农场，并不需要考虑诸如大规模的数据同步，存储调度等问题。而然商业运作规律告诉我们，无论是存储还是计算，都不是一定要自行实现。云概念下的网络基础设施可以被租赁使用，而不需要购买者去维护。

在未来，用户不必为渲染过程下载一堆软件，购买众多机器，而是通过网络提交自己的渲染服务，投资自己消耗的那部分计算。无论是Google的MapReduce，还是亚马逊的弹性服务，还是Sun、IBM的解决方案。“云计算”不是新概念，也不是任何一个人或一家公司的想法，而是整个行业思维方法的转变，工业化的分工细分。

2010年的Nvidia技术大会上，用户可以把自己的场景提交给iray的计算集群，GPU优化过的渲染器集群，可以在数十秒内将渲染结果反馈给用户。同样的任务，需要一台同时代的PC计算几天到几周不等。

在新的基础设施的支持下，我们如何存放场景，如何协同工作，如何提交计算任务，如何获取计算结果，都将一步一步的发生变化。

也许有一天，你也可以加入渲染网络，用你自己的PC或者集群赚点零花钱呢。