扁平化的未来

为了能够比较通俗的进行解释，我们决定用一个不那么严谨的方式来举一个不怎么准确，但却十分好理解的例子。

我们的一位同事前一阵跳槽了，他去了一家做手机的名字是某种粮食的公司高就。同事去了粮食公司之后对我们大发感慨——这间公司扁平化的好厉害，各级主管都是只管具体事儿的小头目而已，定调的只有绰号“雷布斯”的公司老总一人。所有人，哪怕是最底层的实习生，只要一有想法，都可以去直接敲“雷布斯”的办公室门然后进去PK，无论天文地理还是鸡毛蒜皮，只要想法可行，“雷布斯”都会直接把想法变成项目交给对应的人员去推动，甚至可以绕开各个小头目们。

扁平化企业结构的优势（图片源自互动百科）

虽然并不是所有项目都会以这种方式在公司内部产生、发酵然后成型，但粮食公司这种扁平化的组织架构确实给公司中许多项目的产生和推进创造了有利的条件，它可以让信息更快速的在决策层和基层之间进行流动，减少传统企业架构当中多层管理结构对于信息交换和决策所造成的迟滞，还可以带来更高的项目执行效率，提升公司的执行能力和竞争力。粮食公司这两年的蓬勃发展，与扁平化有着很深的联系。

当然，有优势就会有考验，扁平化不代表一盘散沙，扁平化公司内部的原始执行效率和单位执行效率必须要高，而且依旧需要针对性极强的模块化分工和协作来达成任务的高效执行。在此基础上，扁平化还需要顶层的决策者相当强势并且十分全能。“雷布斯”不一定非要专精于某种领域，但他必须是，起码要尽可能的是一名全才，能够了解公司业务相关的一切或者是绝大多数相关领域，可以对信息和想法是否对公司有益以及如何发展进行判断和决策，甚至还要明确将任务交给谁才干的最快等等细节问题。

最理想的扁平化需要一个无比强大的领导，当然也可能累死他……

扁平化要求决策者无比强大，他的强大是信息快速交换、决策快速成型以及任务正确推进的一等要素。如果能够达成扁平化对决策者的要求，同时公司内部能够保有极好的执行效率和分工协作能力，扁平化的企业应该可以保持旺盛的活力和很好的竞争力。

当前的GPU，尤其是NVIDIA GPU所要面对并解决的，正是与扁平化公司相同的问题。

扁平化的麦克斯韦

就像一般的健全发展企业一样，GPU的发展也是一个循序渐进的过程。在GPU逻辑结构的初级阶段，复杂细腻的多级任务管理机制有助于细化任务，提高任务的分派效率和准确率，进而提升单元复用率并提升架构的总效率。但是，随着ALU规模的肥大化，分级任务管理机制的规模也会跟着膨胀，越来越多的ALU需要越来越多的分级管理机制进行有效的管理，这显然会导致管理体系慢慢走向过于庞大的方向，消耗过多晶体管并占据更多的芯片资源。

不仅如此，同样跟每一个繁文冗节过多而且部门派系庞大并且相互制肘的企业一样，过于庞大复杂的多级管理机制也会给任务发放和回收带来明显的迟滞问题，大量能源和延迟会被浪费在数据交换流通以及通讯而不是运算和操作上。多级管理机制的膨胀同时还会提升驱动及软件对硬件的管理和使用成本，增加编程端的优化难度，面对日益庞大的硬件，程序员们在构筑算法时需要更多的考虑通讯问题并非操作本身，他们的精力将可能会因此而被更多地引导到数据结构之类的层面，如何提升操作效率或者进行更有效的计算反倒成了退一步之后才会考虑的问题。这不仅无助于硬件实际性能的提升，降低架构的性能功耗比，同时还会制约软件和算法的进步。

传统NVIDIA GPU的多级任务管理机制

凡事总有过犹不及，复杂严谨的多级任务管理机制在GPU的初期阶段是必要和必须的，但在GPU规模日益庞大的今天，它反倒成了进步的枷锁和绊脚石。所以就像Cache肥大化之后Intel从xbar转向ringbus一样，GPU的肥大化必定催生任务管理机制从多级回归到单级。

于是，逐步接替现有任务管理机制的LOC来了。

在我们所推测的麦克斯韦架构当中，LOC单元就是整个GPU的“雷布斯”，它将会以比GTE更高的效率遂行整个逻辑结构的任务决策和管理工作，更多地介入但又不会完全接管原本由其他下级任务管理机制承担的与执行单元的沟通活动。LOC会直接与底层执行单元进行通讯并传递任务，而底层单元执行完毕的部分任务结果也将能够直接递交给LOC进行回收，不再需要像过去那样通过逐级回归的方式来完成上缴。显而易见的，LOC单元的引入不仅能增强GPU的最上级管理体系，改善整个GPU的任务密度和任务传递有效性，同时也可以降低整个GPU的通讯成本并提升底层单元的执行效率。

面向ALU团簇的二级任务管理机制（Fermi架构）

从多级任务管理机制回归到扁平化甚至单级任务管理机制，需要单级任务管理机制本身具有强大的执行/决策能力和足够高的灵活性，它（LOC或者其他一级任务管理单元）不仅要能够迅速的对不同任务做出正确反应，还要能实时掌握原本拆分给多级并行管理机制来管理的庞大ALU团簇所处的状态并直接对其进行有效统御。设计者需要为充当单级任务管理机制的逻辑结构与ALU团簇设计更为直接高效的通讯机制，驱动端也必须做出大量的对应优化工作，这些工作都是前所未有的。既然前所未见，试水就是一个必要的选择了。

Echelon架构细节

伴随着数代架构的演进和积累，NVIDIA目前所拥有的各个底层执行结构在现行环境下的综合表现，尤其是性能功耗比表现已经相对成熟，我们认为NVIDIA以这些相对成熟的结构作为基础和对象来完成试水是一个很合适的选择。所以从谨慎的采用渐进式的方式逐步取代现行结构的角度出发，以一个成熟的，比较小但又不是小的离谱的现行结构作为切入点进行LOC的引入试水是合理的。

扁平化的需求和切入点的合理选择，这就是我们对麦克斯韦首秀形式做出前述预期的依据。如果GM107是第一个被推出的麦克斯韦，NVIDIA在推出GM107之后才推出更大规模的麦克斯韦，那也不是什么奇怪的事情。

但是，GM107并不一定就会采用麦克斯韦架构。