Mac 上的 OpenGL 4.3：为什么它对 CAD、GIS 和专业 Windows 应用程序至关重要

在 Apple Silicon Mac 上运行的 Windows 应用程序与 Mac GPU 的通信方式，不同于其在传统 Windows 工作站上的方式。

应用程序可能会发出 OpenGL 指令。Apple 的 GPU 是围绕 Metal 设计的。虚拟化平台必须弥合这一差距，既要保留应用程序所期望的图形行为，又要将转换开销保持在交互式工作可接受的范围内。

这正是 Parallels Desktop 27 中最重要的变化之一背后的工程难题：在 Windows 虚拟机中支持 OpenGL 4.3，该支持由 Apple 的 Metal 框架提供。

根据 Parallels 的测试，新的图形架构在搭载 Apple M3 芯片及更新版本的 Mac 上，OpenG L性能提升高达 2.6 倍。在 ArcGIS Pro 测试中，3D 渲染速度提升高达 35%，测试工作流完成速度比 Parallels Desktop 26 快高达24%。

版本号只是故事的一部分。OpenGL 4.3 引入了图形和计算能力，许多专业渲染引擎可以利用这些能力处理更大的数据集、更高效地提交复杂场景，并将合适的工作从 CPU 转移到 GPU。

对于从事地图、地形、工程模型、建筑设计、仿真结果或其他图形密集型 Windows 应用程序工作的人来说，这影响的不仅仅是基准测试分数。它可以改变视口的响应流畅度，并扩大能够在虚拟机中正常运行的应用程序功能范围。

什么是 OpenGL？

OpenGL 是 Open Graphics Library（开放图形库）的缩写，是由 Khronos Group 维护的跨平台图形 API。

API 是软件组件之间进行通信的明确定义方式。在这种情况下，OpenGL 为应用程序提供了一组标准指令，用于请求 GPU 绘制和处理图形。

专业应用程序可能使用这些指令来：

• 绘制 CAD 模型中的几何图形
• 在 3D 地图中渲染高程和影像
• 显示建筑信息模型的组件
• 为工程仿真结果着色
• 在用户平移、缩放或旋转场景时更新视口

应用程序不需要了解物理 GPU 的每一个底层细节。它通过 OpenGL 描述所需的工作，图形驱动程序将该工作映射到可用的硬件。

OpenGL 在工作站和技术软件中已有数十年的应用历史。其长期存在之所以重要，是因为专业应用程序通常包含围绕特定 OpenGL 功能构建和测试的成熟渲染系统。

为什么 OpenGL 版本很重要？

OpenGL 版本不同于常规的应用程序更新——后者较高的版本号主要意味着改进或界面变化。

新的 OpenGL 版本会添加编程能力。应用程序只有在图形环境提供所需版本或扩展时，才能使用某项功能。

Khronos 于 2012 年发布的 OpenGL 4.3 增加了多项与数据密集型和对象密集型渲染相关的功能，包括计算着色器、着色器存储缓冲对象和多绘制间接指令。Khronos将这些能力描述为利用GPU并行性进行计算、允许着色器读写更大量数据以及更高效地提交多个绘制操作的方式。

仅有强大的 GPU 是不够的。驱动程序和虚拟化层还必须向应用程序提供所需的 API 功能。

OpenGL 4.3 增加了什么？

OpenGL 4.3 的实际重要性来自于其功能允许渲染引擎将工作放到 GPU 上执行。

并非每个应用程序都使用每项功能，具体实现因产品而异。不过，有三项新增功能有助于解释为什么迁移到 OpenGL 4.3 对专业软件意义重大。

Mac 上 GPU 加速 Windows 应用程序的计算着色器支持

顶点着色器和片段着色器各自处理图形管线中已定义的部分。计算着色器的工作方式不同。应用程序可以使用它们将并行处理任务发送到GPU，而无需将该工作绑定到特定的渲染阶段。软件可能将计算着色器用于图像处理、几何计算、仿真或数据可视化。具体工作负载取决于开发人员构建应用程序的方式。

计算着色器的支持之所以重要，是因为一些专业 Windows 应用程序期望获得 OpenGL 4.3 的功能集。当应用程序被设计为使用 GPU 计算时，它可以将合适的工作划分为许多相似的操作并并行处理。这可以提高兼容性，并可能提升这些特定任务的性能。但并非所有计算都会变快。某些工作负载更适合CPU，且结果因应用程序而异。

着色器存储缓冲对象

