图形和计算API概述
名称 | 开发者/维护者 | 适用场景 | 描述 |
---|---|---|---|
OpenGL | Khronos Group | 计算机图形渲染、视频游戏开发以及工程应用程序 | 一个跨语言、跨平台的API,用于渲染2D和3D矢量图形。 |
OpenGL ES | Khronos Group | 专为移动和嵌入式系统(如智能手机、平板电脑、游戏机和车载系统)设计 | OpenGL的一个子集,专为移动和嵌入式系统设计。 |
WebGL | Khronos Group | 在Web浏览器中的3D图形 | 一个JavaScript API,允许在兼容的Web浏览器中渲染3D图形。 |
WebGPU | W3C | Web应用程序的图形和计算 | 旨在提供一个更现代的、低级别的接口,用于Web应用程序中的图形和计算任务。 |
DirectX | 微软 | Windows和Xbox上的游戏和多媒体应用 | 一套API,用于视频游戏开发和处理视频和音频。 |
Metal | 苹果公司 | iOS、iPadOS、macOS、tvOS上的图形和计算 | 一个低水平的图形和计算API,专为苹果设备设计。 |
Vulkan | Khronos Group | 跨平台的高性能图形和计算 | 一个跨平台的图形API,旨在提供高效的、低开销的GPU使用。 |
CUDA | NVIDIA | GPU加速的计算 | NVIDIA的并行计算平台和API,允许使用GPU进行通用计算。 |
OpenCL | Khronos Group | 异构平台上的并行编程 | 一个框架,支持多种处理器上的并行计算,包括CPU和GPU。 |
DirectCompute | 微软 | 在Windows平台上的通用GPU计算 | DirectX的一部分,提供了一种在GPU上执行通用计算的方法。 |
Mantle | AMD | (已停止开发)游戏和图形应用 | 一个低级图形API,虽然已停止开发,但对后来的Vulkan API产生了影响。 |
RTX/DXR | NVIDIA/微软 | 实时光线追踪 | 提供实时光线追踪技术的支持,允许创建更真实的光照和阴影效果。 |
SceneKit | 苹果公司 | iOS和macOS上的3D图形应用 | 苹果公司的高级3D图形框架,简化了3D图形应用程序和游戏的开发。 |
SpriteKit | 苹果公司 | iOS和macOS上的2D游戏 | 专门为2D游戏和图形设计的高级框架,提供了一套丰富的功能来处理图形和动画。 |
DirectX
OpenGL 、OpenGL ES、WebGL 之间的关系
WebGL 的设计理念同源可以追溯到 1992 年 0penGL 1.0 发布时,更早则可追溯到 1980 年代 IRIS GL 的时代,这也意味着 WebGL 并不与现代 GPU 的设计理念匹配,导致了很多 CPU 和 GPU 性能问题,同时也使得现代浏览器厂商在现代化的本地 GPU API 之上对 WebGL 进行实现的工作变的愈发困难,WebGL 2.0 Compute 标准是一次为 WebGL 添加通用计算功能的尝试,但是因为与本地 API 的不匹配导致这次努力异常的困难,所以导致苹果的Safari到21年才开始支持WebGL 2.0 的 API。
对于2.0中发布的OffscreenCanvas,Safari 在22年的版本中部分支持,直到23年9月发布的版本中才完全支持
走向衰落的 OpenGL
- 当年力挺 HTML5 并唾弃 Flash 的 Apple,在 Jobs 故去后,也抛弃了 OpenGL 这一开放标准,自立门户研发推出了全新的 Metal 图形框架
- 事实上,WebGL 现在并不运行在 OpenGL 上,由于 ANGLE 的存在,实现了 WebGL 与本地 API 的转换实现(尽管非常难)
WebGL通常通过一个名为ANGLE(Almost Native Graphics Layer Engine)的中间层来实现与底层图形硬件的通信。ANGLE项目的目标是让WebGL内容能够在各种设备上运行,无论这些设备支持的是OpenGL还是其他图形API。它主要将WebGL调用转换为适合设备图形驱动的原生图形API调用。在Windows上,例如,ANGLE可能会将WebGL调用转换为DirectX调用,因为DirectX是Windows上的主要图形API。这种转换让WebGL能够在不直接支持OpenGL或OpenGL ES的平台上运行,从而增强了其跨平台的兼容性。
- 而 WebGL 的拥有者,Khronos Group 也逐渐放弃了 OpenGL 这一 WebGL 标准的基础,全力打造现在的明星产品 Vulkan 标准,通过下面这幅图看一下OpenGL和Vulkan之间的区别
在左侧是OpenGL ES的架构,显示了它在应用程序和GPU之间有一个高级别的驱动程序抽象层。这个抽象层负责许多复杂的任务,包括上下文管理、内存分配、GLSL(OpenGL Shading Language)编译以及错误检测。这表明,在OpenGL ES中,驱动程序承担了很多工作,从而简化了应用程序的开发,但这也可能导致一些性能开销,因为驱动程序必须处理更多的抽象层任务。
在右侧是Vulkan的架构,它被描述为具有一个"薄驱动程序"(Thin Driver),意味着它的驱动层更轻量,不像OpenGL ES那样进行大量的抽象。在Vulkan中,应用程序负责更多的任务,包括内存分配、线程管理、命令缓冲区的多线程生成以及多队列工作提交。这种设计允许应用程序更好地控制资源和执行,从而潜在提高性能,尤其是在多核心处理器上。然而,这也意味着对开发者而言,使用Vulkan需要写更多的代码和管理更多的底层细节。
总的来说,这幅图表明Vulkan旨在给予开发者更多的控制权以提高性能,而OpenGL ES则提供了一个更高级的、易于使用的抽象层,但可能牺牲了一些性能和控制力。
图形行业格局:从龙虎斗到三足鼎立
Vulkan
Vulkan 是一种跨平台的图形和计算API,由Khronos Group开发和维护。它设计成为一个低开销、高性能的API,为硬件提供直接的、细粒度的控制,从而实现跨多个操作系统和设备类型的图形和计算应用的标准化。以下是Vulkan如何实现跨平台能力的几个关键方面:
- 统一的API规范: Vulkan 提供了一个统一的API规范,这意味着无论在哪个平台上,API的功能和表现形式都是一致的。这允许开发者编写一次代码,然后在支持Vulkan的任何平台上运行。
- SPIR-V中间语言: Vulkan使用SPIR-V作为它的着色语言中间表示,这是一种标准化的二进制中间语言,使得开发者可以编写着色器代码,然后将其编译成一个跨平台的中间形式。这意味着相同的着色器代码可以在不同的硬件平台上执行,而不需要为每个平台单独编写或优化代码。
- 驱动程序和平台支持: 各个硬件供应商负责为他们的设备提供Vulkan驱动程序,确保Vulkan API可以在他们的硬件上运行。这包括从桌面GPU到移动设备的广泛硬件。
- 扩展机制: Vulkan有一个强大的扩展机制,允许硬件供应商引入新的特性和功能,而不会打破现有的规范。这些扩展可以是跨平台的,也可以是特定于供应商的,提供了额外的灵活性,以充分利用特定平台的特性。
- 分层架构: Vulkan的设计允许在驱动程序之上使用层。这些层可以添加功能、执行验证、记录调用等,而不会影响驱动程序本身。这种架构使得跨平台工具和中间件的创建成为可能,增加了在不同平台上实现一致性的能力。
- 社区和开源生态系统: Vulkan享有一个活跃的社区和开源生态系统,提供工具、库和支持,以帮助开发者更容易地为不同的平台开发和优化他们的应用程序。
- MoltenVK和其他封装: Vulkan API在某些平台(如macOS和iOS)上通过封装层(如MoltenVK)间接支持。MoltenVK允许Vulkan调用被转换为Metal调用,这是苹果的图形API,从而实现在苹果平台上的跨平台支持。
通过这些方法,Vulkan实现了真正的跨平台功能,为开发者提供了一个统一和高效的方式来开发高性能的图形和计算应用。
web 图形API新宠儿------WebGPU
WebGPU 是一种正在开发中的Web标准,由W3C的GPU for the Web工作组负责推进。它旨在为现代Web应用程序提供一种更高效、更强大的方式来访问图形和计算功能,特别是在GPU上。
WebGPU的主要特点和优势:
- 低级别的硬件抽象: WebGPU提供了一个低级别的API,允许开发者更接近硬件层面进行编程。这种低级别的控制可以提高性能,尤其是在复杂的图形和计算工作负载中。
- 跨平台: 它旨在支持多种平台,无论底层系统使用的是DirectX、Vulkan还是Metal,WebGPU 都能运行。这提供了一个统一的API,可以在不同的操作系统和设备上工作。
- 安全和隔离: 与WebGL相比,WebGPU更注重提供一种安全的环境,以防止恶意网站访问敏感信息。WebGPU的设计考虑到了安全性,从而限制了与GPU的交互可能导致的潜在问题。
- 现代特性支持: WebGPU被设计来支持现代GPU的特性,包括计算着色器、存储缓冲区和纹理压缩等,这使得它能够处理更复杂的渲染任务和高级视觉效果。
- 更好的性能: 由于提供了对GPU更直接的控制,WebGPU能够提供比WebGL更高的性能,特别是在涉及多线程和大量并行计算的任务中。
- 统一的着色语言: WebGPU将使用一种统一的着色语言,这将简化开发过程,因为开发者只需学习和使用一种语言就可以开发跨平台的Web应用程序。
- API的设计: WebGPU API的设计是为了易用性和性能的平衡。它的API设计旨在避免常见的性能陷阱,同时提供足够的灵活性来实现复杂的图形技术。
webGl vs WebGPU
这是复杂场景的渲染性能对比。这个场景中有 1000 棵树,它们不是使用实例化绘制的,而是每一棵树都有一个 draw call,所以一个场景我要有 1000 多个 draw call。如果使用 WebGL 进行绘制的话,可以看到,使用 2070 显卡只能跑到 21FPS,而且每一帧的 CPU 时间需要 44 毫秒,但是同样用 WebGPU 来处理,可以跑到 123 帧,每一帧的 CPU 时间只有 0.1 毫秒,这个是 WebGPU 和 WebGL 最大最显著的性能上的差距。
另外就是一个代码上的差距。用 WebGL 原生 API 绘制的过程,所有的东西的起点都在于 Canvas;然而这是一件很不可思议的事情,就是即使不需要画什么东西,用户也需要创建一个 Canvas 元素,这个操作对于前端可能是无感知的,但是对于浏览器开发者来说就要新建一个 DOM 元素,要给它增加所有它需要有的东西,一旦 DOM 元素崩溃了,浏览器要处理所有这些事情,对于开发者而言后面的事情就会变得非常复杂。
但是 WebGPU 不是这样,WebGPU 的入口是 navigator.gpu,用户可以从这里获取到一个显卡,再从显卡获取到一个设备,而中间的 Canvas 是没有的。