NOTE： Designed by GPT-6 Astra Created by GPT-6.1 Sol

引言

在 WSL2 的 Ubuntu 20.04 中运行 ROS1，使用 RViz 可视化点云时，发现窗口交互明显卡顿。执行下面的命令检查 OpenGL：

glxinfo -B | grep -E 'Device:|Accelerated:|OpenGL renderer'

输出如下：

Device: llvmpipe (LLVM 12.0.0, 256 bits) (0xffffffff)
Accelerated: no
OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits)

这说明当前 OpenGL 使用的是 CPU 软件渲染。点云仍然可以显示，但大量绘制工作落在 CPU 上，成为卡顿的一个明确原因。

本次处理有两个前提：现有代码依赖 ROS1，需要继续使用当前 Ubuntu 20.04 环境；保留现有点云显示需求，不通过减少显示数据来绕开问题。

最终的解决方法是：将新版 glibc、C++ 运行库和配套动态加载器解包到用户目录，仅在启动 RViz 时使用这套库，让 Intel 的 WSL 图形驱动能够正常加载。 系统的 Ubuntu、ROS、Mesa 和基础库保持原来的版本。

这篇博客记录实际排查过程，包括为什么第一次补运行库仍然失败，以及最后的启动脚本如何工作。

博客开始前先给出验证的结果吧：

rviz-gpu --check

# name of display: :0
# display: :0  screen: 0
# direct rendering: Yes
# Extended renderer info (GLX_MESA_query_renderer):
#     Vendor: Microsoft Corporation (0xffffffff)
#     Device: D3D12 (Intel(R) Arc(TM) B390 GPU) (0xffffffff)
#     Version: 21.2.6
#     Accelerated: yes
#     Video memory: 48609MB
#     Unified memory: yes
#     Preferred profile: core (0x1)
#     Max core profile version: 3.3
#     Max compat profile version: 3.1
#     Max GLES1 profile version: 1.1
#     Max GLES[23] profile version: 3.0
# OpenGL vendor string: Microsoft Corporation
# OpenGL renderer string: D3D12 (Intel(R) Arc(TM) B390 GPU)
# OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.2.6
# OpenGL core profile shading language version string: 3.30
# OpenGL core profile context flags: (none)
# OpenGL core profile profile mask: core profile

# OpenGL version string: 3.1 Mesa 21.2.6
# OpenGL shading language version string: 1.40
# OpenGL context flags: (none)

# OpenGL ES profile version string: OpenGL ES 3.0 Mesa 21.2.6
# OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

rviz-gpu --check | grep -E 'Device:|Accelerated:|OpenGL renderer'
#     Device: D3D12 (Intel(R) Arc(TM) B390 GPU) (0xffffffff)
#     Accelerated: yes
# OpenGL renderer string: D3D12 (Intel(R) Arc(TM) B390 GPU)

问题分析

本机 Intel Arc B390 的 Windows WSL 驱动使用较新的 Linux 运行库。 逐层检查发现 libigd12umd64.so 要求 GLIBC_2.34， libigd12um64xe3.so 要求 GLIBC_2.38，libigdgmm_w.so.12 要求 GLIBCXX_3.4.32。 系统仍为 Ubuntu 20.04、glibc 2.31、Mesa 21.2.6。

启动器：~/.local/bin/rviz-gpu 生效运行库：~/.local/share/rviz-wsl-gpu/runtime-noble/ 只解包官方 .deb 到用户目录，没有通过 dpkg/apt 安装，没有修改系统库或 shell 配置。 旧的 runtime/ 和 runtime-2.39/ 是诊断过程中保留的试验目录，启动器不使用它们。

使用方式

先像平常一样 source ROS/workspace，然后运行：

rviz-gpu --check
rviz-gpu
rviz-gpu -d /home/kwanwaipang/GRG-Cortex-Omni/src/grgslam/config/grgslam.rviz

--check 应显示 Accelerated: yes 及 D3D12 (Intel(R) Arc(TM) B390 GPU)。 普通 glxinfo、rviz、rosrun rviz rviz 仍然使用系统运行库；专用启动器才启用修复。 若 PATH 未包含 ~/.local/bin，使用启动器的绝对路径即可。

