1. 为什么要在 Ubuntu 18.04 上折腾 OpenGL ES1.1 这个环境到底解决什么问题先把话说清楚OpenGL ES 不是桌面 OpenGL它是为嵌入式、移动端、以及各种 GPU 计算场景准备的精简版图形 API。你在 Android、iOS、各种车机、机顶盒、甚至一些国产 SoC 上看到的渲染管线底层基本都是 OpenGL ES。那为什么要在 Ubuntu 18.04 这种桌面系统上搭它原因很直接——很多做图形中间件、Shader 调试、GPU 驱动验证、跨平台渲染引擎的团队开发阶段就是在 Linux 桌面上跑 OpenGL ES 的模拟环境验证完再交叉编译到目标板子上。Ubuntu 18.04 LTS 这个版本虽然现在看有点老但它在工业界和芯片原厂 SDK 里依然是主力。很多 GPU 厂商的 BSP 包、Mali 驱动、PowerVR 工具链默认适配的就是 18.04 的 glibc 和 X11 环境。你如果直接上 20.04 或 22.04反而会遇到一堆依赖版本对不上的破事。所以这个标题里的“极度舒适”核心诉求就是用最少的踩坑把 OpenGL ES 的编译、链接、运行、调试链路一次性打通。适合谁看三类人第一类是做嵌入式图形开发的需要在 PC 上先跑通渲染逻辑第二类是做 Shader 效果验证的不想每次都烧到板子上看结果第三类是学生或转行者想学 OpenGL ES 但被环境配置卡在门外。这篇文章会把每一步的“为什么”讲透让你不仅配得出来还知道每个包是干嘛的。1.2 整体思路桌面模拟 交叉验证搭建思路其实就两条路一条是用 Mesa 的软件渲染或硬件加速来模拟 OpenGL ES另一条是直接用 GPU 厂商提供的模拟器。Mesa 是开源图形栈里最稳的选择它提供了libGLESv2和libEGL的完整实现能在没有真实 ES 硬件的情况下把 ES 的调用翻译成桌面 OpenGL 或 Vulkan 来执行。我选的是 Mesa 路线原因是零成本、可调试、和真实 ES 行为足够接近。你不需要买开发板不需要厂商账号一条apt install就能把运行时装好。后面如果要上真实硬件代码层面几乎不用改只需要换链接库和交叉编译工具链。这个方案的优势在于“先软后硬”把逻辑 bug 和渲染 bug 分开解决效率高很多。注意Ubuntu 18.04 默认的 Mesa 版本是 18.x对 OpenGL ES 3.2 的支持是完整的但如果你要用 ES 3.2 的高级特性比如 compute shader建议手动升级到 Mesa 20 以上。这个后面会讲怎么处理。2. 环境搭建前的依赖梳理与工具选型2.1 核心依赖包逐个拆解很多人配环境失败不是因为命令敲错而是根本不知道每个包在链路里的位置。我把关键依赖分成四层编译层、运行时层、窗口系统层、调试层。编译层需要build-essential、cmake、pkg-config。这三个是基础中的基础pkg-config特别重要它负责在编译时告诉编译器去哪里找libGLESv2.so和头文件路径。没有它你就得手动写-I和-L项目一复杂就崩。运行时层是libgles2-mesa-dev、libegl1-mesa-dev、libglm-dev。前两个提供 ES 和 EGL 的头文件与链接库glm是数学库做矩阵变换必备。这里有个坑Ubuntu 仓库里libgles2-mesa-dev和libgles2-mesa是两个包前者带头文件后者只有运行时。你如果只装后者编译时就会报GLES2/gl2.h: No such file。窗口系统层需要libx11-dev、libxrandr-dev、libxi-dev、libxcursor-dev。EGL 在 Linux 上要通过 X11 创建 surface这些是 X11 的开发头文件。如果你用 Wayland包名会不一样但 18.04 默认还是 X11所以按这个来。调试层推荐mesa-utils、libgl1-mesa-dri、apitrace。mesa-utils里的es2_info能直接打印当前 ES 上下文的信息验证环境是否生效特别方便。apitrace可以抓帧分析每一帧的 GL 调用调 Shader 的时候是神器。依赖包所属层级核心作用是否必装build-essential编译层提供 gcc/g/make必装cmake编译层跨平台构建工具必装pkg-config编译层自动解析库路径必装libgles2-mesa-dev运行时层ES 头文件与链接库必装libegl1-mesa-dev运行时层EGL 头文件与链接库必装libglm-dev运行时层矩阵/向量数学库推荐libx11-dev窗口层X11 基础开发库必装libxrandr-dev窗口层分辨率与显示模式必装mesa-utils调试层es2_info 等诊断工具推荐apitrace调试层GL 调用抓帧分析可选2.2 为什么不用厂商模拟器有人会问Mali 有 Offline CompilerPowerVR 有 PVRTrace为什么不直接用我的经验是厂商工具适合做最终验证不适合日常开发。原因有三第一厂商工具通常绑定特定驱动版本换个 GPU 就废第二它们的调试信息不如 Mesa 透明出问题只能看日志猜第三很多厂商工具在 Linux 桌面上的安装包年久失修依赖冲突比 Mesa 还多。Mesa 的另一个好处是源码开放你遇到诡异行为可以直接看实现。比如 EGL 创建上下文失败你可以加MESA_DEBUG1环境变量它会打印详细的错误原因。这种透明度在排查问题时价值极高。3. 从零开始的完整实操流程3.1 系统更新与基础包安装第一步永远是更新源但 18.04 的默认源现在可能有点慢建议先换成国内镜像。编辑/etc/apt/sources.list把archive.ubuntu.com替换成mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn。换完执行sudo apt update sudo apt upgrade -y升级完重启一次确保内核和驱动状态干净。然后装基础编译工具sudo apt install -y build-essential cmake pkg-config git这里有个细节build-essential会带入gcc-718.04 默认就是 7.x对 C14 支持完整。如果你要用 C17 的std::filesystem需要额外装g-8并手动切换但 OpenGL ES 开发一般用不到保持默认即可。3.2 OpenGL ES 与 EGL 开发库安装核心命令如下sudo apt install -y libgles2-mesa-dev libegl1-mesa-dev libglm-dev sudo apt install -y libx11-dev libxrandr-dev libxi-dev libxcursor-dev sudo apt install -y mesa-utils apitrace装完后验证头文件是否存在ls /usr/include/GLES2/gl2.h ls /usr/include/EGL/egl.h两个文件都在说明开发库就位。接着验证运行时es2_info如果输出里能看到EGL_VERSION、GL_VERSION、GL_RENDERER并且 renderer 显示Mesa或你的显卡型号说明 EGL 已经能正常创建上下文。这一步是整个搭建过程中最关键的验证点过了这关后面基本不会有大问题。提示如果es2_info报failed to create context先检查是不是在纯 SSH 环境下运行。EGL 需要 X11 displaySSH 默认没有你需要ssh -X或者直接在桌面终端里跑。3.3 编写第一个 ES 渲染程序光装库不算完得跑通一个真实渲染才能确认链路完整。我写一个最小化的三角形渲染程序包含 EGL 初始化、Shader 编译、绘制三个核心环节。先建目录结构mkdir -p ~/gles_demo/src cd ~/gles_demosrc/main.cpp的核心逻辑分四步。第一步EGL 初始化EGLDisplay display eglGetDisplay(EGL_DEFAULT_DISPLAY); eglInitialize(display, nullptr, nullptr); const EGLint configAttribs[] { EGL_SURFACE_TYPE, EGL_PBUFFER_BIT, EGL_BLUE_SIZE, 8, EGL_GREEN_SIZE, 8, EGL_RED_SIZE, 8, EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT, EGL_NONE };这里用EGL_PBUFFER_BIT而不是窗口 surface原因是 pbuffer 不需要可见窗口适合自动化测试和后台渲染。如果你要显示到屏幕把 surface type 改成EGL_WINDOW_BIT然后用eglCreateWindowSurface绑定 X11 窗口。第二步创建上下文并设为当前EGLint contextAttribs[] { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE }; EGLContext context eglCreateContext(display, config, EGL_NO_CONTEXT, contextAttribs); eglMakeCurrent(display, surface, surface, context);EGL_CONTEXT_CLIENT_VERSION设为 2 表示 ES 2.0设 3 就是 ES 3.0。这个参数决定了你能用哪些 GLSL 版本写错了会在编译 shader 时报版本不匹配。第三步编译 shader。顶点 shader 就三行#version 100 attribute vec4 a_Position; void main() { gl_Position a_Position; }片段 shader 更简单#version 100 precision mediump float; void main() { gl_FragColor vec4(1.0, 0.5, 0.2, 1.0); }注意#version 100是 ES 2.0 的 GLSL 版本号ES 3.0 要写#version 300 es而且attribute要改成ingl_FragColor要改成自定义输出变量。这个差异是新手最容易翻车的地方。第四步绘制并读回像素glClearColor(0.1f, 0.1f, 0.1f, 1.0f); glClear(GL_COLOR_BUFFER_BIT); glDrawArrays(GL_TRIANGLES, 0, 3); glFinish(); std::vectorunsigned char pixels(256 * 256 * 4); glReadPixels(0, 0, 256, 256, GL_RGBA, GL_UNSIGNED_BYTE, pixels.data());glFinish不能省否则glReadPixels可能读到未完成的内容。读回像素后可以存成 PPM 文件肉眼确认渲染结果。3.4 CMake 构建配置与链接细节CMakeLists.txt的写法直接决定链接是否成功cmake_minimum_required(VERSION 3.10) project(gles_demo) set(CMAKE_CXX_STANDARD 14) find_package(PkgConfig REQUIRED) pkg_check_modules(GLESv2 REQUIRED glesv2) pkg_check_modules(EGL REQUIRED egl) add_executable(gles_demo src/main.cpp) target_include_directories(gles_demo PRIVATE ${GLESv2_INCLUDE_DIRS} ${EGL_INCLUDE_DIRS}) target_link_libraries(gles_demo ${GLESv2_LIBRARIES} ${EGL_LIBRARIES})关键点是pkg_check_modules它会自动找到glesv2.pc和egl.pc这两个 pkg-config 文件。如果报找不到用pkg-config --list-all | grep gles确认包名。Ubuntu 18.04 上包名就是glesv2和egl不要写成GLESv2大小写敏感。构建并运行mkdir build cd build cmake .. make -j4 ./gles_demo如果一切正常当前目录会生成output.ppm用图片查看器打开能看到一个橙色三角形。到这一步整个 OpenGL ES 环境就算彻底打通了。4. 常见问题排查与避坑经验4.1 上下文创建失败的几种典型情况eglInitialize返回EGL_FALSE是最常见的报错。排查顺序如下先看DISPLAY环境变量是否设置echo $DISPLAY应该输出:0或类似值空的话说明不在图形环境。再看用户是否有权限访问 X11xhost命令可以临时放开权限。最后看 Mesa 驱动是否加载glxinfo | grep renderer能确认。还有一种情况是eglChooseConfig返回的 config 数量为 0。这通常是 attribute 列表写得不合理比如你要求EGL_DEPTH_SIZE 32但 pbuffer 不支持这么高的深度。解决办法是把非必要 attribute 去掉先用最小集合跑通再逐个加回来。4.2 Shader 编译报错的定位技巧Shader 报错信息默认不打印必须手动查日志GLint success; glGetShaderiv(shader, GL_COMPILE_STATUS, success); if (!success) { char log[512]; glGetShaderInfoLog(shader, 512, nullptr, log); printf(Shader error: %s\n, log); }这段代码建议封装成函数每个 shader 编译后都调一次。我踩过的坑是GLSL 里少写一个分号报错信息指向的行号是下一行因为编译器在解析到下一个 token 时才报错。所以看到行号不对先检查上一行。另一个高频问题是precision声明。片段 shader 里如果用了float但没写precision mediump float;在部分驱动上会直接编译失败。ES 规范要求片段 shader 必须显式声明浮点精度顶点 shader 有默认值所以不写也行但为了统一建议两个都写。4.3 链接库版本冲突的处理Ubuntu 18.04 上如果同时装了 NVIDIA 驱动和 Mesa可能会出现libGLESv2.so指向混乱。表现是程序能编译但运行时报undefined symbol。排查方法是ldd ./gles_demo | grep -i gles看它实际链接的是哪个路径的库。如果指向/usr/lib/nvidia-xxx/下的版本而你的代码是按 Mesa 写的就可能出问题。解决办法是在 CMake 里显式指定库路径或者用LD_LIBRARY_PATH强制优先加载 Mesa 的库。问题现象可能原因排查命令解决方案eglInitialize 失败无 X11 displayecho $DISPLAY在桌面终端运行或 ssh -XeglChooseConfig 返回 0attribute 不兼容逐步减少 attribute用最小配置先跑通Shader 编译失败语法或精度声明缺失glGetShaderInfoLog检查行号上一行undefined symbol库版本冲突ldd ./程序指定 LD_LIBRARY_PATHglReadPixels 全黑未 glFinish加 glFinish 后重试绘制后强制同步4.4 性能调优与调试工具的使用环境跑通后如果要做性能分析apitrace是首选。用法apitrace trace ./gles_demo apitrace dump gles_demo.trace它会记录每一帧的所有 GL 调用包括参数和耗时。你可以看到哪个 draw call 最慢哪个 texture 上传最频繁。我实测下来很多性能问题不是 shader 复杂而是状态切换太多比如每帧重复绑定同一个 texture这种在 apitrace 里一眼就能看出来。另一个技巧是用MESA_GLES_VERSION_OVERRIDE环境变量强制指定 ES 版本MESA_GLES_VERSION_OVERRIDE3.2 ./gles_demo这在测试代码对不同 ES 版本的兼容性时特别有用不用改代码就能切换上下文版本。5. 从模拟环境到真实硬件的过渡建议5.1 代码层面的可移植性设计在 Mesa 上跑通的代码要迁移到真实 GPU 上最大的差异在 EGL 配置和扩展支持。建议在代码里做两件事第一把所有 EGL attribute 写成可配置的不要硬编码第二用eglQueryString查询扩展列表而不是假设某个扩展一定存在。比如EGL_KHR_create_context这个扩展在桌面 Mesa 上默认有但某些嵌入式驱动可能没有。如果你的代码依赖它创建 ES 3.2 上下文迁移时就会失败。正确做法是先查扩展有就用没有就降级到 ES 3.0。5.2 交叉编译工具链的准备真实硬件通常是 ARM 架构需要交叉编译。工具链一般由芯片厂商提供比如arm-linux-gnueabihf-gcc或aarch64-linux-gnu-gcc。CMake 里通过CMAKE_TOOLCHAIN_FILE指定set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH /path/to/sysroot)关键是sysroot要包含目标板的 GLES 和 EGL 库。很多厂商 SDK 里会带一个sysroot目录直接指过去就行。编译出来的二进制用file命令确认架构用readelf -d看动态链接依赖是否都能在目标板上找到。5.3 真实硬件上的验证清单迁移到板子后按这个顺序验证先跑es2_info确认 EGL 能初始化再跑最小三角形确认渲染管线通最后跑完整业务逻辑。每一步都确认后再进下一步不要跳。我见过太多人直接烧完整程序结果黑屏然后花几天排查最后发现是 EGL config 不兼容。另外真实硬件的 GPU 驱动对 GLSL 的校验比 Mesa 严格得多。Mesa 能过的 shader在 Mali 或 PowerVR 上可能报错。建议在开发阶段就用glslangValidator做静态检查提前发现语法和精度问题。提示如果目标板是 Wayland 环境EGL 的 native display 要用eglGetPlatformDisplayEXT而不是eglGetDisplay这个差异在迁移时经常被忽略。6. 我个人在实际操作中的几点体会这套环境我从 18.04 刚发布时就开始用前后在不同机器上配过不下二十次。最大的体会是不要迷信“一键脚本”。网上很多脚本把一堆包塞在一起装看起来省事但一旦出错你根本不知道是哪一步的问题。手动一步步来每步验证虽然慢一点但出问题时定位快得多。另一个体会是关于 Mesa 版本。18.04 默认的 Mesa 18.x 对大多数 ES 2.0/3.0 场景够用但如果你要做 ES 3.2 的 compute shader 或者GL_EXT_texture_filter_anisotropic这类扩展建议加 PPA 升级到 Mesa 20 以上。升级命令是sudo add-apt-repository ppa:ubuntu-x-swat/updates然后apt upgrade。升级后es2_info里的版本号会变扩展列表也会更全。最后分享一个小技巧如果你经常需要重建环境把整个安装过程写成一个setup.sh但不要写成“一键执行完”而是写成带read -p暂停的分步脚本。每步执行完暂停让你确认输出没问题再继续。这样既保留了自动化又保留了可控性。我现在的脚本就是这么写的配一台新机器大概十五分钟而且每次都知道自己在装什么。 
长河君 · 2026/10/13 6:04:16 · 阅读 1.2k Ubuntu 18.04 上搭建 OpenGL ES 开发环境：从零到渲染的完整指南
1. 为什么要在 Ubuntu 18.04 上折腾 OpenGL ES1.1 这个环境到底解决什么问题先把话说清楚OpenGL ES 不是桌面 OpenGL它是为嵌入式、移动端、以及各种 GPU 计算场景准备的精简版图形 API。你在 Android、iOS、各种车机、机顶盒、甚至一些国产 SoC 上看到的渲染管线底层基本都是 OpenGL ES。那为什么要在 Ubuntu 18.04 这种桌面系统上搭它原因很直接——很多做图形中间件、Shader 调试、GPU 驱动验证、跨平台渲染引擎的团队开发阶段就是在 Linux 桌面上跑 OpenGL ES 的模拟环境验证完再交叉编译到目标板子上。Ubuntu 18.04 LTS 这个版本虽然现在看有点老但它在工业界和芯片原厂 SDK 里依然是主力。很多 GPU 厂商的 BSP 包、Mali 驱动、PowerVR 工具链默认适配的就是 18.04 的 glibc 和 X11 环境。你如果直接上 20.04 或 22.04反而会遇到一堆依赖版本对不上的破事。所以这个标题里的“极度舒适”核心诉求就是用最少的踩坑把 OpenGL ES 的编译、链接、运行、调试链路一次性打通。适合谁看三类人第一类是做嵌入式图形开发的需要在 PC 上先跑通渲染逻辑第二类是做 Shader 效果验证的不想每次都烧到板子上看结果第三类是学生或转行者想学 OpenGL ES 但被环境配置卡在门外。这篇文章会把每一步的“为什么”讲透让你不仅配得出来还知道每个包是干嘛的。1.2 整体思路桌面模拟 交叉验证搭建思路其实就两条路一条是用 Mesa 的软件渲染或硬件加速来模拟 OpenGL ES另一条是直接用 GPU 厂商提供的模拟器。Mesa 是开源图形栈里最稳的选择它提供了libGLESv2和libEGL的完整实现能在没有真实 ES 硬件的情况下把 ES 的调用翻译成桌面 OpenGL 或 Vulkan 来执行。我选的是 Mesa 路线原因是零成本、可调试、和真实 ES 行为足够接近。你不需要买开发板不需要厂商账号一条apt install就能把运行时装好。后面如果要上真实硬件代码层面几乎不用改只需要换链接库和交叉编译工具链。这个方案的优势在于“先软后硬”把逻辑 bug 和渲染 bug 分开解决效率高很多。注意Ubuntu 18.04 默认的 Mesa 版本是 18.x对 OpenGL ES 3.2 的支持是完整的但如果你要用 ES 3.2 的高级特性比如 compute shader建议手动升级到 Mesa 20 以上。这个后面会讲怎么处理。2. 环境搭建前的依赖梳理与工具选型2.1 核心依赖包逐个拆解很多人配环境失败不是因为命令敲错而是根本不知道每个包在链路里的位置。我把关键依赖分成四层编译层、运行时层、窗口系统层、调试层。编译层需要build-essential、cmake、pkg-config。这三个是基础中的基础pkg-config特别重要它负责在编译时告诉编译器去哪里找libGLESv2.so和头文件路径。没有它你就得手动写-I和-L项目一复杂就崩。运行时层是libgles2-mesa-dev、libegl1-mesa-dev、libglm-dev。前两个提供 ES 和 EGL 的头文件与链接库glm是数学库做矩阵变换必备。这里有个坑Ubuntu 仓库里libgles2-mesa-dev和libgles2-mesa是两个包前者带头文件后者只有运行时。你如果只装后者编译时就会报GLES2/gl2.h: No such file。窗口系统层需要libx11-dev、libxrandr-dev、libxi-dev、libxcursor-dev。EGL 在 Linux 上要通过 X11 创建 surface这些是 X11 的开发头文件。如果你用 Wayland包名会不一样但 18.04 默认还是 X11所以按这个来。调试层推荐mesa-utils、libgl1-mesa-dri、apitrace。mesa-utils里的es2_info能直接打印当前 ES 上下文的信息验证环境是否生效特别方便。apitrace可以抓帧分析每一帧的 GL 调用调 Shader 的时候是神器。依赖包所属层级核心作用是否必装build-essential编译层提供 gcc/g/make必装cmake编译层跨平台构建工具必装pkg-config编译层自动解析库路径必装libgles2-mesa-dev运行时层ES 头文件与链接库必装libegl1-mesa-dev运行时层EGL 头文件与链接库必装libglm-dev运行时层矩阵/向量数学库推荐libx11-dev窗口层X11 基础开发库必装libxrandr-dev窗口层分辨率与显示模式必装mesa-utils调试层es2_info 等诊断工具推荐apitrace调试层GL 调用抓帧分析可选2.2 为什么不用厂商模拟器有人会问Mali 有 Offline CompilerPowerVR 有 PVRTrace为什么不直接用我的经验是厂商工具适合做最终验证不适合日常开发。原因有三第一厂商工具通常绑定特定驱动版本换个 GPU 就废第二它们的调试信息不如 Mesa 透明出问题只能看日志猜第三很多厂商工具在 Linux 桌面上的安装包年久失修依赖冲突比 Mesa 还多。Mesa 的另一个好处是源码开放你遇到诡异行为可以直接看实现。比如 EGL 创建上下文失败你可以加MESA_DEBUG1环境变量它会打印详细的错误原因。这种透明度在排查问题时价值极高。3. 从零开始的完整实操流程3.1 系统更新与基础包安装第一步永远是更新源但 18.04 的默认源现在可能有点慢建议先换成国内镜像。编辑/etc/apt/sources.list把archive.ubuntu.com替换成mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn。换完执行sudo apt update sudo apt upgrade -y升级完重启一次确保内核和驱动状态干净。然后装基础编译工具sudo apt install -y build-essential cmake pkg-config git这里有个细节build-essential会带入gcc-718.04 默认就是 7.x对 C14 支持完整。如果你要用 C17 的std::filesystem需要额外装g-8并手动切换但 OpenGL ES 开发一般用不到保持默认即可。3.2 OpenGL ES 与 EGL 开发库安装核心命令如下sudo apt install -y libgles2-mesa-dev libegl1-mesa-dev libglm-dev sudo apt install -y libx11-dev libxrandr-dev libxi-dev libxcursor-dev sudo apt install -y mesa-utils apitrace装完后验证头文件是否存在ls /usr/include/GLES2/gl2.h ls /usr/include/EGL/egl.h两个文件都在说明开发库就位。接着验证运行时es2_info如果输出里能看到EGL_VERSION、GL_VERSION、GL_RENDERER并且 renderer 显示Mesa或你的显卡型号说明 EGL 已经能正常创建上下文。这一步是整个搭建过程中最关键的验证点过了这关后面基本不会有大问题。提示如果es2_info报failed to create context先检查是不是在纯 SSH 环境下运行。EGL 需要 X11 displaySSH 默认没有你需要ssh -X或者直接在桌面终端里跑。3.3 编写第一个 ES 渲染程序光装库不算完得跑通一个真实渲染才能确认链路完整。我写一个最小化的三角形渲染程序包含 EGL 初始化、Shader 编译、绘制三个核心环节。先建目录结构mkdir -p ~/gles_demo/src cd ~/gles_demosrc/main.cpp的核心逻辑分四步。第一步EGL 初始化EGLDisplay display eglGetDisplay(EGL_DEFAULT_DISPLAY); eglInitialize(display, nullptr, nullptr); const EGLint configAttribs[] { EGL_SURFACE_TYPE, EGL_PBUFFER_BIT, EGL_BLUE_SIZE, 8, EGL_GREEN_SIZE, 8, EGL_RED_SIZE, 8, EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT, EGL_NONE };这里用EGL_PBUFFER_BIT而不是窗口 surface原因是 pbuffer 不需要可见窗口适合自动化测试和后台渲染。如果你要显示到屏幕把 surface type 改成EGL_WINDOW_BIT然后用eglCreateWindowSurface绑定 X11 窗口。第二步创建上下文并设为当前EGLint contextAttribs[] { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE }; EGLContext context eglCreateContext(display, config, EGL_NO_CONTEXT, contextAttribs); eglMakeCurrent(display, surface, surface, context);EGL_CONTEXT_CLIENT_VERSION设为 2 表示 ES 2.0设 3 就是 ES 3.0。这个参数决定了你能用哪些 GLSL 版本写错了会在编译 shader 时报版本不匹配。第三步编译 shader。顶点 shader 就三行#version 100 attribute vec4 a_Position; void main() { gl_Position a_Position; }片段 shader 更简单#version 100 precision mediump float; void main() { gl_FragColor vec4(1.0, 0.5, 0.2, 1.0); }注意#version 100是 ES 2.0 的 GLSL 版本号ES 3.0 要写#version 300 es而且attribute要改成ingl_FragColor要改成自定义输出变量。这个差异是新手最容易翻车的地方。第四步绘制并读回像素glClearColor(0.1f, 0.1f, 0.1f, 1.0f); glClear(GL_COLOR_BUFFER_BIT); glDrawArrays(GL_TRIANGLES, 0, 3); glFinish(); std::vectorunsigned char pixels(256 * 256 * 4); glReadPixels(0, 0, 256, 256, GL_RGBA, GL_UNSIGNED_BYTE, pixels.data());glFinish不能省否则glReadPixels可能读到未完成的内容。读回像素后可以存成 PPM 文件肉眼确认渲染结果。3.4 CMake 构建配置与链接细节CMakeLists.txt的写法直接决定链接是否成功cmake_minimum_required(VERSION 3.10) project(gles_demo) set(CMAKE_CXX_STANDARD 14) find_package(PkgConfig REQUIRED) pkg_check_modules(GLESv2 REQUIRED glesv2) pkg_check_modules(EGL REQUIRED egl) add_executable(gles_demo src/main.cpp) target_include_directories(gles_demo PRIVATE ${GLESv2_INCLUDE_DIRS} ${EGL_INCLUDE_DIRS}) target_link_libraries(gles_demo ${GLESv2_LIBRARIES} ${EGL_LIBRARIES})关键点是pkg_check_modules它会自动找到glesv2.pc和egl.pc这两个 pkg-config 文件。如果报找不到用pkg-config --list-all | grep gles确认包名。Ubuntu 18.04 上包名就是glesv2和egl不要写成GLESv2大小写敏感。构建并运行mkdir build cd build cmake .. make -j4 ./gles_demo如果一切正常当前目录会生成output.ppm用图片查看器打开能看到一个橙色三角形。到这一步整个 OpenGL ES 环境就算彻底打通了。4. 常见问题排查与避坑经验4.1 上下文创建失败的几种典型情况eglInitialize返回EGL_FALSE是最常见的报错。排查顺序如下先看DISPLAY环境变量是否设置echo $DISPLAY应该输出:0或类似值空的话说明不在图形环境。再看用户是否有权限访问 X11xhost命令可以临时放开权限。最后看 Mesa 驱动是否加载glxinfo | grep renderer能确认。还有一种情况是eglChooseConfig返回的 config 数量为 0。这通常是 attribute 列表写得不合理比如你要求EGL_DEPTH_SIZE 32但 pbuffer 不支持这么高的深度。解决办法是把非必要 attribute 去掉先用最小集合跑通再逐个加回来。4.2 Shader 编译报错的定位技巧Shader 报错信息默认不打印必须手动查日志GLint success; glGetShaderiv(shader, GL_COMPILE_STATUS, success); if (!success) { char log[512]; glGetShaderInfoLog(shader, 512, nullptr, log); printf(Shader error: %s\n, log); }这段代码建议封装成函数每个 shader 编译后都调一次。我踩过的坑是GLSL 里少写一个分号报错信息指向的行号是下一行因为编译器在解析到下一个 token 时才报错。所以看到行号不对先检查上一行。另一个高频问题是precision声明。片段 shader 里如果用了float但没写precision mediump float;在部分驱动上会直接编译失败。ES 规范要求片段 shader 必须显式声明浮点精度顶点 shader 有默认值所以不写也行但为了统一建议两个都写。4.3 链接库版本冲突的处理Ubuntu 18.04 上如果同时装了 NVIDIA 驱动和 Mesa可能会出现libGLESv2.so指向混乱。表现是程序能编译但运行时报undefined symbol。排查方法是ldd ./gles_demo | grep -i gles看它实际链接的是哪个路径的库。如果指向/usr/lib/nvidia-xxx/下的版本而你的代码是按 Mesa 写的就可能出问题。解决办法是在 CMake 里显式指定库路径或者用LD_LIBRARY_PATH强制优先加载 Mesa 的库。问题现象可能原因排查命令解决方案eglInitialize 失败无 X11 displayecho $DISPLAY在桌面终端运行或 ssh -XeglChooseConfig 返回 0attribute 不兼容逐步减少 attribute用最小配置先跑通Shader 编译失败语法或精度声明缺失glGetShaderInfoLog检查行号上一行undefined symbol库版本冲突ldd ./程序指定 LD_LIBRARY_PATHglReadPixels 全黑未 glFinish加 glFinish 后重试绘制后强制同步4.4 性能调优与调试工具的使用环境跑通后如果要做性能分析apitrace是首选。用法apitrace trace ./gles_demo apitrace dump gles_demo.trace它会记录每一帧的所有 GL 调用包括参数和耗时。你可以看到哪个 draw call 最慢哪个 texture 上传最频繁。我实测下来很多性能问题不是 shader 复杂而是状态切换太多比如每帧重复绑定同一个 texture这种在 apitrace 里一眼就能看出来。另一个技巧是用MESA_GLES_VERSION_OVERRIDE环境变量强制指定 ES 版本MESA_GLES_VERSION_OVERRIDE3.2 ./gles_demo这在测试代码对不同 ES 版本的兼容性时特别有用不用改代码就能切换上下文版本。5. 从模拟环境到真实硬件的过渡建议5.1 代码层面的可移植性设计在 Mesa 上跑通的代码要迁移到真实 GPU 上最大的差异在 EGL 配置和扩展支持。建议在代码里做两件事第一把所有 EGL attribute 写成可配置的不要硬编码第二用eglQueryString查询扩展列表而不是假设某个扩展一定存在。比如EGL_KHR_create_context这个扩展在桌面 Mesa 上默认有但某些嵌入式驱动可能没有。如果你的代码依赖它创建 ES 3.2 上下文迁移时就会失败。正确做法是先查扩展有就用没有就降级到 ES 3.0。5.2 交叉编译工具链的准备真实硬件通常是 ARM 架构需要交叉编译。工具链一般由芯片厂商提供比如arm-linux-gnueabihf-gcc或aarch64-linux-gnu-gcc。CMake 里通过CMAKE_TOOLCHAIN_FILE指定set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH /path/to/sysroot)关键是sysroot要包含目标板的 GLES 和 EGL 库。很多厂商 SDK 里会带一个sysroot目录直接指过去就行。编译出来的二进制用file命令确认架构用readelf -d看动态链接依赖是否都能在目标板上找到。5.3 真实硬件上的验证清单迁移到板子后按这个顺序验证先跑es2_info确认 EGL 能初始化再跑最小三角形确认渲染管线通最后跑完整业务逻辑。每一步都确认后再进下一步不要跳。我见过太多人直接烧完整程序结果黑屏然后花几天排查最后发现是 EGL config 不兼容。另外真实硬件的 GPU 驱动对 GLSL 的校验比 Mesa 严格得多。Mesa 能过的 shader在 Mali 或 PowerVR 上可能报错。建议在开发阶段就用glslangValidator做静态检查提前发现语法和精度问题。提示如果目标板是 Wayland 环境EGL 的 native display 要用eglGetPlatformDisplayEXT而不是eglGetDisplay这个差异在迁移时经常被忽略。6. 我个人在实际操作中的几点体会这套环境我从 18.04 刚发布时就开始用前后在不同机器上配过不下二十次。最大的体会是不要迷信“一键脚本”。网上很多脚本把一堆包塞在一起装看起来省事但一旦出错你根本不知道是哪一步的问题。手动一步步来每步验证虽然慢一点但出问题时定位快得多。另一个体会是关于 Mesa 版本。18.04 默认的 Mesa 18.x 对大多数 ES 2.0/3.0 场景够用但如果你要做 ES 3.2 的 compute shader 或者GL_EXT_texture_filter_anisotropic这类扩展建议加 PPA 升级到 Mesa 20 以上。升级命令是sudo add-apt-repository ppa:ubuntu-x-swat/updates然后apt upgrade。升级后es2_info里的版本号会变扩展列表也会更全。最后分享一个小技巧如果你经常需要重建环境把整个安装过程写成一个setup.sh但不要写成“一键执行完”而是写成带read -p暂停的分步脚本。每步执行完暂停让你确认输出没问题再继续。这样既保留了自动化又保留了可控性。我现在的脚本就是这么写的配一台新机器大概十五分钟而且每次都知道自己在装什么。