opengl 优化的核心步骤有哪些实战案例如何

opengl 优化的常见问题分析

刚开始接触opengl的时候，我总觉得画面卡、帧率低是电脑配置不行，后来才发现很多时候是自己写的代码“太臃肿”，就像房间里堆满杂物，走路都费劲，opengl程序里的“杂物”也会让显卡和CPU忙不过来，常见的问题其实就那么几个：绘制调用次数太多，比如游戏里每个小草、每块石头都单独调用一次绘制函数，显卡刚画完一个又得接下一个，累得直喘气；纹理尺寸不合理，明明一个512x512的图就能显示清楚，非要用4096x4096的，内存占满了加载还慢；还有顶点数据没处理好，比如一个立方体明明8个顶点就能画出来，偏要存成36个（每个面6个顶点）,显卡处理数据的时候得多算多少遍啊。

之前帮社团做一个简单的3D迷宫游戏，刚开始迷宫里的墙壁、地面、道具都是分开画的，光绘制调用就有几百次，帧率一直在30上下晃悠，角色移动的时候画面一顿一顿的，玩起来像看PPT，后来才知道这些“小碎步”的绘制调用是性能杀手，显卡每次切换绘制对象都要重新设置状态，就像老师讲课中途老被打断，思路都断了,效率能高吗？

opengl 优化的核心步骤详解

找到了问题就好办，优化其实就是给opengl“松绑”，让它跑起来更轻快，第一个要做的就是合并绘制调用，把相同材质、相同纹理的物体“打包”，一次性交给显卡，比如迷宫里的所有墙壁，材质都是灰色石头，那就把它们的顶点数据合并到一个大数组里，调用一次绘制函数就能全画出来，我当时把迷宫的墙壁、地面、天花板各自合并，绘制调用从几百次降到了3次，帧率直接跳到50多,画面一下子就流畅了。

然后是优化纹理，纹理就像给3D模型穿的衣服，衣服太大太重，模型就跑不动，我把原来2048x2048的纹理压缩成512x512，格式从RGBA8888换成ETC2（移动设备常用的压缩格式），内存占用直接砍到原来的1/8，加载速度快了不少，游戏启动时间从20秒缩到8秒，不过压缩的时候要注意，不能压缩过度，不然纹理会模糊，就像给模型穿了件起球的旧衣服,不好看。

还有顶点数据处理，用顶点缓冲对象（VBO）存顶点数据，让显卡直接从显存读取，不用每次都从CPU内存复制，之前我是每次绘制都把顶点数据从内存传到显卡，CPU和显卡之间像传接力棒一样来回跑，现在把数据存在VBO里，显卡自己就能取，CPU直接“躺平”，节省了不少时间，用索引缓冲对象（IBO）存顶点索引，重复的顶点只存一次，比如立方体8个顶点，用IBO记录每个面的顶点序号，数据量一下子少了很多,显卡处理起来也更轻松。

opengl 优化的工具推荐清单

光靠眼睛看代码找问题可不行，得有趁手的工具帮忙“体检”，首推RenderDoc，这工具简直是opengl优化的“CT机”，能把每一帧画面的绘制过程拆解开，看看哪个绘制调用花的时间长，哪个纹理占的内存大，我上次用它截了迷宫游戏的一帧，发现有个道具的纹理格式用错了，本该用压缩格式却用了未压缩的，占了30%的显存，改完之后帧率又涨了10，这工具免费又好用，界面也不难懂,跟着教程点几下就能上手。

如果用的是英伟达显卡，那Nsight Graphics必须安排上，它能实时显示帧率、Draw Call数量、显存占用这些数据，就像给程序装了个“仪表盘”，优化的时候调参数，效果立竿见影，我邻居家哥哥用它优化自己的小游戏，发现某个 shader（着色器）写得太复杂，里面循环太多，改了个简单算法，帧率直接翻倍，不过这工具对英伟达显卡“偏心”,AMD显卡用起来可能没那么顺手。

还有Intel GPA，Intel出的性能分析工具，兼容性比较好，不管是Intel核显还是AMD、英伟达独显都能用，它能分析CPU和GPU的瓶颈在哪，有时候画面卡不一定是显卡不行，可能是CPU把数据传太慢了，之前我同学的程序帧率低，用GPA一查，发现CPU在循环里反复计算顶点坐标，没提前算好存在数组里，改完之后CPU占用率从80%降到30%，显卡也能“吃饱饭”了。

opengl 优化的性能测试方法