roslaunch 中仅给 RViz 节点添加以下属性，保留原有 args 和显示配置：

launch-prefix="$(env HOME)/.local/bin/rviz-gpu"

若原属性是 launch-prefix="nice"，可以改为：

launch-prefix="nice $(env HOME)/.local/bin/rviz-gpu"

也可以不改项目 launch 文件：原来的 roslaunch grgslam slam_online.launch 命令 增加 rviz:=false，再在另一个已 source 工作空间的终端使用上面的 rviz-gpu -d ...。

一、先记录实际环境

本次排查使用的环境如下，版本以 2026 年 10 月 31 日的检查结果为准：

其中，glibc 和 libstdc++ 是后面定位问题的关键。不能只看到 Mesa 比较旧，就直接认定升级 Mesa 能解决。

1.1 查看 Linux 侧的信息

cat /etc/os-release
uname -r
getconf GNU_LIBC_VERSION

dpkg-query -W libc6 libstdc++6 libgcc-s1 libgl1-mesa-dri

printenv DISPLAY WAYLAND_DISPLAY XDG_RUNTIME_DIR
printenv LIBGL_ALWAYS_SOFTWARE MESA_LOADER_DRIVER_OVERRIDE GALLIUM_DRIVER

本机没有设置强制软件渲染的环境变量；显示变量中有 DISPLAY=:0 和 WAYLAND_DISPLAY=wayland-0。

1.2 查看 Windows 侧的显卡信息

在 Windows PowerShell 中执行：

Get-CimInstance Win32_VideoController |
    Select-Object Name, DriverVersion, DriverDate, Status |
    Format-List

结果确认显卡是 Intel Arc B390，驱动状态为 OK。

二、理解 WSLg 的 OpenGL 加速路径

WSLg 下的 OpenGL 加速可以简化为以下调用关系：

ROS1 RViz / OGRE
        |
        v
OpenGL / Mesa
        |
        v
Mesa D3D12 Gallium 驱动
        |
        v
WSL 的 Direct3D 接口和厂商用户态驱动
        |
        v
Windows GPU 驱动与 GPU

Microsoft 的 WSLg 文档说明，OpenGL 加速通过 Mesa 的 D3D12 Gallium 驱动实现；Mesa 的 D3D12 驱动会把相关图形操作转换为 Direct3D 12 API 调用。WSLg 官方说明、Mesa D3D12 文档

所以，修复后的渲染器显示成 D3D12 (Intel...) 是正常的，并不需要显示成原生 Linux 下的 Intel OpenGL 驱动名称。

这里还有两个容易误判的地方：

• direct rendering: Yes 本身不能证明启用了 GPU；本次软件渲染时，这一项同样是 Yes。
• llvmpipe 输出中的 256 bits 不能作为显卡已经参与渲染的依据。判断本次问题时，应结合渲染器名称和 Accelerated 字段。

三、确认 GPU 接口和 Mesa 驱动是否存在

首先检查 WSL 的 GPU 接口及相关库：

ls -l /dev/dxg

ls -l /usr/lib/wsl/lib/libdxcore.so
ls -l /usr/lib/wsl/lib/libd3d12.so
ls -l /usr/lib/wsl/lib/libd3d12core.so

ls -l /usr/lib/x86_64-linux-gnu/dri/d3d12_dri.so

ldconfig -p | grep -E 'dxcore|d3d12'

本机的 /dev/dxg 存在，WSL 提供的 Direct3D 库也存在，而且动态库缓存能够找到它们。Ubuntu 自带的 Mesa 21.2.6 已经包含 d3d12_dri.so。

这说明需要继续检查驱动的初始化过程，不能直接归因于“没有 GPU 接口”或“没有安装 D3D12 后端”。

排查时也遇到过受限执行环境无法连接 DISPLAY=:0、看不到实际 /dev/dxg 的情况。切换到能够访问实际 WSL 图形服务的终端后，接口正常存在。因此，受限终端中的访问失败，需要与 WSL 主环境中的设备缺失区分开。

