摘要：Part I分析了GPU客户端之间存在的同步问题，以及Chromium的GL扩展同步点机制的基本原理。本文将源代码的角度剖析同步点（SyncPoint）机制的实现方式。同步点机制的实现主要涉及到是如何跨进程实现两个GL扩展接口InsertSyncPointCHROMIUM和WaitSyncPointCHROMIUM的实现方式，以及如何实现GPU服务端的同步点等待。
GPU客户端将所有的GL命令都封装在GLES2Implementation中，GLES2Implementation将客户端的GL命令序列化后存放在命令行缓冲区中，客户端的每个WebGraphicsContext3DImpl都会创建一个GLES2Implementation实例，调用GLES2Implementation的方法看上去就像直接调用OpenGL方法直接操作GPU设备一样。GPU客户端与GPU进程之间的交互封装在GpuCommandBufferProxy类中，这个代理类会向GPU服务端的GpuCommandBufferStub发送IPC消息请求执行某些GPU操作，如发送GpuCommandBufferMsg_AsyncFlush消息提交（Flush）命令缓冲区。
同步点机制首先需要在GLES2Implementation类中实现这两个GL扩展接口，以便允许客户端代码使用同步点机制。GLES2Implementation::InsertSyncPointCHROMIUM通过GpuCommandBufferProxy向GPU服务端发送一条同步IPC消息GpuCommandBufferMsg_InsertSyncPoint请求注册一个新的同步点，在调用CommandBufferProxyImpl::InsertSyncPoint之前，GLES2Implementation会将客户端的所有GL命令通过Flush命令行缓冲区都提交到服务端，如下代码：
GLuint GLES2Implementation::InsertSyncPointCHROMIUM() {
GPU_CLIENT_SINGLE_THREAD_CHECK();
GPU_CLIENT_LOG("[" << GetLogPrefix() << "] glInsertSyncPointCHROMIUM");
helper_->CommandBufferHelper::Flush();
return gpu_control_->InsertSyncPoint();
}
...
uint32 CommandBufferProxyImpl::InsertSyncPoint() {
if (last_state_.error != gpu::error::kNoError)
return 0;
uint32 sync_point = 0;
Send(new GpuCommandBufferMsg_InsertSyncPoint(route_id_, true, &sync_point));
return sync_point;
}
同步IPC消息GpuCommandBufferMsg_InsertSyncPoint的参数sync_point返回由GPU服务端统一分配的唯一标识。
而与InsertSyncPointCHROMIUM不同的是，WaitSyncPointCHROMIUM不是通过发送专门的IPC消息给GPU服务端，而是作为一条GL扩展命令添加到CommandBuffer中，GPU服务端处理这条GL命令时再决定如何执行暂停后续命令的提交，等待同步点的完成。
GPU服务端既可以是一个独立的进程，也可以是一个Browser进程的一个线程，不论是进程还是线程，所有GPU操作了都是在同一个线程上执行，或称为GPU线程。GPU线程除了向GPU设备提交GL命令之外，还需要管理多个GpuChannel。
每个GpuChannel都对应了一个GPU客户端（Renderer进程或者Browser进程），GpuChannel::OnMessageReceived收到来自客户端的IPC消息后，并不会立即对消息进行处理，而是其添加到一个未处理消息队列中，然后再向主消息循环添加一个任务GpuChannel::HandleMessage来处理所有消息队列中所有未处理的消息。这种缓存IPC消息的处理方式至少有两个好处：
第一，便于根据IPC消息序列的特定模式优化对多上下文的消息处理；
第二，便于控制多个GpuChannel之间GL命令执行的同步方式，也就是本文所讨论的同步点机制；
HandleMessage任务中会逐一遍历所有未经处理的IPC消息，根据IPC消息的路由信息，将其交给对应的GpuCommandBufferStub来处理，见如下代码:
void GpuChannel::HandleMessage() {
handle_messages_scheduled_ = false;
if (deferred_messages_.empty())
return;
bool should_fast_track_ack = false;
// 根据IPC消息的路由信息查找对应的GpuCommandBufferStub实例
IPC::Message* m = deferred_messages_.front();
GpuCommandBufferStub* stub = stubs_.Lookup(m->routing_id());
do {
if (stub) {
if (!stub->IsScheduled()) // 当GpuCommandBufferStub处于“不可调度”状态时，直接返回
return;
if (stub->IsPreempted()) {
OnScheduled();
return;
}
}
// 从消息队列中弹出队头消息并交由GpuCommandBufferStub处理
scoped_ptr<IPC::Message> message(m);
deferred_messages_.pop_front();
bool message_processed = true;
currently_processing_message_ = message.get();
bool result;
if (message->routing_id() == MSG_ROUTING_CONTROL)
result = OnControlMessageReceived(*message);
else
result = router_.RouteMessage(*message);
currently_processing_message_ = NULL;
if (!result) {
// Respond to sync messages even if router failed to route.
if (message->is_sync()) {
IPC::Message* reply = IPC::SyncMessage::GenerateReply(&*message);
reply->set_reply_error();
Send(reply);
}
} else {
// If the command buffer becomes unscheduled as a result of handling the
// message but still has more commands to process, synthesize an IPC
// message to flush that command buffer.
if (stub) {
if (stub->HasUnprocessedCommands()) {
deferred_messages_.push_front(new GpuCommandBufferMsg_Rescheduled(
stub->route_id()));
message_processed = false;
}
}
}
if (message_processed)
MessageProcessed();
// 此处省略一部分无关代码
} while (should_fast_track_ack);
// 如果消息队列不为空，调用OnScheduled继续往主消息循环中添加HandleMessage任务
if (!deferred_messages_.empty()) {
OnScheduled();
}
}
GpuCommandBufferStub是GPU进程端一个非常重要的类，它封装了大部分在GPU服务端用来执行GL命令的功能，包括上下文的创建和初始化，响应客户端的GPU操作请求，调度执行分析和反序列化命令行缓冲区中的GL命令等工作。 GPU客户端请求创建一个新的3D上下文时，实际上是请求一个新的GpuCommandBufferStub实例，因此，对于包含硬件加速canvas的Renderer进程，其对应的GpuChannel会管理多个GpuCommandBufferStub实例，以及根据IPC消息头部信息将IPC消息派发给相应的GpuCommandBufferStub实例上。
为了对IO线程上收到的IPC消息进行预处理，每个GpuChannel都会安装一个运行在IO线程上的消息过滤器，每条来自GPU客户端的IPC消息首先要经由消息过滤器的预处理，再转发给GpuChannel做进一步处理。
当GPU服务端收到GpuCommandBufferMsg_InsertSyncPoint消息后，IO线程上的消息过滤器GpuChannelMessageFilter分两步处理：
1. IO线程上请求SyncPointManager::GenerateSyncPoint生成同步点的唯一标识，并立即发送给GPU客户端；
2. 向GPU服务端的主消息循环队列添加一个新的任务InsertSyncPointOnMainThread，即在主线程上向GpuChannel添加一个同步点；
static void InsertSyncPointOnMainThread(
base::WeakPtr<GpuChannel> gpu_channel,
scoped_refptr<SyncPointManager> manager,
int32 routing_id,
bool retire,
uint32 sync_point) {
// This function must ensure that the sync point will be retired. Normally
// we'll find the stub based on the routing ID, and associate the sync point
// with it, but if that fails for any reason (channel or stub already
// deleted, invalid routing id), we need to retire the sync point
// immediately.
if (gpu_channel) {
GpuCommandBufferStub* stub = gpu_channel->LookupCommandBuffer(routing_id);
if (stub) {
stub->AddSyncPoint(sync_point);
if (retire) {
GpuCommandBufferMsg_RetireSyncPoint message(routing_id, sync_point);
gpu_channel->OnMessageReceived(message);
}
return;
} else {
gpu_channel->MessageProcessed();
}
}
manager->RetireSyncPoint(sync_point);
}
InsertSyncPointOnMainThread除了调用GpuCommandBufferStub::AddSyncPoint向当前上下文添加同步点之外，还会显式调用GpuChannel::OnMessageReceived向当前GpuChannel发送一条 GpuCommandBufferMsg_RetireSyncPoint消息，这条消息将会添加到GpuChannel的消息队列队尾，那么对于同时处理多个GpuChannel的主线程来说，可能会发生以下两种情况（这里假设GpuChannelA调用AddSyncPoint了）：
情况I: GpuChannel A在主线程中得到了充分的调度，所有未处理的IPC消息都被处理了，包括插入同步点时要求的GpuCommandBufferMessage_AsyncFlush消息，以及添加同步点之后GPU进程端创建的GpuCommandBufferMsg_RetireSyncPoint消息，这就表明，在同步点之前的所有GL命令此时都已经提交给GPU驱动了，可以让这个同步点“退休”了，也就是上述文档中提到的，同步点收到信号将自动被删除。如果其他GpuChannel有调用WaitSyncPointCHROMIUM的GL命令，等价于不执行任何操作。
情况II: GpuChannel A在主线程中没有得到充分的调度，同时，主线程调度了GpuChannel B，其中某个上下文中调用WaitSyncPointCHROMIUM去等待A中创建的同步点。上面提到，WaitSyncPointCHROMIUm作为一条扩展的GL命令掺入到命令缓冲区中，所以GpuChannelB中的GpuCommandBufferStub在逐条解析并执行命令缓冲区的GL命令时，当遇到WaitSyncPointCHROMIUM命令时，GLES2DecoderImpl::HandleWaitSyncPointCHROMIUM会执行如下操作：
细心的读者可能会发现，这里还有两个问题没有交代清楚：
第一，GpuCommandBufferStub的调度状态是如何被使用的?
第二，SyncPointManager什么时候会调用回调函数GpuCommandBufferStub::OnSyncPointRetired?
前面提到，GpuChannel::HandleMessage会逐一遍历所有未被处理的IPC消息，并交给对应的GpuCommandBufferStub来处理，而只有GpuCommandBufferStub处于“可调度”状态时才能处理这个IPC消息，否则直接从HandleMessage方法中返回，因此GpuChannel的消息处理也将停滞不前，也就是说，此时GpuChannelB将停止下来等待同步点的“退休”，直到GpuCommandBufferStub::OnSyncPointRetired回调函数被触发。
一旦主线程上GpuChannel B的消息处理停止了，GpuChannel A则有更多的机会得到主线程的调度，GpuChannelA中积压的GpuCommandBufferMsg_AsyncFlush和GpuCommandBufferMsg_RetireSyncPoint消息将会一并被处理。GpuCommandBufferMsg_AsyncFlush消息负责将所有客户端的GL命令通过GLES2DecoderImpl提交给GPU驱动，而GpuCommandBufferMsg_RetireSyncPoint消息则会触发GpuCommandBufferStub::OnRetireSyncPoint消息处理函数，请求SyncPointManager将给定的同步点删除，在删除同步点时，SyncPointManager将会运行所有与该同步点关联的回调函数，所以此时GpuCommandBufferStub::OnSyncPointRetired被调用，GpuChannelB的消息处理又可以开始了。
需要特别说明的，由于 GpuCommandBufferStub的调度状态而导致GpuChannelB的消息处理停止，只是针对服务端执行GL命令而言的，并没有停止接受来自客户端的消息，客户端仍然可以向GpuChannelB发送IPC消息，不过这些消息将会一直会被缓存在消息队列中，直到所等待的同步点“退休”，这就是上述提到的“服务端的等待”。
Chromium为解决多个GPU客户端的数据同步问题，引入同步点(SyncPoint)机制的GL扩展，从而允许客户端可以定制不同上下文GL命令执行的先后次序，同步点机制保证了当前上下文在执行后续GL命令之前，其等待的同步点之前的所有GL命令都已经提交给GPU设备。同步点的等待是服务端的等待，客户端代码并不会被阻塞。在实现上，同步点机制依赖于GpuChannel的消息处理机制，当等待的同步点尚未“退休”时，当前的GpuCommandBufferStub将会被置为“不可调度”状态，直到同步点之前的所有的GL命令均已提交。
Chromium Graphics: GPU客户端之间同步机制的原理和实现分析-Part II
原文地址：http://blog.csdn.net/hongbomin/article/details/39826499