着色器存储缓冲对象（通常称为 SSBO）为着色器提供了对大数据块的读写访问权限。应用程序可以使用 SSBO 来存储场景信息、几何数据、仿真值或需要多个着色器操作访问的中间计算结果。与统一缓冲对象相比，SSBO 支持更大的最小缓冲区大小，并允许着色器修改存储的数据。

该能力在处理复杂模型或大型数据集的应用程序中非常有用。当应用程序设计为将工作数据保留在 GPU 上时，它还可以减少不必要的数据移动。 SSBO 在 OpenGL 4.3 中成为核心功能。对用户而言，实际意义在于应用程序兼容性：当虚拟化平台支持此功能时，依赖此功能的 Windows 软件可以访问所需的 OpenGL 编程模型。

多绘制间接

一个复杂的技术场景可能包含数千个独立对象。为每个对象发出单独的绘制请求会消耗大量 CPU 时间，即使 GPU 可以快速渲染几何体。

多绘制间接允许渲染引擎将多个绘制操作的参数存储在缓冲区中，并通过一次 API 调用提交整个列表。Khronos 指出，这在渲染许多三角形数量相对较少的对象时尤其有用。

这可以减少由 CPU 处理的命令提交工作量。它并不保证特定的帧率提升，因为应用程序设计和场景组成仍然很重要，但它为开发人员提供了一条更高效的处理对象密集型场景的路径。

为什么这是一个困难的虚拟化问题

在传统的 Windows 工作站上，应用程序将图形指令发送到为已安装的图形硬件开发的 Windows GPU 驱动程序。

在 Apple Silicon Mac 上的 Windows 虚拟机则有不同的配置。

Windows 应用程序看到的是一个虚拟图形设备。Mac 的物理 GPU 通过 Apple 的图形栈进行管理，其中 Metal 是高性能图形和计算工作的主要 API。

Apple 在 macOS 10.14 中弃用了 OpenGL，并建议新的高性能 GPU 开发使用 Metal。 OpenGL 在包括 Apple Silicon 在内的当前 macOS 系统上仍然可用，但已被弃用，并未获得与 Metal 同等的平台投入。

因此，Parallels Desktop 不能将 Mac 视为包含带有供应商提供的 Windows 驱动程序的常规 Windows GPU。它必须向来宾操作系统提供适当的图形接口，并将产生的工作映射到主机上的 Metal。

简化的路径如下所示：

Windows 应用程序 → 虚拟机中的 OpenGL 驱动程序 → Parallels 虚拟图形架构 → Metal → Apple Silicon GPU

每个箭头背后都隐藏着工程工作。

图形 API 转换并不是一种指令语言到另一种的逐字替换。OpenGL 和 Metal 在资源管理、命令提交、同步、着色器行为和图形状态方面采用不同的方法。

转换层必须保留 Windows 应用程序所期望的结果。它还需要避免不必要的复制、重复的状态变更以及 CPU 绑定的命令处理。否则，转换开销可能会消耗掉使用 GPU 所获得的大部分性能。

Parallels Desktop 27 的变化

Parallels Desktop 27 引入了专为 Apple Silicon 设计的新图形驱动程序架构，并为 Windows 虚拟机增加了 OpenGL 4.3 支持。

这一变化有两个相互关联的目标。

首先是兼容性。暴露更新的 OpenGL 功能集允许应用程序找到先前在虚拟环境中不可用的图形能力。

其次是执行效率。 Metal 驱动的架构旨在将更多合适的图形工作传递给 Apple GPU，同时降低与处理及提交该工作相关的 CPU 成本。

这些改进相互促进。如果某项功能的实现速度太慢而无法正常使用，那么支持该功能的价值是有限的。如果因为缺少必需的能力而导致应用程序拒绝激活其渲染路径，那么快速的转换层也无能为力。

更好的 GPU 利用率

GPU 利用率描述了应用程序的图形工作负载在多大程度上有效地到达并占用 GPU。低利用率并不总是意味着 GPU 性能弱。处理器可能在等待 CPU 准备工作、等待数据被复制，或者等待图形指令通过多个软件层。

通过改进 Windows 中 OpenGL 操作与 macOS 上 Metal 操作之间的映射，新架构可以让更多合适的工作留在 GPU 上。这在交互式应用程序中很重要，因为绘制一帧只是工作负载的一部分。系统可能还需要更新场景数据、处理可见性、准备绘制命令、编译或选择着色器以及协调内存访问。

更低的 CPU 开销

CPU 仍然至关重要。它运行应用程序、处理操作系统工作、执行业务逻辑并准备场景的各个部分。当 CPU 花费过多时间转换或发出本可由 GPU 更高效处理的图形指令时，问题就会出现。