优化完了不能拍脑袋说“好了”，得用数据说话，最直接的就是测帧率，用opengl的API或者第三方库（比如SDL、GLFW）获取每一帧的绘制时间，算成帧率（FPS），正常游戏帧率至少要30 FPS才流畅，60 FPS就很丝滑了，我测迷宫游戏的时候，优化前30 FPS，优化后稳定在60 FPS,手机上玩也不卡了。

还要统计绘制调用次数，用工具或者自己在代码里加计数器，看看合并绘制调用后到底降了多少，之前我的迷宫游戏从300多次降到3次，这个数据一看就知道优化效果多明显。监控显存占用也很重要，用Nsight或者系统自带的任务管理器都行，显存满了会导致卡顿甚至程序崩溃，我有次把纹理压缩忘做了，显存直接飙到2G，手机当场闪退，后来压缩完降到500M,就没事了。

进阶一点可以分析Draw Call耗时，用RenderDoc看每个绘制调用花了多少毫秒，找出“拖后腿”的调用，比如有次我发现一个角色模型的绘制调用特别慢，查了半天是材质设置太复杂，用了5个纹理采样器，改成2个之后，单次调用耗时从15ms降到5ms，整体帧率又提了5 FPS。

opengl 优化的实战案例分享

去年帮朋友做一个AR看房的App，用户用手机扫房间，App能实时显示3D家具模型，刚开始模型一多就卡得不行，手机烫得能煎鸡蛋，用户体验简直灾难，我接手后第一步就是分析问题，用RenderDoc一看，好家伙，每个家具模型都单独绘制，有10个家具就有10次Draw Call，而且每个模型的纹理都是4096x4096的PNG,内存占用直接上天。

我先把所有相同材质的家具模型合并，比如所有椅子用一个材质，所有桌子用一个材质，Draw Call从10次降到2次，然后把纹理压缩成ASTC格式（移动设备高效压缩格式），分辨率降到1024x1024，显存占用从800M降到150M，接着用VBO和IBO存顶点数据，之前是每次绘制都从CPU传数据，现在数据存在显存里，CPU只需要发个“开始绘制”的指令就行。

改完之后测试，帧率从20 FPS提到55 FPS，手机也不烫了，朋友高兴得请我喝奶茶，后来用户反馈说“滑动屏幕比之前顺多了，像刷短视频一样”，这个案例让我明白，opengl优化不是什么玄学，就是把“多余的动作”去掉，让显卡和CPU各司其职,别互相添乱。

opengl 优化与directx优化对比

很多人纠结opengl优化和directx优化选哪个，其实它们就像安卓和iOS，各有各的地盘，opengl的优势是跨平台，Windows、macOS、Linux、手机、游戏机（比如Switch）都能用，你写一套优化代码，改改细节就能在不同设备上跑，我之前做的AR看房App，既要支持安卓又要支持iOS，选opengl就很方便,优化方法两边通用。

directx是微软自家的，主要在Windows和Xbox上用，对微软系统的兼容性更好，优化起来可能更贴合Windows的底层，比如directx 12的多线程渲染，能让CPU多个核心一起处理绘制命令，对多核CPU的利用效率更高，但它的缺点是“挑食”，macOS和Linux上基本用不了,手机上更是没戏。

性能方面，两者优化到极致其实差不多，但opengl因为开源，社区资料更多，遇到问题容易找到解决方案，我同学做Windows单机游戏，用directx 12优化，多线程渲染确实让CPU压力小了不少；我做跨平台项目，用opengl优化，虽然在Windows上可能比directx稍慢一点，但胜在一份代码跑遍所有设备,省心。

opengl 优化的未来发展趋势

现在opengl已经发展到4.6版本，未来的优化方向肯定是更智能、更自动化，比如现在需要手动合并绘制调用、压缩纹理，以后可能显卡驱动会自动识别相似的绘制任务，帮你合并；纹理压缩也可能由工具自动完成，根据设备性能动态调整压缩率,既保证画质又不卡。

还有硬件加速的光线追踪，现在英伟达和AMD的新显卡都支持光追，opengl未来可能会更好地结合光追技术，在优化性能的同时，让画面更真实，比如之前优化只能牺牲画质换帧率，以后可能在保持高帧率的同时，让游戏里的光影、反射效果更逼真，就像用单反相机拍照和手机拍照的区别，以前只能选清晰或不卡,以后两者都能要。

移动端优化会更受重视，现在手机性能越来越强，但电池续航是个大问题，opengl优化以后会更注重“低功耗”，比如减少显卡的运算量，让手机玩游戏时耗电慢一点，温度低一点，我猜以后可能会有专门针对手机CPU和GPU架构的优化工具，就像给手机“量身定制”瘦身方案,效果更好。