1298
编者按
去年的时候，抛砖引玉的写了一篇“硬件定义软件？还是软件定义硬件？”的文章，现在再看，发现很多考虑不全面不深刻的地方。继续抛砖，与大家深入探讨此话题。
今天这篇文章，我们主要关注如下话题：
超异构计算，为什么需要开放生态？
开放生态应该由硬件定义还是软件定义？
什么样的生态才算开放？
本文对应的幻灯片，公众号回复“介绍PPT”可以下载。
1 处理器类型：从CPU到ASIC
1.1 CPU指令集架构ISA
ISA（Instruction Set Architecture，指令集架构），是计算机体系结构与编程相关的部分（不包含组成和实现）。ISA定义了：指令集、数据类型、寄存器、寻址模式、内存管理、I/O模型等。
CPU图灵完备，是可自运行的处理器：CPU主动从指令内存读取指令流，然后译码后执行；指令执行会涉及到数据的载入(Load)、计算和存储(Store)。
我们可以把处理器简单地分为控制平面和计算平面两部分。
CPU是指令流驱动计算的处理引擎。
1.2 （CPU视角的）GPU架构
架构侧重软硬件之间的交互“接口”，而微架构侧重具体实现。因此，GPU架构通常指的是CPU视角看到的GPU“接口”。从CPU视角看GPU的处理流程：
CPU把数据准备好，并保存在CPU内存中；
将待处理的数据从CPU内存复制到GPU内存（处理①）；
CPU指示GPU工作，配置并启动GPU内核（处理②）；
多个GPU内核并行执行，处理准备好的数据（图中的③处理）；
处理完成后，将处理结果复制回CPU内存（处理④）；
CPU把GPU的结果进行后续处理。
1.3 ASIC专用处理引擎
ASIC功能逻辑完全确定：通过驱动程序和CSR和可配置表项交互，以此来控制硬件运行。
ASIC覆盖的场景较小，并且类型多种多样；即使同一场景，不同厂家实现依然存在差别；ASIC场景碎片化，毫无生态可言。
和GPU类似，ASIC的运行依然需要CPU的参与：
数据的输入：数据在内存准备好，CPU控制ASIC引擎的输入逻辑，把数据从内存搬到处理引擎；
ASIC的运行控制：控制CSR、可配置表项、中断等；
数据的输出：CPU控制ASIC引擎的输出逻辑，把数据从引擎搬到内存，等待后续处理。
ASIC是数据流驱动计算的处理引擎。
1.4 DSA领域专用架构
DSA是在ASIC基础上的回调，具有一定的可编程能力，覆盖场景更多，性能和ASIC同量级。
DSA经典案例：
网络DSA，如Intel Barefoot P4-DSA网络交换芯片。
1.5 小结：从CPU到ASIC，架构越来越碎片化
指令是软件和硬件的媒介，指令的复杂度（单位计算密度）决定了系统的软硬件解耦程度。
按照指令的复杂度，典型的处理器平台大致分为CPU、协处理器、GPU、FPGA、DSA、ASIC。
世间万物由基本粒子组成，复杂处理由基本计算组成。
指令复杂度越高，单个处理器引擎覆盖的场景就会越小，处理器引擎的形态就会越多。
从CPU到ASIC，处理器引擎越来越碎片化，构建生态越来越困难。
2 计算架构：从异构到超异构
2.1 CPU性能瓶颈，引发连锁反应
在云计算、边缘计算以及一些超级终端的复杂计算场景，对灵活性的要求远高于对性能的要求。
CPU通用灵活性好，在符合性能要求的情况下，各类复杂计算场景，CPU依然是最优选择。
对算力的需求不断增加，不得不通过各种异构加速方式进行性能优化。
实践证明，在复杂计算场景，提升性能的同时，不能损失通用灵活性（言外之意，目前很多技术方案损害了灵活性）。
2.2 异构计算存在的问题
复杂计算的挑战：系统越复杂，需要选择越灵活的处理器；性能挑战越大，需要选择越偏向定制的加速处理器。本质矛盾是：单一处理器无法兼顾性能和灵活性；即使我们拼尽全力平衡，也只“治标不治本”。
CPU+xPU异构计算中的xPU，决定了整个系统的性能/灵活性特征：
GPU灵活性较好，但性能效率不够极致；
DSA性能好，但灵活性差，难以适应复杂计算场景对灵活性的要求。案例：AI落地困难。
FPGA功耗和成本高，需要一些定制开发，落地案例不多。
ASIC功能完全固定，难以适应灵活多变的复杂计算场景。
异构计算还存在计算孤岛的问题：
异构计算面向某个领域或场景，领域之间的交互困难。
服务器物理空间有限，无法多个物理加速卡，需要把这些加速方案整合；
需要强调的是：整合，不是简单的拼凑，而是要架构重构。
2.3 超异构存在的前提条件：复杂系统和超大规模
基础特征：①超大规模的计算集群；②复杂宏系统，是由分层分块的组件(系统)组成。
单服务器的宏系统复杂度，以及超大规模的云和边缘计算，使得“二八定律”在系统中普遍存在，因此，可以把：相对确定的任务沉淀到基础设施层，相对弹性的沉淀到弹性加速部分，其他继续放在CPU（CPU兜底）。
2.4 从异构并行到超异构并行
计算从单核的串行走向多核的并行；又进一步从同构并行走向异构并行。未来，计算需要进一步从异构并行走向超异构并行。
异构计算是CPU+xPU的两个层次的处理引擎类型，而超异构计算则是CPU+GPU+DSA的三个层次的处理引擎类型。
超异构计算，不是简单的集成，而是把更多的异构计算整合重构，各类型处理器间充分的、灵活的数据交互，形成统一的超异构计算宏系统。
2.5 Intel：超异构、XPU和oneAPI
2019年，Intel提出超异构计算相关概念；目前为止，Intel没有完全符合超异构概念的产品。
超异构计算的基础引擎是XPU，XPU是多种架构的组合，包括CPU、GPU、FPGA 和其他加速器；
oneAPI是开源的跨平台编程框架，底层是不同的XPU处理器，通过OneAPI提供一致性编程接口，使得应用跨平台复用。
2.6 Intel超异构分析
2.7 NVIDIA自动驾驶Thor
（上图为Atlan架构示意图，Atlan和Thor架构相同，性能上有差异）
NVIDIA自动驾驶Thor芯片，由数据中心架构的CPU+GPU+DPU三部分组成，算力高达2000TFLOPS的超异构计算芯片。
Thor是把传统多个DCU（SOC）的功能融合成单个超异构处理芯片。
2.8 为什么是现在？
首先，是需求驱动。软件新应用层出不穷，两年一个新热点；并且，已有的热点技术仍在快速演进。元宇宙是继互联网和移动互联网之后的下一个互联网形态，要想实现元宇宙级别的体验，需将算力提升1000倍。
其次，工艺和封装支撑。工艺封装持续进步，工艺10nm以下，芯片从2D->3D->4D。Chiplet使得在单芯片层次，可以构建规模数量级提升的超大系统。系统规模越大，超异构的优势越明显。
最后，系统架构需要持续创新。通过架构创新，在单芯片层次，实现多个数量级的性能提升。挑战：异构编程很难，超异构编程更是难上加难；如何更好地驾驭超异构，是成败的关键。
2.9 小结：超异构设计和开发难度呈指数上升
软件需要跨平台复用，跨①不同架构、②不同处理器类型、③不同厂家平台、④不同位置、⑤不同设备类型。
如此复杂的超异构该如何驾驭？
3 开放架构和生态的现状
3.1 开放架构和生态综述
系统必然是在某个层次开放：
用户接口：应用程序必须提供UI供用户使用。
开发库：指提供函数的代码，开发者可以从自己的代码中调用这些函数来处理常见任务，如CUDA库等。
操作系统：提供系统调用接口。
硬件需要提供硬件接口/架构，给系统软件调用，如I/O接口、CPU架构、GPU架构等。
互操作性：不同的系统、模块一起协同工作并共享信息的能力。系统堆栈的相邻两层，遵循配对的接口协议进行交互；如果接口不匹配，就需要有接口转换层。
开放接口/架构及生态：基于互操作性，形成标准的开放的接口/架构；大家遵循此接口/架构开发产品和服务，从而形成开放生态。
3.2 RISC-V：开放CPU架构
x86架构主要应用在PC和数据中心领域，ARM架构主要应用在移动领域，目前也在向PC和服务器领域拓展。
为了给芯片提供低成本CPU，加州大学伯克利分校开发了RISC-V， RISC-V已成为行业标准的开放ISA。
理论上可通过静态编译、动态翻译等方式，实现跨不同CPU架构运行。但都存在损耗及稳定性等问题，需要很多移植方面的工作。
一个平台上的程序难以在其他平台上运行（静态），运行时跨平台（动态）更是难上加难。
理想情况，如果形成RISC-V的开放生态，没有了跨平台的损耗和风险，大家可以把精力专注于CPU微架构及上层软件的创新。
RISC-V的优势：
免费。指令集架构免费获取，不需要授权，没有商业上掣肘。
开放性。任何厂家就可以设计自己的RISC-v CPU，大家共建一套开放的生态，共荣共生。
简洁高效。没有历史包袱，ISA更高效。
标准化。最关键的价值。如果RISC-v变成主流架构，就没有了跨平台等成本或代价。
3.3 GPU架构生态
目前，GPU还没有像CPU RISC-V一样，有标准化的、开源的ISA架构。
CUDA是NVIDIA GPU的开发框架，向前兼容。
OpenCL是完全开放的异构开发框架，可以跨CPU、GPU、FPGA等处理引擎。
3.4 DSA，混战
①DSA领域多种多样，即使同一领域，②不同厂家的DSA架构仍不相同，甚至③同一厂家不同代产品的架构也不相同。
最典型的AI-DSA场景，目前就处在各种DSA架构混战的阶段。
要想构建DSA的生态：
软件定义，不需要开发应用，兼容已有软件生态；
少量编程（许多DSA编程，类似静态配置脚本），门槛较低的标准的领域编程语言；
开放架构，防止架构过多导致的市场碎片化。
DSA架构一般来说分为静态和动态两部分：
静态部分。类配置脚本，通过编译器映射到具体的DSA引擎，编程实现DSA引擎的具体功能。
动态部分。DSA的动态部分通常不是编程实现，而是跟已有软件进行适配；相当于是把软件的数据平面/计算平面卸载到硬件，控制平面依然在软件；符合软件定义的思路。
3.5 DSA/ASIC集成平台：NVIDIA DPU
DPU集成虚拟化、网络、存储、安全等DSA/ASIC引擎，DOCA框架：库文件、运行时和服务、驱动程序组成。
DPU/DOCA是非开源/开放的封闭架构、平台和生态。
3.6 DSA/ASIC集成平台：Intel IPU
和NVIDIA DPU类似，Intel IPU集成虚拟化、网络、存储、安全等DSA/ASIC引擎。
IPDK是开源的基础设施编程框架，可运行在CPU、IPU、DPU或交换机。
Intel和Linux基金会的OPI项目：为基于 DPU/IPU 类技术的下一代架构和框架，培育一个标准的开放生态系统。
Intel IPU/IPDK/OPI是开源/开放的架构、平台和生态。
3.7 硬件使能：Hardware Enablement
随着数据中心演变成虚拟机、裸金属机和容器的组合，OpenStack社区扩大成新的OpenInfra社区。
旨在推进开放基础设施领域技术发展，包括：公共云、私有云、混合云，以及AI/ML、CI/CD、容器、边缘计算等。
Ubuntu硬件使能版本：为了更好地支持最新的硬件，会经常更新内核版本，不太适合企业用户。
OpenInfra硬件使能：软件组件需要在云和边缘环境使能硬件，包括GPU、DPU、FPGA等。
在硬件加速/软件卸载的语境下，硬件使能可以理解成：
软件要支持硬件加速，“硬件加速原生”；
如果存在硬件加速的资源，则采用硬件加速模式；
如果不存在硬件加速的资源，则继续采用传统的软件运行模式。
4 硬件定义软件，还是软件定义硬件？
4.1 系统的控制平面和计算平面
把分层分块的系统，映射到软硬件具体实现：控制平面运行在CPU，计算/数据平面运行在CPU、GPU、DSA等处理引擎。
4.2 泛义的软硬件接口
泛义的接口：
块和块之间、层和层之间的接口；
软件和软件之间、硬件和硬件之间、软硬件之间的接口。
软件和硬件之间的接口：
硬件定义接口，软件适配；
软件定义接口，硬件适配；
硬件/软件定义接口，软件接口适配层；
硬件/软件定义接口，接口适配层卸载；
软件硬件设计遵循标准接口（要求：标准、高效、开源、迭代）。
4.3 什么是硬件/软件定义？
系统是由软件和硬件组成，也必然是软硬件协同的。从软硬件的相互关系和影响，阐述软件定义和硬件定义。
评价标准：系统的业务逻辑由谁决定；软件和硬件的交互接口（架构）由谁决定。
“硬件定义软件”定义为：系统的业务逻辑以硬件实现为主，软件实现为辅；软件依赖于硬件提供的接口构建。
“软件定义硬件”定义为：当一个系统的业务逻辑以软件实现为主，硬件实现为辅；或者硬件引擎是软件可编程的，硬件引擎按照软件编程的逻辑执行操作；硬件依赖于软件提供的接口构建。
4.4 硬件/软件定义的依据：系统复杂度
硬件定义软件，还是软件定义硬件，跟系统复杂度是休戚相关的。
系统复杂度较小，迭代较慢。可以快速设计优化的系统软硬件划分，先硬件开发，然后开始系统层和应用层的软件开发。
量变引起质变，随着系统复杂度上升，系统迭代快，直接实现一个完全优化的设计难度很大。系统实现变成了演进式：
前期系统不够稳定，算法和业务逻辑在快速迭代，需要快速实现想法。这样，基于CPU的软件实现就比较合适；
随着系统发展，算法和业务逻辑逐渐稳定，后续逐步优化到GPU、DSA等硬件加速来持续优化性能。
硬件定义还是软件定义？本质上是系统定义。系统的复杂度过高，实现难以一次到位，于是系统的实现，变成了持续优化和迭代的过程。
4.5 硬件/软件定义的本质：归纳和演绎
硬件/软件定义的本质，是通过归纳和演绎实现系统及系统的发展。从长期和发展的视角看，系统是由软硬件共同定义的。我们以典型的处理引擎实现进行分析：
CPU：把所有领域归纳出共性（最基本的指令），这个共性“放之四海皆准”。也即是说，相对其他平台，“CPU不需要再归纳”，只需要持续演绎新的领域和场景。软件定义：CPU已经是成熟的软件平台，可以基于CPU快速实现系统原型，当系统的算法和业务逻辑稳定后，可通过硬件加速进行性能优化。
GPU：把很多个领域归纳出共性，然后硬件实现共性，软件实现个性。GPU平台实现后，可以持续演绎新的领域新的场景。GPU是足够通用、成熟的并行计算开发平台。
DSA：把某个领域多个场景的业务逻辑进行归纳：硬件实现共性部分，软件实现个性部分。DSA平台实现后，可以在此领域演绎新的场景。
ASIC：具体场景的算法和业务逻辑直接变成硬件，软件只是基本的控制作用。直接映射，谈不上归纳和演绎。
5 总结：软硬件共同定义，超异构开放生态
5.1 软件原生支持硬件加速
软件原生支持硬件加速：
软件架构调整，控制面和计算/数据面分开；
控制面和计算/数据面接口标准化；
硬件加速资源的发现能力，自适应选择软件计算/数据面或硬件计算/数据面。
数据的输入，可以来源于软件，也可以来源于硬件；
数据的输出，可以去向软件，也可以去向硬件。
5.2 完全可编程
完全可编程，不是CPU可编程，而是在极致优化性能基础之上的可编程。完全可编程是分层的可编程体系：
基础设施层可编程。基础设施层Workload不经常变化，可以采用DSA架构。
弹性应用可编程。支持主流GPU编程方式，可以把常见应用通过DSA，实现更高效率的加速。
应用可编程。应用不确定性最大，仍然运行在CPU。同时，CPU负责兜底，所有其他不适合加速或没有加速引擎的任务都在CPU运行。
实现完全可编程的同时，性能数量级的提升：
从整个系统看，绝大部分是DSA加速的，因此系统的性能效率接近于DSA；
Chiplet+超异构，系统规模数量级提升，系统性能数量级提升；
从用户角度，应用运行在CPU，用户体验到的是100%的CPU可编程。
5.3 开放接口和架构
ASIC/DSA覆盖的领域/场景较小，芯片对场景的覆盖（相比CPU、GPU）越来越碎片化。
构建生态越来越困难。需要从硬件定义，逐步转向软件定义。
超异构计算，包括CPU、GPU，也包括多种DSA、ASIC类型的处理器。
异构的引擎架构越来越多，必须构建高效的、标准的、开放的接口和架构体系，才能构建一致性的宏架构（多种架构组合）平台，才能避免场景覆盖的碎片化。
5.4 计算需要跨不同类型处理器
超异构包含CPU、GPU、FPGA、DSA等不同类型的处理器，计算任务需要跨不同类型的处理器运行。
oneAPI是Intel开源的跨平台编程框架，通过oneAPI提供一致性编程接口，使得应用可以跨不同类型处理器运行。
更广泛的，不仅仅是跨不同类型的处理器，还要能跨不同厂家的芯片平台。
5.5 超异构开放生态
要想提升算力利用率，就需要把一个个孤岛的计算资源，整合成统一的资源池。
需要通过跨平台融合，实现计算资源池化：
维度一：跨同类型处理器架构。如软件可以跨x86、ARM和RISC-v CPU运行。
维度二：跨不同类型处理器架构。软件需要跨CPU、GPU、FPGA和DSA等处理器运行。
维度三：跨不同的芯片平台。如软件可以在Intel、NVIDIA等不同公司的芯片上运行。
维度四：跨云网边端不同的位置。计算可以根据各种因素的变化，自适应的运行在云网边端最合适的位置。
维度五：跨不同的云网边服务供应商、不同的终端用户、不同的终端设备类型。
超异构时代，必须要形成开放的生态，才能让计算资源形成一个整体，才能满足元宇宙等应用场景对算力数量级提升的要求。
5.6 软硬件共同定义：超异构开放生态
首先，是超异构计算架构。CPU+GPU+FPGA+DSA等多种架构处理引擎组成的超异构计算；实现既要又要：接近CPU的灵活性，接近ASIC的性能效率，以及多个数量级提升的性能。
其次，要平台化&可编程。两个一切：软件定义一切，硬件加速一切；两个完全：完全可软件编程的硬件加速平台，完全由软件编程决定业务逻辑；一个通用：足够的通用性，满足多场景、多用户的需求，满足业务的长期演进。
最后，要标准&开放。架构/接口标准、开放，持续演进；拥抱开源开放的生态；支持云原生、云网边端融合；用户无（硬件、框架等）平台依赖。
