Chrome内核解析 -- 绘制引擎基础篇：Command Buffer_chrome 浏览器绘制引擎-优快云博客

本文链接：https://blog.youkuaiyun.com/yunchao_he/article/details/41743463

本文详细介绍了Chromium中的Command Buffer机制，作为GraphicsContext与GPU线程通信的桥梁，它确保GL操作同步、高效且安全。通过Command Buffer，多个GraphicsContext的GL调用被转换为字符串并发送给服务端，服务端解析并验证后执行。文章还涵盖了Command Buffer的代码结构、资源管理、测试以及设计文档链接。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

转载请注明出处：http://write.blog.youkuaiyun.com/postedit/41743463

本文讲解Chromium里集中处理GL操作的重要模块：command buffer.

GraphicsContexts与Gpu thread的通信媒介： command buffer

Chromium里，GraphicsContext对应的实体（比如Render主线程，compositor线程，raster线程等）并不会直接与Gpu打交道。所有的GL操作都必须通过command buffer进行处理，然后才向GPU发起GL操作。也就是说，其构架为：

(WebGL/Canvas/Compositor等的) GraphicsContext -> Command buffer -> Gpu

实际上，每个GraphicsContext都是command buffer的客户端，而Gpu 线程或进程有与之对应的服务端。二者通过IPC通信。实际上就是客户端将GL调用转换为字符串，发送给服务器端。服务器端收到消息后，解析字符串(GLESDecoderImpl::DoCommands)得知相应的GL操作，验证其合法性，并发出相应的GL调用。而Command Buffer的存储空间在客户端和服务端是共享的。这整个过程类似于生产者/消费者模式。

这样的构架有几点原因。首先，保证了各个调用者的同步关系。大多数GPU实际上是单通道的。也就是同一时刻实际上只支持一个pipeline，类似于单核CPU。GPU内的所有计算单元全部为当前pipeline服务，所以单位时间内有很高的吞吐量（这一点和单核CPU不同：GPU有几十到几百个计算单元，而单核CPU至多也就是单核双线程，最多有两个计算单元）。当然，最新的GPU构架已经开始支持多通道。但这也意味着需要从逻辑上的多个GraphicsContext映射到多个物理pipeline上。而不同的pipeline之间的切换，也需要切换GraphicsContext，相当于CPU中切换进程时需要保存上下文。所以，command b