OpenGL 4.3 的功能（如多绘制间接）可以在使用它们的应用程序中减少部分命令提交压力。虚拟化图形管道的改进也可以降低转换和协调成本。

更低的 CPU 开销可能表现为界面响应更快、视口行为更稳定，或结合 CPU 和 GPU 工作的工作流完成更快。这不应被理解为普遍的性能倍增器。结果取决于应用程序、项目、虚拟机配置、Mac 型号和具体操作。

基准测试结果：Parallels Desktop 26 与 Parallels Desktop 27 对比

能力与架构对比

性能基准测试摘要

OpenGL 图形性能高达 2.6 倍

高达 160% 的提升意味着在表现最佳的测试案例中，测量结果达到了对比性能的 2.6 倍。这并不意味着每个 OpenGL 应用程序都变快了 160%。该数字反映的是整个图形栈的表现。促成因素可能包括扩展的 API 支持、更高效的 OpenGL 到 Metal 转换、更低的 CPU 开销以及更好地利用新一代 Apple GPU 架构。合成或聚焦的图形基准测试可以比完整的应用程序工作流更清晰地隔离这些改进。实际项目通常包含不受图形子系统影响的其他工作。

ArcGIS Pro 3D 渲染速度更快高达 35%

ArcGIS Pro 使用 GPU 来支持地图和场景的显示。Esri 的文档指出，ArcGIS Pro 主要使用 DirectX 进行渲染，尽管某些工作流和环境也可能使用 OpenGL，并建议在虚拟化环境中配置合适的 GPU 资源以保持流畅的地图和场景导航。渲染改进可以影响诸如重新绘制场景、更改相机位置、显示地形和呈现密集视觉图层等操作。具体收益将取决于场景。受数据加载、分析代码或远程服务限制的项目，其整体变化可能小于本地图形密集型 3D 场景。

ArcGIS Pro 工作流速度更快高达24%

工作流测试提供了更广泛的衡量标准，因为它包含的不只是绘制帧。ArcGIS Pro 工作流可能涉及加载内容、更改视图、导航场景、修改图层以及等待应用程序完成一系列操作。某些步骤可以直接受益于图形改进；其他步骤仍然依赖于 CPU、存储、可用内存或数据源。在重复性工作中，时间减少 24% 可能意义重大。作为参考，之前需要 100 秒的测试序列，在最大报告改进下大约需要 76 秒。该计算用于说明百分比，而非承诺客户项目的具体时间节省。

立即开始 Parallels Desktop 免费试用。

OpenGL 4.3 如何改善 Mac 上的 GIS 应用程序

GIS 应用程序在单一视图中结合了多种高要求的数据类型。

一个 3D 场景可能包含高程曲面、航拍影像、拉伸建筑物、标注、点云、矢量要素和分析叠加层。不同的图层可能需要不同的渲染技术和细节级别。

用户在平移、缩放、倾斜或切换图层时，还期望视图能够持续更新。

Esri 建议为流畅的地图和场景渲染（包括在虚拟化环境中）配置合适的 GPU 资源。

OpenGL 4.3 支持并不会让每个 GIS 操作都实现 GPU 加速。数据库查询、地理处理工具、Python 脚本、网络请求和许多分析任务可能仍然受限于 CPU、内存或 I/O。

最明显的收益应该出现在图形处理占总时间较大比例的工作中。例如导航详细的 3D 场景、重新绘制视觉密集的图层，以及处理经常更新视口的项目。

CAD 和工程应用程序的 OpenGL 4.3 兼容性

CAD 和工程软件通常处理的模型由许多独立对象、精确曲面、边线、材质、注释和显示状态组成。

在编辑过程中，用户期望获得即时的视觉反馈。旋转装配体时，应用程序必须从新角度重新绘制它。隔离某个组件时，显示会再次变化。启用剖面、着色、边线轮廓、透明度或分析叠加层时，渲染工作负载变得更加复杂。现代 GPU 可以并行处理大部分这类工作，但应用程序必须能够访问其渲染器所期望的图形功能。

OpenGL 4.3 引入了渲染引擎可用于管理更大数据集和更高效提交对象密集型场景的功能。特定 CAD 产品是否使用这些功能，需要与软件供应商确认，并使用确切的应用版本进行测试。

这种区别很重要。 API 支持为兼容性奠定了技术基础。它不等同于来自 Autodesk、Dassault Systèmes、Siemens 或其他独立软件供应商的认证。

在生产环境中部署 Windows 工程应用程序之前，团队应检查：