四、强制使用 D3D12，找到被隐藏的加载错误

先启用 Mesa 的加载日志：

LIBGL_DEBUG=verbose glxinfo -B

再仅对当前命令指定 D3D12：

GALLIUM_DRIVER=d3d12 LIBGL_DEBUG=verbose glxinfo -B

第二条命令没有恢复加速，而是出现了：

libGL error: failed to create dri screen
libGL error: failed to load driver: swrast
X Error of failed request: BadValue

这些信息还不足以定位根因。虽然日志提到了 swrast，但不能仅凭这一行就认定是缺少软件渲染驱动。继续打开动态链接器的诊断信息：

GALLIUM_DRIVER=d3d12 LD_DEBUG=libs,versions \
    glxinfo -B > /tmp/glxinfo-loader.log 2>&1

grep -E 'not found|version lookup error|libigd|libdxcore|libd3d12' \
    /tmp/glxinfo-loader.log

这次终于出现了明确的错误：

version `GLIBC_2.32' not found
(required by .../libigd12umd64.so)

加载器已经找到了 /usr/lib/wsl/lib/libdxcore.so、libd3d12.so 和 Windows 显卡驱动目录中的 libigd12umd64.so，但系统 glibc 缺少它要求的符号版本。

本机系统库是：

getconf GNU_LIBC_VERSION

glibc 2.31

还可以用 readelf 查看驱动声明的版本依赖。下面用通配符查找驱动文件，避免把本机特定的驱动目录后缀写死：

for driver in /usr/lib/wsl/drivers/iigd_dch.inf_amd64_*/libigd12umd64.so; do
    readelf --version-info "$driver" |
        grep -E 'Name: (GLIBC_|GLIBCXX_|CXXABI_)'
done

这一步发现主驱动还需要 GLIBC_2.34 和 GLIBCXX_3.4.29。因此，只补上报错中第一个出现的 GLIBC_2.32 并不够。

此时可以确定：本次硬件加速失败，至少存在 Intel WSL 用户态驱动与 Ubuntu 20.04 基础运行库不兼容的问题。

五、为什么第一次补运行库仍然失败

为了保留原系统，首先尝试从 Ubuntu 22.04 的官方软件包中提取 glibc 2.35 和较新的 C++ 运行库，放进用户目录，再通过配套加载器运行 glxinfo。

这次主驱动能够加载了，但继续加载 Xe3 驱动时又失败：

version `GLIBC_2.38' not found
(required by .../libigd12um64xe3.so)

于是改用 glibc 2.39。主驱动和 Xe3 驱动都通过后，显存管理库又报错：

version `GLIBCXX_3.4.32' not found
(required by .../libigdgmm_w.so.12)

整个过程可以整理成下面的表格：

这里的 GLIBC_* 来自 glibc；GLIBCXX_* 来自 libstdc++。两个名字相近，但对应不同的运行库。

这也解释了为什么只看第一条报错，很容易低估所需运行库的版本。Intel 图形驱动会继续动态加载其他组件，必须检查整条实际加载路径。

六、最终方案：给 RViz 配置独立运行库

最终使用三个 Ubuntu 官方软件包：

这些包来自 Ubuntu 24.04 的官方仓库，但这里只把文件解包到用户目录，没有把 Ubuntu 20.04 升级为 24.04，也没有在系统中安装这些跨发行版软件包。

最终生效的目录结构为：

~/.local/
├── bin/
│   └── rviz-gpu
└── share/
    └── rviz-wsl-gpu/
        ├── packages/
        ├── runtime-noble/
        │   └── usr/lib/x86_64-linux-gnu/
        │       ├── ld-linux-x86-64.so.2
        │       ├── libc.so.6
        │       ├── libm.so.6
        │       ├── libstdc++.so.6
        │       └── libgcc_s.so.1
        └── logs/

runtime-noble 只是便于识别软件包来源的目录名，系统发行版仍然是 Ubuntu 20.04。

6.1 下载官方软件包

下面保留本次实际使用的版本，便于复现。后续版本可能变化，可以先查看 libc6 下载页、libstdc++6 下载页 和 libgcc-s1 下载页，核对文件名与 SHA256。

这些命令应在 Ubuntu 20.04 的 Bash 中执行，下载的包是 amd64 架构：

rviz_gpu_base="$HOME/.local/share/rviz-wsl-gpu"
mkdir -p "$rviz_gpu_base/packages" "$rviz_gpu_base/runtime-noble"
cd "$rviz_gpu_base/packages"

curl -fL --connect-timeout 15 --max-time 60 \
    -o libc6-noble.deb \
    'https://security.ubuntu.com/ubuntu/pool/main/g/glibc/libc6_2.39-0ubuntu8.9_amd64.deb'

curl -fL --connect-timeout 15 --max-time 60 \
    -o 'libstdc++6-noble.deb' \
    'https://security.ubuntu.com/ubuntu/pool/main/g/gcc-14/libstdc++6_14.2.0-4ubuntu2~24.04.1_amd64.deb'

curl -fL --connect-timeout 15 --max-time 60 \
    -o libgcc-s1-noble.deb \
    'https://security.ubuntu.com/ubuntu/pool/main/g/gcc-14/libgcc-s1_14.2.0-4ubuntu2~24.04.1_amd64.deb'

下载之后核对 SHA256，下面的值对应上述三个固定版本：

sha256sum --check <<'EOF'
ff5557d99b51f761c4b7c92368b9cc45565eda17df9bf9eb4b134d09825008be  libc6-noble.deb
a51f8de7829211db961a31f02158058ad1a95f92ac6d0a5dff6350e2821c54c0  libstdc++6-noble.deb
aa7fadbe33b78bcf99885318040601c550c208929565b179891d9a3cc2aa68cd  libgcc-s1-noble.deb
EOF

三项都显示 OK 后，再继续解包。如果更换软件包版本，也要同步更新对应的官方 SHA256。

NOTE：

软件包与下载元数据保存在 packages/。这些独立库不由系统 apt 自动更新。

6.2 只提取文件，不安装到系统

继续在同一个终端执行：

dpkg-deb -x libc6-noble.deb "$rviz_gpu_base/runtime-noble"
dpkg-deb -x 'libstdc++6-noble.deb' "$rviz_gpu_base/runtime-noble"
dpkg-deb -x libgcc-s1-noble.deb "$rviz_gpu_base/runtime-noble"

这里使用的是 dpkg-deb -x，只提取软件包里的文件。整个步骤不需要 sudo，也不执行软件包安装脚本，不会把这三个包登记为系统已安装版本。

不要把这一步改成 sudo dpkg -i，也不要手动覆盖 /lib/x86_64-linux-gnu/libc.so.6。本次方案依赖“保留系统运行库、显式选择独立运行库”这一点。

6.3 先用独立加载器运行 glxinfo

rviz_gpu_runtime="$HOME/.local/share/rviz-wsl-gpu/runtime-noble/usr/lib/x86_64-linux-gnu"

"$rviz_gpu_runtime/ld-linux-x86-64.so.2" \
    --library-path "$rviz_gpu_runtime:/usr/lib/wsl/lib" \
    /usr/bin/glxinfo -B

这次实际得到的输出是：

Vendor: Microsoft Corporation (0xffffffff)
Device: D3D12 (Intel(R) Arc(TM) B390 GPU) (0xffffffff)
Version: 21.2.6
Accelerated: yes
OpenGL renderer string: D3D12 (Intel(R) Arc(TM) B390 GPU)
OpenGL version string: 3.1 Mesa 21.2.6

Mesa 仍然是原来的 21.2.6，但已经能够使用 GPU。 这说明本机此次回退到软件渲染的直接障碍，是驱动所需的运行库依赖，而不是必须先升级 Mesa。

七、为什么需要显式调用动态加载器

正常执行一个动态链接的 Linux 程序时，系统会按照 ELF 文件中记录的解释器路径启动动态加载器。仅把新版 libc.so.6 放在某个目录里，并不会自动让程序正确使用整套新版运行库。

本次做法是直接调用新版 glibc 自带的加载器：

独立的 ld-linux-x86-64.so.2
        |
        +-- 优先使用独立 glibc / libstdc++ / libgcc
        |
        +-- 加载系统中的 RViz、Qt、OGRE、Mesa
        |
        +-- 加载 WSL 提供的 Direct3D 接口和 Intel 驱动

加载器自身的帮助中可以看到：

"$rviz_gpu_runtime/ld-linux-x86-64.so.2" --help

其中 --library-path 用于为此次启动指定动态库搜索路径，--argv0 用于设置被启动程序看到的 argv[0]。

之所以使用 --library-path，而不把新版 glibc 路径全局写入 .bashrc 的 LD_LIBRARY_PATH，是为了把影响限制在这次启动的程序。若把新版 glibc 路径导出给所有后续程序，它们仍可能通过系统旧加载器启动，形成加载器和 glibc 混用的问题。

需要准确理解这里的“独立”：它是为一个进程显式选择部分运行库，并不是容器或完整的新发行版。RViz 仍然会使用系统中的其他依赖，所以最终还需要用实际 RViz 验证兼容性。

八、封装成 rviz-gpu 启动脚本

为了避免每次都输入一长串加载器参数，将最终启动逻辑保存到：

~/.local/bin/rviz-gpu

如果目录尚不存在，先执行 mkdir -p "$HOME/.local/bin"。

下面是本次实际使用的完整脚本：

#!/bin/bash
# Private runtime for the Intel WSL graphics driver; system libraries stay intact.
set -e

runtime="$HOME/.local/share/rviz-wsl-gpu/runtime-noble/usr/lib/x86_64-linux-gnu"
loader="$runtime/ld-linux-x86-64.so.2"
if [[ ! -x "$loader" ]]; then
    echo "RViz GPU runtime not found: $loader" >&2
    exit 1
fi

if [[ "${1:-}" == "--check" ]]; then
    shift
    binary=/usr/bin/glxinfo
    set -- -B "$@"
else
    # Source the base ROS environment only if the caller has not sourced it.
    if [[ "${ROS_DISTRO:-}" != "noetic" ]]; then
        source /opt/ros/noetic/setup.bash
    fi
    binary=/opt/ros/noetic/lib/rviz/rviz
    # Also support roslaunch's launch-prefix, which supplies the executable.
    case "${1:-}" in
        /opt/ros/noetic/bin/rviz|/opt/ros/noetic/lib/rviz/rviz)
            binary="$1"
            shift
            ;;
    esac
fi

# --library-path applies to this executable; do not export a replacement glibc
# through LD_LIBRARY_PATH, which would break children using the system loader.
library_path="$runtime:/usr/lib/wsl/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
export GALLIUM_DRIVER=d3d12
exec "$loader" --argv0 "$binary" --library-path "$library_path" "$binary" "$@"

保存后赋予执行权限，并做一次 Bash 语法检查：

chmod +x "$HOME/.local/bin/rviz-gpu"
bash -n "$HOME/.local/bin/rviz-gpu"

这个脚本主要处理了以下几个问题：

1. --check 会用同一套独立运行库执行 glxinfo -B，方便确认硬件加速状态。
2. 正常启动时，执行的是原来的 ROS Noetic RViz 二进制。
3. 动态库搜索路径优先放置独立运行库和 /usr/lib/wsl/lib，再追加调用者已有的 ROS/workspace 库路径。
4. 仅在脚本进程中设置 GALLIUM_DRIVER=d3d12。它负责指定渲染后端，真正解决依赖问题的是配套运行库。
5. 通过 exec 交接给加载器，脚本进程不继续驻留，方便 roslaunch 管理节点生命周期。
6. 兼容 roslaunch 的 launch-prefix 调用方式，能够识别 roslaunch 传入的 RViz 可执行文件路径。

对于项目自己的 RViz 插件，仍然应先像平常一样 source 工作空间。脚本只会在未检测到 Noetic 环境时补充基础 ROS 环境，不会自动判断应该 source 哪一个自定义工作空间。

九、独立启动与 roslaunch 的接入方式

9.1 直接启动 RViz

source /opt/ros/noetic/setup.bash

# 有自定义插件时，再 source 对应工作空间。
# source "$HOME/your_catkin_ws/devel/setup.bash"

"$HOME/.local/bin/rviz-gpu" --check
"$HOME/.local/bin/rviz-gpu"

加载原有的 .rviz 配置文件：

"$HOME/.local/bin/rviz-gpu" -d /path/to/your/config.rviz

如果 ~/.local/bin 已经在 PATH 中，就可以直接输入 rviz-gpu。

9.2 在 roslaunch 中使用

给原有 RViz 节点增加 launch-prefix，保留原来的参数和显示配置。例如：

<node pkg="rviz" type="rviz" name="rviz"
      launch-prefix="$(env HOME)/.local/bin/rviz-gpu"
      args="-d $(find your_package)/config/your_config.rviz"/>

其中 your_package 和配置文件路径应替换为原项目实际内容。

如果原节点已经使用 nice，可以组合：

launch-prefix="nice $(env HOME)/.local/bin/rviz-gpu"

roslaunch 会把 RViz 可执行文件和节点参数传给前缀命令。脚本识别并移除这个可执行文件参数，然后使用独立加载器启动原来的 RViz，后续参数继续原样传递。

本次修复没有直接修改项目 launch 文件。另一种使用方法是让项目关闭自动启动的 RViz，再单独运行 rviz-gpu -d ...。例如本机项目已有 rviz 开关参数，可以使用 rviz:=false；其他项目是否支持这个参数，需要检查其 launch 文件。

十、验证不能只停留在 glxinfo

glxinfo 恢复加速之后，还实际启动了 ROS1 RViz，确认 Qt、OGRE、Mesa 和 Intel 驱动能够共同工作。

本次验证使用独立 ROS master，避免依赖正在运行的项目。测试脚本创建了一个临时 .rviz 配置，订阅固定坐标系为 map 的 sensor_msgs/PointCloud2，并发布合成点云。

RViz 的实际日志包含：

rviz version 1.14.26
compiled against Qt version 5.12.8
compiled against OGRE version 1.9.0 (Ghadamon)
GL_RENDERER = D3D12 (Intel(R) Arc(TM) B390 GPU)
OpenGL device: D3D12 (Intel(R) Arc(TM) B390 GPU)
OpenGl version: 3.1 (GLSL 1.4).

也检查了 RViz 进程的 /proc/<pid>/maps，确认相关 Intel 驱动文件实际加载到了 RViz 进程中。

本机保留的验证日志位于：

~/.local/share/rviz-wsl-gpu/logs/rviz-test-20261031-215712/rviz.log

如果要查看自己后续运行时的渲染器，可以在启动 RViz 时启用 OGRE 日志：

"$HOME/.local/bin/rviz-gpu" -l -d /path/to/your/config.rviz

这里需要明确测试结果的边界：10 Hz 是合成点云的发布频率，不是测得的 RViz 渲染帧率。 本次没有测量真实项目的 FPS、丢帧率或性能提升倍数，也没有运行实际 SLAM 算法、回放真实 rosbag 或逐一验证自定义插件。已经确认的是：CPU 软件渲染问题被修复，ROS1 RViz 能使用 GPU 并保持接收测试点云。

十一、为什么普通 glxinfo 仍然可能显示 llvmpipe

本次修复只通过专用启动器生效，所以检查时需要区分：

因此，普通 glxinfo 继续显示 llvmpipe，并不代表专用启动器失效。应使用 rviz-gpu --check，并结合实际 RViz 的渲染器日志确认。

修复后再次检查系统软件包，仍然得到：

glibc 2.31
libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.2
libstdc++6 10.5.0-1ubuntu1~20.04

如果需要停用这套方案，改回原来的启动方式，并去掉新增的 launch-prefix 即可；系统库本身不需要恢复。

独立提取的运行库不会由系统 apt 自动更新。以后 Windows 显卡驱动更新后，若又出现加载失败，应重新查看 LD_DEBUG=libs,versions 的输出，核对新增的符号版本要求。本次的三个包和脚本是在上述机器及版本组合下验证通过的方案，其他硬件或插件组合仍需要实际验证。