• 供应商支持的操作系统和图形要求
• 是否支持 Windows on Arm
• 插件和设备驱动程序依赖项
• 许可证管理器兼容性
• 认证要求
• 使用代表性项目文件的性能

Parallels Desktop 可以提供图形环境。应用程序供应商决定其官方支持和认证政策。

建筑和 BIM 应用程序的 OpenGL 4.3 支持

建筑模型对图形系统施加了自身的压力。

一个协调的 BIM 项目可能结合了建筑元素、结构组件、建筑服务、链接模型、注释和导入的几何体。模型通常从多个视角进行检查，而不是作为最终图像一次性渲染。图形响应能力影响日常操作，如围绕建筑旋转、隔离楼层、切换显示模式以及审查冲突或设计细节。

更强大的虚拟图形基础可以改善使用支持的 OpenGL 路径的应用程序和插件的体验。它还可以扩大能够初始化其预期渲染器而非选择降级功能路径的程序集。

特定应用的结果可能有所不同，因为建筑和 BIM 工具并不都使用相同的图形引擎或遵循相同的支持模型。有些主要依赖 DirectX 进行视口渲染，而另一些则混合使用多种图形 API，或依赖 OpenGL 实现特定功能和组件。

仿真和科学可视化的 OpenGL 4.3支持

仿真工作通常分为两个阶段。

求解器计算结果。后处理将结果转换为工程师可以检查的形式。

求解阶段可能主要依赖于 CPU、专门的 GPU 计算框架、内存带宽或远程计算集群。 OpenGL 支持不会自动加速该计算。

可视化则不同。显示大型有限元网格、矢量场、瞬态动画或彩色映射结果，可能对图形管线提出很高要求。OpenGL 4.3 功能可以为可视化软件提供更强大的工具来管理结果数据并在 GPU 上运行并行操作。实际行为取决于后处理器及其使用的代码路径。

为什么 OpenGL 4.3 兼容性与性能同等重要？

性能数字吸引眼球，但 OpenGL 4.3 支持也是一个兼容性里程碑。

当所需的 API 功能不可用时，检查该功能的应用程序可能会有多种表现。它可能会禁用一个效果、选择一个能力较弱的渲染器、拒绝打开 3D 视图、显示警告或无法启动。暴露所需功能可以让应用程序选择不同的路径。

这并不意味着每个需要 OpenGL 4.3 的程序现在都得到支持。应用程序还依赖于着色器语言行为、扩展、驱动程序特性、Windows 架构、系统库、许可组件和供应商测试的配置。

尽管如此，更新、更完整的 OpenGL 实现消除了一类主要限制。它为 Parallels 工程团队提供了一个更强大的基础，以便随着时间的推移测试和改进更多专业应用程序。

OpenGL 和 Metal 在虚拟机内部并非竞争关系

人们很容易将 OpenGL 和 Metal 视为相互竞争的技术。在这种架构中，它们服务于同一工作负载的不同方面。

Windows 应用程序使用 OpenGL，因为这是其渲染器构建时调用的接口。

Parallels Desktop 将该工作映射到 Metal，因为 Metal 是 Apple 当前用于高性能访问 Apple 设计 GPU 的 API。 Apple 鼓励原生 Mac 应用程序的开发人员从已弃用的 OpenGL 代码迁移到 Metal。 虚拟化产品不能要求每个 Windows 软件供应商为其应用程序重写以支持 Metal。 转换层允许现有的 Windows 渲染代码通过主机平台的首选图形框架使用 Mac 的 GPU。

这座桥梁是核心的工程成就。

部署专业应用程序前的实用指南

OpenGL 4.3 支持消除了一项重要的技术限制，但工作站规划仍需要测试。

• 使用代表性项目而非空文件。大型装配体、详细场景、密集图层、自定义着色器和第三方插件通常能暴露出简单启动测试无法发现的问题。
• 为虚拟机分配足够的内存，同时不影响 macOS。统一内存在系统间共享，因此为 Windows 分配更多内存并不总是更好。
• 保持 Parallels Tools 和应用程序为最新版本。图形修复可以独立于主要产品版本发布。
• 检查 Windows on Arm 兼容性。可能支持图形 API，但插件、内核驱动程序、许可组件或硬件集成却不支持。
• 审查供应商认证要求。在受监管或生产关键型环境中的组织，即使应用程序在虚拟机中正常运行，也可能需要经过官方认证的工作站配置。
• 衡量对您重要的工作流。帧率、场景加载时间、重绘速度、导出持续时间和端到端任务时间回答的是不同的问题。