Chromium的GPU进程启动过程分析
? ? ? ?Chromium除了有Browser進程和Render進程，還有GPU進程。GPU進程負責Chromium的GPU操作，例如Render進程通過GPU進程離屏渲染網頁，Browser進程也是通過GPU進程將離屏渲染好的網頁顯示在屏幕上。Chromium之所以將GPU操作運行在獨立進程中，是考慮到穩定性問題。畢竟GPU操作是硬件相關操作，硬件的差異性會引發一定的不穩性。本文分析GPU進程的啟動過程。
老羅的新浪微博：http://weibo.com/shengyangluo，歡迎關注！
《Android系統源代碼情景分析》一書正在進擊的程序員網（http://0xcc0xcd.com）中連載，點擊進入！
? ? ? ?GPU進程由Browser進程負責啟動，它的啟動過程與Render進程的啟動過程是類似的，因此在閱讀本文之前，最好先閱讀Chromium的Render進程啟動過程分析一文。不過，GPU進程啟動之后，Browser進程會與它建立兩個IPC通道。一個IPC通道用來傳輸普通的IPC消息，另一個IPC通道專門用來執行GPU操作，稱為GPU通道。類似地，Render進程需要執行GPU操作時，也會通過Browser進程與GPU進程建立一個專門用來執行GPU操作的IPC通道。Render進程之所以要通過Browser進程間接地與GPU進程建立GPU通道，是因為GPU進程是由Browser進程啟動的，Render進程對它一無所知。
? ? ? ?以上描述的Browser進程、Render進程和GPU進程的關系可以通過圖1概括，如下所示：
圖1 Browser進程、Render進程和GPU進程的關系
? ? ? ?在圖1中，Browser進程與Render進程的IPC通道的建立過程可以參考前面Chromium的Render進程啟動過程分析一文，本文只分析以下三部分內容：
? ? ? ?1. Browser進程與GPU進程的IPC通道的建立過程。?
? ? ? ?2. Browser進程與GPU進程的GPU通道的建立過程。
? ? ? ?3. Render進程與GPU進程的GPU通道的建立過程。
? ? ? ?Browser進程通過一個GpuProcessHost對象描述由它啟動的GPU進程。GPU進程啟動起來之后，會創建一個GpuProcess對象用來與Browser進程進行IPC。接下來，Browser進程中的GpuProcessHost對象會通過已經建立起來的IPC通道請求GPU進程中創建一個GPU通道，以便以后可以執行GPU操作。
? ? ? ?Render進程需要通過GPU渲染網頁的時候，會通過之前與Browser進程建立的IPC通道請求Browser進程為它創建一個GPU通道，并且將該GPU通道封裝在一個WebGraphicsContext3DCommandBufferImpl對象，以后就可以通過該WebGraphicsContext3DCommandBufferImpl對象向GPU進程請求執行GPU操作了。
? ? ? ?GPU進程在啟動的過程中，也會像Browser進程和Render進程一樣，啟動一個IO線程，專門用來執行IPC。以后每當GPU進程通過上述IPC通道接收到一個創建GPU通道的請求的時候，都會在內部創建一個OpenGL上下文。這個OpenGL上下文通過一個GLContext對象描述。這樣在GPU進程中，就會存在若干個OpenGL上下文。這些OpenGL上下文都運行在同一個線程中，這個線程稱為GPU Child Thread。這樣就會涉及到一個OpenGL上下文調度問題，即每當GPU進程接收到一個GPU操作請求時，都要先切換到請求的GPU操作所在的OpenGL上下文，然后才能執行請求的GPU操作。關于GPU進程的OpenGL上下文調度問題，我們在下一系列的文章中再詳細分析。
? ? ? ?接下來，我們就先分析Browser進程啟動GPU進程的過程。這個過程主要是涉及到Browser進程和GPU進程的IPC通道的建立過程。
? ? ? ?在前面Chromium多線程模型設計和實現分析一文中，我們提到，Browser進程，也就是Chromium應用程序的主進程，在啟動的時候，會調用BrowserMainLoop類的成員函數CreateStartupTasks。BrowserMainLoop類的成員函數CreateStartupTasks會請求啟動一個GPU進程，相關的代碼如下所示：
void BrowserMainLoop::CreateStartupTasks() {......// First time through, we really want to create all the tasksif (!startup_task_runner_.get()) {startup_task_runner_ = make_scoped_ptr(new StartupTaskRunner( base::Bind(&BrowserStartupComplete), base::MessageLoop::current()->message_loop_proxy())); ......StartupTask browser_thread_started = base::Bind(&BrowserMainLoop::BrowserThreadsStarted, base::Unretained(this));startup_task_runner_->AddTask(browser_thread_started);......if (BrowserMayStartAsynchronously()) {startup_task_runner_->StartRunningTasksAsync();}}if (!BrowserMayStartAsynchronously()) {......startup_task_runner_->RunAllTasksNow();} }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/browser_main_loop.cc中。
? ? ? ?BrowserMainLoop類的成員函數CreateStartupTasks首先是會創建一個StartupTaskRunner對象，并且保存在成員變量startup_task_runner_中。這個StartupTaskRunner對象封裝了當前線程的一個消息循環，因此通過它可以向當前線程的消息隊列發送消息。當前線程即為Browser進程的主線程，因此有了這個StartupTaskRunner對象之后，接下來可以向其主線程的消息隊列發送消息。
? ? ? ?BrowserMainLoop類的成員函數CreateStartupTasks接下來創建了一個StartupTask，這個StartupTask綁定的函數為BrowserMainLoop類的成員函數BrowserThreadsStarted，用來執行一個Browser線程啟動完畢任務，并且會保存在前面創建的一個StartupTaskRunner對象的內部等待執行。
? ? ? ?最后，取決于Browser進程使用同步還是異步方式啟動，BrowserMainLoop類的成員函數CreateStartupTasks使用不同的方式來執行保存在成員變量startup_task_runner_指向的一個StartupTaskRunner對象中的StartupTask：
? ? ? ?1. 如果是使用同步方式啟動，那么就調用上述StartupTaskRunner對象的成員函數RunAllTasksNow立即執行保存在它里面的各個StartupTask對象所描述的任務。
? ? ? ?2. 如果是使用異步方式啟動，那么就調用上述StartupTaskRunner對象的成員函數StartRunningTasksAsync向主線程的消息隊列發送一個消息，當該消息被處理時，再執行保存在上述StartupTaskRunner對象里面的各個StartupTask對象所描述的任務。
? ? ? ?無論是同步方式，還是異步方式，最終都會在主線程中調用BrowserMainLoop類的成員函數BrowserThreadsStarted，與GPU進程啟動相關的代碼如下所示：
int BrowserMainLoop::BrowserThreadsStarted() {......bool initialize_gpu_data_manager = true; #if defined(OS_ANDROID)// On Android, GLSurface::InitializeOneOff() must be called before initalizing// the GpuDataManagerImpl as it uses the GL bindings. crbug.com/326295if (!gfx::GLSurface::InitializeOneOff()) {......initialize_gpu_data_manager = false;} #endifif (initialize_gpu_data_manager)GpuDataManagerImpl::GetInstance()->Initialize();bool always_uses_gpu = true;bool established_gpu_channel = false; #if defined(USE_AURA) || defined(OS_MACOSX)if (ShouldInitializeBrowserGpuChannelAndTransportSurface()) {established_gpu_channel = true;if (!GpuDataManagerImpl::GetInstance()->CanUseGpuBrowserCompositor()) {established_gpu_channel = always_uses_gpu = false;}BrowserGpuChannelHostFactory::Initialize(established_gpu_channel);......} #elif defined(OS_ANDROID)established_gpu_channel = true;BrowserGpuChannelHostFactory::Initialize(established_gpu_channel); #endif...... }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/browser_main_loop.cc中。
? ? ? ?在Android平臺上，BrowserMainLoop類的成員函數BrowserThreadsStarted首先調用gfx::GLSurface類的靜態成員函數InitializeOneOff在當進程中加載合適的OpenGL庫，以及創建一個EGLDisplay。這樣做有兩個原因，一是后面調用GpuDataManagerImpl類的成員函數Initialize時，在Android平臺上需要通過加載的OpenGL庫來獲取GPU信息，二是Android平臺的Chromium實際上并沒有獨立的GPU進程，而是在Browser進程中創建一個GPU線程，不過這個GPU線程起到的作用與GPU進程是一樣的。上述第二個原因要求Browser進程要做一些GPU相關的初始化工作，即加載合適的OpenGL庫，以及創建一個EGLDisplay，以后創建OpenGL上下文時需要使用到這個EGLDisplay。對于獨立GPU進程的情況，上述的GPU初始化也是需要做的。后面我們就會看到，GPU進程在啟動的時候，會調用gfx::GLSurface類的靜態成員函數InitializeOneOff。
? ? ? ?只有在gfx::GLSurface類的靜態成員函數InitializeOneOff的返回值為true，即在當進程中成功加載了合適的OpenGL庫之后，BrowserMainLoop類的成員函數Initialize才會被調用，負責檢查當前設備使用的GPU及其相關的驅動是否在黑名單中。如果在黑名單中，那么Chromium就不會采用GPU對網頁進行硬件加速渲染。這是由于不是所有的GPU都能夠很好地支持Chromium進行硬件加速渲染，因此就需要設置一個黑名單，避免在渲染網頁的過程中出現錯誤。一旦不能使用GPU對網頁進行硬件加速渲染，那么Chromium就會退而求其次，使用CPU進行渲染。
? ? ? ?如果Chromium在編譯時定義了宏USE_AURA，那么就表示要使用GPU對網頁進行硬件加速渲染，這時候就可能需要啟動GPU進程。AURA是Chromium 35引入的一個窗口管理框架，通過GPU來實現界面上的像按鈕、滾動條和對話框等界面控件。但是由于GPU黑名單的存在，因此就不一定能夠如愿地使用GPU對網頁進行硬件加速渲染。這時候就需要進一步調用函數ShouldInitializeBrowserGpuChannelAndTransportSurface以及GpuDataManagerImpl類的成員函數CanUseGpuBrowserCompositor進行判斷。如果最終確定不能夠使用GPU對網頁進行硬件加速渲染，那么接下來在調用BrowserGpuChannelHostFactory類的靜態成員函數Initialize的時候，傳遞進去的參數就會等于false。對于Mac OS X平臺，也會進行相同的處理。
? ? ? ?如果Chromium在編譯時沒有定義宏USE_AURA，但是當前平臺是Android，那么BrowserMainLoop類的成員函數BrowserThreadsStarted就直接將本地變量established_gpu_channel設置為true，并且以其為參數，調用BrowserGpuChannelHostFactory類的靜態成員函數Initialize啟動一個GPU進程。這表明在Android平臺上，要求GPU能夠支持Chromium對網頁進行硬件加速渲染。
? ? ? 為了更好地理解上面分析的內容，接下來我們在分析GPU進程的啟動過程，也就是BrowserGpuChannelHostFactory類的靜態成員函數Initialize之前，先分析以下幾個函數：
? ? ? 1. gfx::GLSurface::InitializeOneOff
? ? ? 2.?GpuDataManagerImpl::Initialize
? ? ? 3.?ShouldInitializeBrowserGpuChannelAndTransportSurface
? ? ? 4.?GpuDataManagerImpl::CanUseGpuBrowserCompositor
? ? ??gfx::GLSurface類的靜態成員函數InitializeOneOff負責在當前進程中加載合適的OpenGL庫，它的實現如下所示：
bool GLSurface::InitializeOneOff() {......std::vector<GLImplementation> allowed_impls;GetAllowedGLImplementations(&allowed_impls);......CommandLine* cmd = CommandLine::ForCurrentProcess();// The default implementation is always the first one in list.GLImplementation impl = allowed_impls[0];bool fallback_to_osmesa = false;if (cmd->HasSwitch(switches::kOverrideUseGLWithOSMesaForTests)) {impl = kGLImplementationOSMesaGL;} else if (cmd->HasSwitch(switches::kUseGL)) {std::string requested_implementation_name =cmd->GetSwitchValueASCII(switches::kUseGL);if (requested_implementation_name == "any") {fallback_to_osmesa = true;} else if (requested_implementation_name == "swiftshader") {impl = kGLImplementationEGLGLES2;} else {impl = GetNamedGLImplementation(requested_implementation_name);if (std::find(allowed_impls.begin(),allowed_impls.end(),impl) == allowed_impls.end()) {......return false;}}}......return InitializeOneOffImplementation(impl, fallback_to_osmesa, gpu_service_logging, disable_gl_drawing); }? ? ? ?這個函數定義在文件external/chromium_org/ui/gl/gl_surface.cc中。? ? ? ?gfx::GLSurface類的靜態成員函數InitializeOneOff首先是調用另外一個函數GetAllowedGLImplementations獲得當前平臺所支持的OpenGL實現版本列表。對于Android平臺，它的實現如下所示：
void GetAllowedGLImplementations(std::vector<GLImplementation>* impls) {impls->push_back(kGLImplementationEGLGLES2);impls->push_back(kGLImplementationOSMesaGL); }? ? ? ?這個函數定義在文件external/chromium_org/ui/gl/gl_implementation_android.cc中。? ? ? ?從這里可以看到，在Android平臺上，Chromium支持兩個版本的OpenGL實現，其中一個是kGLImplementationEGLGLES2，另一個是kGLImplementationOSMesaGL。kGLImplementationEGLGLES2描述的OpenGL即為Android系統本身提供的OpenGL實現，這個就是由底層的GPU實現的OpenGL庫。kGLImplementationOSMesaGL描述的OpenGL是由Mesa實現的OpenGL庫。Mesa是一個開源的OpenGL實現框架，它可以以軟件方式模擬GPU硬件加速渲染，也可以通過底層真實的GPU來實現硬件加速渲染。
? ? ? ?回到gfx::GLSurface類的靜態成員函數InitializeOneOff中，它獲得當前平臺所支持的OpenGL實現版本列表之后，取出列表中的第一個版本作為默認版本。從前面的分析就可以知道，對于Android平臺，這個默認的OpenGL實現版本就是kGLImplementationEGLGLES2描述的版本。
? ? ? ?接下來，gfx::GLSurface類的靜態成員函數InitializeOneOff再根據命令行參數選擇最終使用的OpenGL實現版本：
? ? ? ?1. 如果設置了switches::kOverrideUseGLWithOSMesaForTests選項，那么就表示要使用kGLImplementationOSMesaGL描述的OpenGL版本，方便用來測試。
? ? ? ?2. 如果設置了switches::kUseGL選項，那么就根據這個選項的值選擇指定的OpenGL實現。不過有兩種特殊情況。一是當該選項值等于"any"時，默認使用之前選擇的OpenGL實現版本，但是如果不能成功加載該版本的庫，那么就改為使用kGLImplementationOSMesaGL描述的OpenGL版本。二是當該選項的值等于"swiftshader"時，使用kGLImplementationEGLGLES2描述的OpenGL版本。SwiftShader是一件純軟件實現的3D渲染引擎工具，由TransGaming公司實現，宣稱支持所有的Pixel和Vertex Shader DX9特效，并且可以獲得比微軟D3D的REF設備（reference rasterizer）快50倍的速度。在Android平臺上，沒有提供SwiftShader，因此用kGLImplementationEGLGLES2描述的OpenGL版本替代。
? ? ? ?最后，gfx::GLSurface類的靜態成員函數InitializeOneOff調用另外一個成員函數InitializeOneOffImplementation在當前進程中加載前面所選擇的OpenGL實現版本，它的實現如下所示：
bool GLSurface::InitializeOneOffImplementation(GLImplementation impl,bool fallback_to_osmesa,bool gpu_service_logging,bool disable_gl_drawing) {bool initialized =InitializeStaticGLBindings(impl) && InitializeOneOffInternal();if (!initialized && fallback_to_osmesa) {ClearGLBindings();initialized = InitializeStaticGLBindings(kGLImplementationOSMesaGL) &&InitializeOneOffInternal();}if (!initialized)ClearGLBindings();......return initialized; }? ? ? ?這個函數定義在文件external/chromium_org/ui/gl/gl_surface.cc中。? ? ? ?gfx::GLSurface類的靜態成員函數InitializeOneOffImplementation首先調用函數InitializeStaticGLBindings加載由參數impl指定的OpenGL實現版本相關的庫。如果能成功加載，再調用函數InitializeOneOffInternal在當前進程中創建一個EGLDisplay。如果也能成功創建這個EGLDisplay，那么就說明參數指定的OpenGL實現版本是能夠正確使用的。
? ? ? ?如果不能成功加載參數impl指定的OpenGL實現版本相關的庫，或者能夠成功加載，但是不能成功創建一個EGLDisplay，并且參數fallback_to_osmesa的值為true，那么就如前所述，改為使用kGLImplementationOSMesaGL描述的OpenGL實現版本，也就是由Mesa實現的OpenGL庫。
? ? ? ?接下來，我們先分析函數InitializeStaticGLBindings的實現，接著再分析函數InitializeOneOffInternal的實現。
? ? ? ?函數InitializeStaticGLBindings的實現如下所示：
bool InitializeStaticGLBindings(GLImplementation implementation) {......switch (implementation) {case kGLImplementationEGLGLES2: {base::NativeLibrary gles_library =LoadLibraryAndPrintError("libGLESv2.so");......base::NativeLibrary egl_library = LoadLibraryAndPrintError("libEGL.so");......GLGetProcAddressProc get_proc_address =reinterpret_cast<GLGetProcAddressProc>(base::GetFunctionPointerFromNativeLibrary(egl_library, "eglGetProcAddress"));......SetGLGetProcAddressProc(get_proc_address);AddGLNativeLibrary(egl_library);AddGLNativeLibrary(gles_library);SetGLImplementation(kGLImplementationEGLGLES2);InitializeStaticGLBindingsGL();InitializeStaticGLBindingsEGL();......break;}......}return true; }? ? ? ?這個函數定義在文件external/chromium_org/ui/gl/gl_implementation_android.cc中。? ? ? ?從這里就可以看到，與kGLImplementationEGLGLES2描述的OpenGL實現版本相關的庫有兩個，分別為libGLESv2.so和libEGL.so，前者描述的是OpenGL實現，后者描述的是EGL實現。調用函數LoadLibraryAndPrintError加載了這兩個庫之后，最后分別調用了函數InitializeStaticGLBindingsGL和InitializeStaticGLBindingsEGL創建了一個RealGLApi接口和一個RealEGLApi接口，這樣以后就可以通過這兩個接口調用由前面加載的libGLESv2.so和libEGL.so所導出的gl*和egl*函數。
? ? ? ?這一步執行完成之后，回到前面分析的gfx::GLSurface類的靜態成員函數InitializeOneOffImplementation中，它接下來調用函數InitializeOneOffInternal創建一個EGLDisplay，以驗證前面加載的OpenGL相關的庫的正確性。
? ? ? ?函數InitializeOneOffInternal的實現如下所示：
bool GLSurface::InitializeOneOffInternal() {switch (GetGLImplementation()) {case kGLImplementationEGLGLES2:if (!GLSurfaceEGL::InitializeOneOff()) {LOG(ERROR) << "GLSurfaceEGL::InitializeOneOff failed.";return false;}default:break;}return true; }? ? ? 這個函數定義在文件external/chromium_org/ui/gl/gl_surface_android.cc中。? ? ? 從這里可以看到， 當使用kGLImplementationEGLGLES2描述的OpenGL實現版本時，函數InitializeOneOffInternal調用GLSurfaceEGL類的靜態成員函數InitializeOneOff創建一個EGLDisplay。
? ? ??GLSurfaceEGL類的靜態成員函數InitializeOneOff的實現如下所示：
bool GLSurfaceEGL::InitializeOneOff() {static bool initialized = false;if (initialized)return true;g_native_display = GetPlatformDefaultEGLNativeDisplay();g_display = eglGetDisplay(g_native_display);if (!g_display) {......return false;}if (!eglInitialize(g_display, NULL, NULL)) {......return false;}static const EGLint kConfigAttribs[] = {EGL_BUFFER_SIZE, 32,EGL_ALPHA_SIZE, 8,EGL_BLUE_SIZE, 8,EGL_GREEN_SIZE, 8,EGL_RED_SIZE, 8,EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,EGL_SURFACE_TYPE, EGL_WINDOW_BIT | EGL_PBUFFER_BIT,EGL_NONE};......const EGLint* config_attribs = kConfigAttribs;......EGLint num_configs;if (!eglChooseConfig(g_display,config_attribs,NULL,0,&num_configs)) {......return false;}......initialized = true;return true; }? ? ? ?這個函數定義在文件external/chromium_org/ui/gl/gl_surface_egl.cc中。? ? ? ?從這里可以看出，GLSurfaceEGL類的靜態成員函數InitializeOneOff通過調用egl函數eglGetDisplay、eglInitialize和eglChooseConfig創建一個EGLDisplay，并且保存在全局變量g_display中，以后就可以通過這個EGLDisplay來創建OpenGL上下文。實際上，eglGetDisplay、eglInitialize和eglChooseConfig是定義在out/target/product/generic/obj/GYP/shared_intermediates/ui/gl/gl_bindings_autogen_egl.h文件中的三個宏，它們分別定義為前面加載的libEGL.so所導出的三個函數eglGetDisplay、eglInitialize和eglChooseConfig。
? ? ? ?事實上，文件out/target/product/generic/obj/GYP/shared_intermediates/ui/gl/gl_bindings_autogen_egl.h定義了所有的egl*宏，并且這些宏都定義為前面加載的libEGL.so所導出的對應的egl*函數。類似地，文件out/target/product/generic/obj/GYP/shared_intermediates/ui/gl/gl_bindings_autogen_gl.h也定義了所有的gl*宏，并且這些宏都定義為前面加載的libGLESv2.so所導出的對應的gl*函數。
? ? ? ?最后，out/target/product/generic/obj/GYP/shared_intermediates/ui/gl/gl_bindings_autogen_egl.h和out/target/product/generic/obj/GYP/shared_intermediates/ui/gl/gl_bindings_autogen_gl.h也定義了所有的gl*宏，并且這些宏都定義為前面加載的libGLESv2.so所導出的對應的gl*函數。這兩個文件又被文件external/chromium_org/ui/gl/gl_bindings.h所included，因此只要include了external/chromium_org/ui/gl/gl_bindings.h文件，就可以直接調用所有的由前面加載的libGLESv2.so和libEGL.so導出的gl*和egl*函數。
? ? ? ?這一步執行完成之后，回到前面分析的BrowserMainLoop類的成員函數BrowserThreadsStarted中，假設gfx::GLSurface類的靜態成員函數InitializeOneOff的返回值為true，即它成功加載了OpenGL相關的庫，那么接下來就會調用GpuDataManagerImpl類的成員函數Initialize檢查設備配置的GPU是否在黑名單列表中。
? ? ? ?GpuDataManagerImpl類的成員函數Initialize的實現如下所示：
void GpuDataManagerImpl::Initialize() {base::AutoLock auto_lock(lock_);private_->Initialize(); }? ? ? 這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl.cc中。? ? ? GpuDataManagerImpl類的成員變量private_指向的是一個GpuDataManagerImplPrivate對象，這里調用它的成員函數Initialize檢查設備配置的GPU是否在黑名單列表中。
? ? ??GpuDataManagerImplPrivate類的成員函數Initialize的實現如下所示：
void GpuDataManagerImplPrivate::Initialize() {......gpu::GPUInfo gpu_info;if (command_line->GetSwitchValueASCII(switches::kUseGL) == gfx::kGLImplementationOSMesaName) {// If using the OSMesa GL implementation, use fake vendor and device ids to// make sure it never gets blacklisted. This is better than simply// cancelling GPUInfo gathering as it allows us to proceed with loading the// blacklist below which may have non-device specific entries we want to// apply anyways (e.g., OS version blacklisting).gpu_info.gpu.vendor_id = 0xffff;gpu_info.gpu.device_id = 0xffff;// Also declare the driver_vendor to be osmesa to be able to specify// exceptions based on driver_vendor==osmesa for some blacklist rules.gpu_info.driver_vendor = gfx::kGLImplementationOSMesaName;} else {......gpu::CollectBasicGraphicsInfo(&gpu_info);}std::string gpu_blacklist_string;std::string gpu_driver_bug_list_string;if (!command_line->HasSwitch(switches::kIgnoreGpuBlacklist) &&!command_line->HasSwitch(switches::kUseGpuInTests)) {gpu_blacklist_string = gpu::kSoftwareRenderingListJson;}if (!command_line->HasSwitch(switches::kDisableGpuDriverBugWorkarounds)) {gpu_driver_bug_list_string = gpu::kGpuDriverBugListJson;}InitializeImpl(gpu_blacklist_string,gpu_driver_bug_list_string,gpu_info); }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl_private.cc中。
? ? ? ?如果Chromium啟動時，指定了switches::kUseGL選項，并且將該選項的值設置為gfx::kGLImplementationOSMesaName，那么就意味著要使用Mesa版本的OpenGL庫來渲染Chromium的UI。由于這里使用的Mesa版本的OpenGL庫是純軟件實現的，因此它不會像GPU版本的OpenGL庫一樣存在一些不友好特性。也就是說Mesa版本的OpenGL庫是可用的，盡管它的性能會差一些。為了避免后面加載GPU黑名單列表時，列表中的某些通用規則會禁用Mesa版本的OpenGL庫的某些特性，GpuDataManagerImplPrivate類的成員函數Initialize會手工構造一個GPUInfo對象，并且給該GPUInfo對象設置假的Vendor ID和Device ID，以及Driver Vendor。
? ? ? ?如果Chromium啟動時，沒有指定switches::kUseGL選項，或者指定了switches::kUseGL選項，但是該選項的值沒有設置為gfx::kGLImplementationOSMesaName，那么上述GPUInfo對象就需要通過函數gpu::CollectBasicGraphicsInfo來構造。函數gpu::CollectBasicGraphicsInfo通過OpenGL接口glGetString獲得當前使用的OpenGL庫的Vendor ID和Device ID，以及Driver Vendor等值。
? ? ? ?接下來，GpuDataManagerImplPrivate類的成員函數Initialize檢查Chromium的命令行參數是否設置了switches::kIgnoreGpuBlacklist和switches::kUseGpuInTests選項。如果都沒有設置，就說明Chromium是運行在發布版本中，這時候需要啟用GPU黑名單列表。這個GPU黑名單列表通過全局變量gpu::kSoftwareRenderingListJson描述的一個JSON格式的字符串描述，它定義在文件external/chromium_org/gpu/config/software_rendering_list_json.cc中。例如，在該GPU黑名單列表中，存在以下一項：
{"id": 1,"description": "ATI Radeon X1900 is not compatible with WebGL on the Mac","webkit_bugs": [47028],"os": {"type": "macosx"},"vendor_id": "0x1002","device_id": ["0x7249"],"features": ["webgl","flash_3d","flash_stage3d"]}? ? ? ?它表示Vendor ID和Device ID分別等于0x1002和0x7249的GPU在Mac OS X上不能夠用來支持Chromium的webgl、flash_3d和flash_stage3d特性。? ? ? ?再接下來，GpuDataManagerImplPrivate類的成員函數Initialize檢查Chromium的命令行參數是否設置了switches::kDisableGpuDriverBugWorkarounds選項。如果沒有設置，也說明Chromium是運行在發布版本中，這時候需要啟用GPU驅動BUG列表。GPU驅動BUG列表描述了那些已知的GPU驅動的BUG，這些BUG也會導致OpenGL的某些特性不能使用。這個GPU驅動BUG列表通過全局變量gpu::kGpuDriverBugListJson描述的一個JSON格式的字符串描述，它定義在文件external/chromium_org/gpu/config/gpu_driver_bug_list_json.cc中。例如，在該GPU驅動BUG列表中，存在以下一項：
{"id": 8,"description": "A few built-in glsl functions on Mac behave incorrectly","cr_bugs": [349137],"os": {"type": "macosx","version": {"op": "<","value": "10.9"}},"vendor_id": "0x1002","features": ["needs_glsl_built_in_function_emulation"]}? ? ? 它表示Vender ID等于0x1002的GPU驅動的編號為349137的BUG會出現在版本號小于10.9的Mac OS X上，Chromium的needs_glsl_built_in_function_emulation特性不可用。? ? ? 最后，GpuDataManagerImplPrivate類的成員函數Initialize將前面獲得的GPUInfo對象，以及GPU黑名單列表和GPU驅動BUG列表，傳遞給另外一個成員函數InitializeImpl進一步處理，如下所示：
void GpuDataManagerImplPrivate::InitializeImpl(const std::string& gpu_blacklist_json,const std::string& gpu_driver_bug_list_json,const gpu::GPUInfo& gpu_info) {......if (!gpu_blacklist_json.empty()) {gpu_blacklist_.reset(gpu::GpuBlacklist::Create());......bool success = gpu_blacklist_->LoadList(gpu_blacklist_json, gpu::GpuControlList::kCurrentOsOnly);......}if (!gpu_driver_bug_list_json.empty()) {gpu_driver_bug_list_.reset(gpu::GpuDriverBugList::Create());......bool success = gpu_driver_bug_list_->LoadList(gpu_driver_bug_list_json, gpu::GpuControlList::kCurrentOsOnly);......}gpu_info_ = gpu_info;UpdateGpuInfo(gpu_info);...... }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl_private.cc中。
? ? ? ?GpuDataManagerImplPrivate類的成員函數InitializeImpl首先是創建一個GpuBlackList對象，保存在成員變量gpu_blacklist_中，并且調用該GpuBlackList對象的成員函數LoadList解析參數gpu_blacklist_json描述的一個JSON格式的字符串，以便可以獲得一系列GPU黑名單。
? ? ? ?GpuDataManagerImplPrivate類的成員函數InitializeImpl接下來又創建一個GpuDriverBugList對象，保存在成員變量gpu_driver_bug_list_中，并且調用該GpuDriverBugList對象的成員函數LoadList解析參數gpu_driver_bug_list_json描述的一個JSON格式的字符串，以便可以獲得一系列GPU驅動BUG列表。
? ? ? ?GpuDataManagerImplPrivate類的成員函數InitializeImpl最后調用了另外一個成員函數UpdateGpuInfo繼續處理GPU黑名單和GPU驅動BUG列表，它的實現如下所示：
void GpuDataManagerImplPrivate::UpdateGpuInfo(const gpu::GPUInfo& gpu_info) {// No further update of gpu_info if falling back to SwiftShader.if (use_swiftshader_)return;.....UpdateGpuInfoHelper(); }? ? ? ??這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl_private.cc中。? ? ? ?當GpuDataManagerImplPrivate類的成員變量use_swiftshader_的值等于true時，表示通過軟件方式來渲染網頁，因此這時候就無需對GPU黑名單列表和GPU驅動BUG列表進行處理了，因為后面不會用到GPU。
? ? ? ?另一方面，當GpuDataManagerImplPrivate類的成員變量use_swiftshader_的值等于false時，需要調用另外一個成員函數UpdateGpuInfoHelper處理GPU黑名單列表和GPU驅動BUG列表，它的實現如下所示：
? ? ? ?GpuDataManagerImplPrivate類的成員函數UpdateGpuInfoHelper首先調用成員變量gpu_blacklist_描述的一個GpuBlackList對象的成員函數MakeDecision根據設備自帶的GPU的信息在GPU黑名單中找到被禁止使用的Chromium特性。這些特性保存在本地變量features描述的一個std::set中，并且會進一步交給GpuDataManagerImplPrivate類的成員函數UpdateBlacklistedFeatures處理。
? ? ? ?GpuDataManagerImplPrivate類的成員函數UpdateGpuInfoHelper接下來又調用了成員變量gpu_driver_bug_list_描述的一個GpuDriverBugList對象的成員函數MakeDecision根據設備自帶的GPU的信息在GPU驅動BUG列表中找到被禁止使用的Chromium特性。這些特性保存在GpuDataManagerImplPrivate類的成員變量gpu_driver_bugs_中，并且會增加到Chromium的啟動命令行參數里面去。
? ? ? ?接下來， 我們繼續分析GpuDataManagerImplPrivate類的成員函數UpdateBlacklistedFeatures，以便可以了解它是如何處理那些禁止使用GPU實現的Chromium特性，如下所示：
void GpuDataManagerImplPrivate::UpdateBlacklistedFeatures(const std::set<int>& features) {blacklisted_features_ = features;...... }? ? ??這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl_private.cc中。? ? ??GpuDataManagerImplPrivate類的成員函數UpdateBlacklistedFeatures主要就是將參數features描述的禁止使用GPU實現的Chromium特性記錄在成員變量blacklisted_features_描述的一個std::set中。
? ? ? 這一步執行完成后，對GPU黑名單列表和GPU驅動BUG列表的處理就完畢，回到前面分析的BrowserMainLoop類的成員函數BrowserThreadsStarted中，如果Chromium在編譯時定義了宏USE_AURA，或者對于Mac OS X平臺，它接下來就會調用函數ShouldInitializeBrowserGpuChannelAndTransportSurface第一次判斷是否需要啟動一個GPU進程。
? ? ??函數ShouldInitializeBrowserGpuChannelAndTransportSurface的實現如下所示：
#if defined(USE_AURA) bool ShouldInitializeBrowserGpuChannelAndTransportSurface() {return true; } #elif defined(OS_MACOSX) && !defined(OS_IOS) bool ShouldInitializeBrowserGpuChannelAndTransportSurface() {return IsDelegatedRendererEnabled(); } #endif? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl_private.cc中。? ? ? ?從這里可以看到，如果Chromium在編譯時定義了宏USE_AURA，那么函數ShouldInitializeBrowserGpuChannelAndTransportSurface的返回值固定為true，因為這時候表示要使用GPU來渲染Chromium的UI，也就是可以啟動一個GPU進程。
? ? ? ?另一方面，如果Chromium在編譯時沒有定義宏USE_AURA，但是當前平臺是非iOS版的Max OS X平臺，那么函數ShouldInitializeBrowserGpuChannelAndTransportSurface調用另外一個函數IsDelegatedRendererEnabled判斷是否可以啟動一個GPU進程。
? ? ? ?函數IsDelegatedRendererEnabled的實現如下所示：
bool IsThreadedCompositingEnabled() {const CommandLine& command_line = *CommandLine::ForCurrentProcess();// Command line switches take precedence over blacklist.if (command_line.HasSwitch(switches::kDisableThreadedCompositing))return false;if (command_line.HasSwitch(switches::kEnableThreadedCompositing))return true;#if defined(USE_AURA) || defined(OS_MACOSX)// We always want threaded compositing on Aura and Mac (the fallback is a// threaded software compositor).return true; #elsereturn false; #endif }bool IsDelegatedRendererEnabled() {const CommandLine& command_line = *CommandLine::ForCurrentProcess();bool enabled = false;......// Flags override.enabled |= command_line.HasSwitch(switches::kEnableDelegatedRenderer);enabled &= !command_line.HasSwitch(switches::kDisableDelegatedRenderer);// Needs compositing, and thread.if (enabled && !IsThreadedCompositingEnabled()) {enabled = false;......}return enabled; }? ? ? ?這兩個函數定義在文件external/chromium_org/content/browser/gpu/compositor_util.cc中。
? ? ? ?從這里可以看到，函數IsDelegatedRendererEnabled的返回值等于true，也就是可以啟動一個GPU進程，需要同時滿足以下條件：
? ? ? ?1. Chromium的命令行參數設置了switches::kEnableDelegatedRenderer選項；
? ? ? ?2.?Chromium的命令行參數沒有設置switches::kDisableDelegatedRenderer選項；
? ? ? ?3.?Chromium的命令行參數設置了switches::kEnableThreadedCompositing選項，或者沒有設置switches::kEnableThreadedCompositing選項，但是Chromium編譯時定義了宏USE_AURA，或者當平臺是Mac OS X平臺。
? ? ? ?4.?Chromium的命令行參數沒有設置switches::kDisableThreadedCompositing選項。
? ? ? ?要理解上述四個條件，關鍵在于理解Delegated Renderer和Threaded Compositing兩個概念。
? ? ? ?Delegated Renderer描述的是一個委托渲染器。所謂委托渲染，就是Render進程的合成器管理的所有GPU資源都會轉交給Browser進程的合成器，再由Browser進程的合成器進行統一的合成，最后顯示在屏幕上。Threaded Compositing稱為線程化合成，指的是在Render進程中，合成器運行在一個獨立的線程中，這個線程稱為實現（IMPL）線程。在Chromium里面，還有一個特性稱為In-Thread?Compositing，稱為線程內合成。這個特性是給Android平臺上的單進程模式的Chromium使用的，這時候Render端的合成器將運行在主線程中，目的是可以讓網頁UI的合成發生在應用程序UI的繪制過程中。
? ? ? ?這意味著，如果Chromium在編譯時沒有定義宏USE_AURA，但是當前平臺是非iOS版的Max OS X平臺，那么Delegated Renderer和Threaded Compositing這兩個特性都是需要GPU支持的，因此當它們都啟用時，就需要啟動一個GPU進程。
? ? ? ?這一步執先完成后，回到前面分析的BrowserMainLoop類的成員函數BrowserThreadsStarted中，這時候如果函數ShouldInitializeBrowserGpuChannelAndTransportSurface的返回值為true，那么只是初步確定Chromium需要一個GPU進程。至于這個GPU進程最終能不能啟動起來，還要取決于設備自帶的GPU能否用來實現GPU_FEATURE_TYPE_GPU_COMPOSITING特性。這是通過調用GpuDataManagerImpl類的成員函數CanUseGpuBrowserCompositor進行判斷的，如下所示：
bool GpuDataManagerImpl::CanUseGpuBrowserCompositor() const {base::AutoLock auto_lock(lock_);return private_->CanUseGpuBrowserCompositor(); }? ? ? 這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl.cc中。? ? ??GpuDataManagerImpl類的成員函數CanUseGpuBrowserCompositor調用了成員變量private_描述的一個GpuDataManagerImplPrivate對象的成員函數CanUseGpuBrowserCompositor判斷設備自帶的GPU能否用來實現GPU_FEATURE_TYPE_GPU_COMPOSITING特性，如下所示：
bool GpuDataManagerImplPrivate::CanUseGpuBrowserCompositor() const {if (ShouldUseSwiftShader())return false;if (IsFeatureBlacklisted(gpu::GPU_FEATURE_TYPE_GPU_COMPOSITING))return false;return true; }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl_private.cc中。? ? ? ?GpuDataManagerImplPrivate類的成員函數CanUseGpuBrowserCompositor首先調用另外一個成員函數ShouldUseSwiftShader判斷Chromium的UI是否是通過軟件方式渲染的，如下所示：
bool GpuDataManagerImplPrivate::ShouldUseSwiftShader() const {return use_swiftshader_; }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl_private.cc中。? ? ? ?前面提到，當GpuDataManagerImplPrivate類的成員變量use_swiftshader的值等于true的時候，就表示Chromium的UI是通過軟件方式渲染的。在這種情況下，回到GpuDataManagerImplPrivate類的成員函數CanUseGpuBrowserCompositor中，那么它就可以直接返回一個false值給調用者，表示不需要啟動一個GPU進程。
? ? ? ?假設GpuDataManagerImplPrivate類的成員函數CanUseGpuBrowserCompositor的返回值為false，那么它接下來就調用成員函數IsFeatureBlacklisted判斷設備自帶的GPU能否用來實現GPU_FEATURE_TYPE_GPU_COMPOSITING特性，如下所示：
bool GpuDataManagerImplPrivate::IsFeatureBlacklisted(int feature) const {......return (blacklisted_features_.count(feature) == 1); }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_data_manager_impl_private.cc中。? ? ? ?從前面的分析可以知道，GpuDataManagerImplPrivate類的成員變量blacklisted_features_描述的一個std::set保存了禁止使用設備自帶的GPU實現的Chromium特性，因此通過它就可以判斷參數feature描述的特性是否被支持。 ? ? ??
? ? ? ?這一步執行完成之后，回到前面分析的BrowserMainLoop類的成員函數BrowserThreadsStarted中，如果GpuDataManagerImpl類的成員函數CanUseGpuBrowserCompositor的返回值為false，也就是設備自帶的GPU被禁止用來實現GPU_FEATURE_TYPE_GPU_COMPOSITING特性，那么本地變量established_gpu_channel的值就會由true值修改為false時，表示不需要啟動一個GPU進程。
? ? ? ?最后，BrowserMainLoop類的成員函數BrowserThreadsStarted調用BrowserGpuChannelHostFactory類的靜態成員函數Initialize檢查本地變量established_gpu_channel的值是否等于true。如果等于true，那么就可能需要啟動一個GPU進程，如下所示：
void BrowserGpuChannelHostFactory::Initialize(bool establish_gpu_channel) {DCHECK(!instance_);instance_ = new BrowserGpuChannelHostFactory();if (establish_gpu_channel) {instance_->EstablishGpuChannel(CAUSE_FOR_GPU_LAUNCH_BROWSER_STARTUP,base::Closure());} }? ? ? 這個函數定義在文件external/chromium_org/content/browser/gpu/browser_gpu_channel_host_factory.cc中。? ? ? BrowserGpuChannelHostFactory類的靜態成員函數Initialize首先是創建了一個BrowserGpuChannelHostFactory對象，并且保存在靜態成員變量instance_中。在參數establish_gpu_channel的值等于true的情況下，BrowserGpuChannelHostFactory類的靜態成員函數Initialize繼續調用前面創建的BrowserGpuChannelHostFactory對象的成員函數EstablishGpuChannel啟動一個GPU進程，以及創建一個到該GPU進程的GPU通道。
? ? ??BrowserGpuChannelHostFactory類的成員函數EstablishGpuChannel的實現如下所示：
void BrowserGpuChannelHostFactory::EstablishGpuChannel(CauseForGpuLaunch cause_for_gpu_launch,const base::Closure& callback) {......if (!gpu_channel_ && !pending_request_) {// We should only get here if the context was lost.pending_request_ = EstablishRequest::Create(cause_for_gpu_launch, gpu_client_id_, gpu_host_id_);}...... }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/browser_gpu_channel_host_factory.cc中。? ? ? ?BrowserGpuChannelHostFactory類的成員變量gpu_channel_描述的是Browser進程到GPU進程的一個GPU通道，另外一個成員變量pending_request_描述的是正在創建上述GPU通道的一個請求。當這兩個成員變量的值均等于NULL的時候，就說明GPU通道還沒有建立起來，因此接下來就會調用EstablishRequest類的靜態成員函數Create創建一個GPU通道。
? ? ? ?EstablishRequest類的靜態成員函數Create的實現如下所示：
scoped_refptr<BrowserGpuChannelHostFactory::EstablishRequest> BrowserGpuChannelHostFactory::EstablishRequest::Create(CauseForGpuLaunch cause,int gpu_client_id,int gpu_host_id) {scoped_refptr<EstablishRequest> establish_request =new EstablishRequest(cause, gpu_client_id, gpu_host_id);scoped_refptr<base::MessageLoopProxy> loop =BrowserThread::GetMessageLoopProxyForThread(BrowserThread::IO);// PostTask outside the constructor to ensure at least one reference exists.loop->PostTask(FROM_HERE,base::Bind(&BrowserGpuChannelHostFactory::EstablishRequest::EstablishOnIO,establish_request));return establish_request; }? ? ??這個函數定義在文件external/chromium_org/content/browser/gpu/browser_gpu_channel_host_factory.cc中。? ? ? EstablishRequest類的靜態成員函數Create首先將參數cause、gpu_client_id和gpu_host_id封裝在一個EstablishRequest對象中，接著向當前進程的IO的消息隊列發送一個Task，該Task綁定的函數為EstablishRequest類的成員函數EstablishOnIO，并且當該函數被調用時，this指針指向的是上述封裝的EstablishRequest對象。
? ? ??EstablishRequest類的成員函數EstablishOnIO的實現如下所示：
void BrowserGpuChannelHostFactory::EstablishRequest::EstablishOnIO() {GpuProcessHost* host = GpuProcessHost::FromID(gpu_host_id_);if (!host) {host = GpuProcessHost::Get(GpuProcessHost::GPU_PROCESS_KIND_SANDBOXED,cause_for_gpu_launch_);......gpu_host_id_ = host->host_id();......} ......host->EstablishGpuChannel(gpu_client_id_,true,base::Bind(&BrowserGpuChannelHostFactory::EstablishRequest::OnEstablishedOnIO,this)); }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/browser_gpu_channel_host_factory.cc中。? ? ? ?在Chroimum中，可能會存在兩個GPU進程，其中一個是受限GPU進程，運行在沙箱中，通過枚舉值GpuProcessHost::GPU_PROCESS_KIND_SANDBOXED描述，另外一個是特權GPU進程，不用運行在沙箱中，通過枚舉值GpuProcessHost::GPU_PROCESS_KIND_UNSANDBOXED描述。同時，每一個GPU進程都分配有一個Host ID，這個ID值保存在EstablishRequest類的成員變量gpu_host_id_中。
? ? ? ?EstablishRequest類的成員函數EstablishOnIO首先是調用GpuProcessHost類的靜態成員函數FromID檢查與它的成員變量gpu_host_id_對應的GPU進程是否已經啟動過了。如果已經啟動過了，那么就會得到一個GpuProcessHost對象。也就是說，每一個GPU進程在Browser進程中，都通過一個GpuProcessHost對象描述，并且每一個GpuProcessHost對象都有一個對應的Host ID。
? ? ? ?如果與EstablishRequest類的成員變量gpu_host_id_對應的GPU進程還沒有創建，那么接下來就會調用GpuProcessHost類的靜態成員函數Get啟動一個類型為GpuProcessHost::GPU_PROCESS_KIND_SANDBOXED的GPU進程，也就是創建一個運行沙箱中的GPU進程。創建啟動成功，那么就可以獲得一個GpuProcessHost對象。由于分配給這個GpuProcessHost對象的Host ID可能發生了變化，因此就通過調用它的成員函數host_id獲得它現在使用的Host ID，并且保存在EstablishRequest類的成員變量gpu_host_id_中。
? ? ? ?最后，EstablishRequest類的成員函數EstablishOnIO就調用上述獲得的GpuProcessHost對象的成員函數EstablishGpuChannel創建一個到它所描述的GPU進程的GPU通道。接下來，我們先分析GpuProcessHost類的靜態成員函數Get啟動GPU進程的過程，接下來再分析GpuProcessHost類的成員函數EstablishGpuChannel創建GPU通道的過程。
? ? ? ?GpuProcessHost類的靜態成員函數Get的實現如下所示：
GpuProcessHost* g_gpu_process_hosts[GpuProcessHost::GPU_PROCESS_KIND_COUNT];......GpuProcessHost* GpuProcessHost::Get(GpuProcessKind kind,CauseForGpuLaunch cause) {......if (g_gpu_process_hosts[kind] && ValidateHost(g_gpu_process_hosts[kind]))return g_gpu_process_hosts[kind];......static int last_host_id = 0;int host_id;host_id = ++last_host_id;......GpuProcessHost* host = new GpuProcessHost(host_id, kind);if (host->Init())return host;...... }? ? ? ?這個函數定義在文件xternal/chromium_org/content/browser/gpu/gpu_process_host.cc中。? ? ? ?全局變量g_gpu_process_hosts是一個GpuProcessHost數組，它的大小為GpuProcessHost::GPU_PROCESS_KIND_COUNT，即等于2，它是用來保存上面提到的用來描述GPU進程的GpuProcessHost對象。也就是說，每當我們創建一個GPU進程的時候，就會創建一個GpuProcessHost對象，并且將該GpuProcessHost對象按照它的類型（puProcessHost::GPU_PROCESS_KIND_UNSANDBOXED或者puProcessHost::GPU_PROCESS_KIND_SANDBOXED）保存在全局g_gpu_process_hosts描述的GpuProcessHost數組中。
? ? ? ?GpuProcessHost類的靜態成員函數Get首先做的便是根據參數kind指定的GPU進程類型在全局變量g_gpu_process_hosts描述的GpuProcessHost數組中檢查是否已經存在一個對應的GpuProcessHost對象。如果已經存在，那么就說明請求啟動的GPU進程已經啟動起來了，因此就不用再往下處理了。否則的話，就會創建一個GpuProcessHost對象，并且調用該GpuProcessHost對象的成員函數Init啟動一個GPU進程。
? ? ? ?我們首先分析GpuProcessHost對象的創建過程，即GpuProcessHost類的構造函數的實現，如下所示：
GpuProcessHost::GpuProcessHost(int host_id, GpuProcessKind kind): ......,in_process_(false),...... {if (CommandLine::ForCurrentProcess()->HasSwitch(switches::kSingleProcess) ||CommandLine::ForCurrentProcess()->HasSwitch(switches::kInProcessGPU)) {in_process_ = true;}......g_gpu_process_hosts[kind] = this;......process_.reset(new BrowserChildProcessHostImpl(PROCESS_TYPE_GPU, this)); }? ? ? ?這個函數定義在文件xternal/chromium_org/content/browser/gpu/gpu_process_host.cc中。? ? ? ?GpuProcessHost類有一個重要的成員變量in_process_。當Chromium的命令行參數中設置了switches::kSingleProcess或者switches::kInProcessGPU選項的時候，它的值等于true。否則的話，它的值就等于false。
? ? ? ?當GpuProcessHost類的成員變量in_process_的值等于true的時候，表示在Browser進程中創建一個GPU線程來代替GPU進程。這種GPU渲染方式在Chromium中就稱為In-Process GPU渲染。這意味著，Browser進程接收到GPU相關的操作時，都轉發給它的GPU線程處理。由于Browser進程與GPU線程和GPU進程的通信過程都統一封裝為IPC通道或者GPU通道操作，因此不管采用的是In-Process GPU渲染方式，還是獨立GPU進程的渲染方式，它們提供給Browser進程的接口，都是一樣的。
? ? ? ?GpuProcessHost類還有另外一個成員變量process_，它指向的是一個BrowserChildProcessHostImpl對象。通過該BrowserChildProcessHostImpl對象，GpuProcessHost類可以向GPU線程或者GPU進程發送IPC消息，或者接收從GPU線程或者GPU進程發送過來的IPC消息。
? ? ? ?從這里還可以看到，正在創建的GpuProcessHost對象被保存在全局變量g_gpu_process_hosts中，這樣以后就可以檢查指定類型的GPU進程是否已經啟動過了。
? ? ? ?回到GpuProcessHost類的靜態成員函數Get中，當它創建了一個GpuProcessHost對象之后，接下來就會調用這個GpuProcessHost對象的成員函數Init啟動一個GPU進程或者一個GPU線程，它的實現如下所示：
bool GpuProcessHost::Init() {......std::string channel_id = process_->GetHost()->CreateChannel();if (channel_id.empty())return false;if (in_process_) {......in_process_gpu_thread_.reset(g_gpu_main_thread_factory(channel_id));in_process_gpu_thread_->Start();......} else if (!LaunchGpuProcess(channel_id)) {return false;}if (!Send(new GpuMsg_Initialize()))return false;return true; }? ? ? 這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_process_host.cc中。? ? ??GpuProcessHost類的成員函數Init首先通過調用成員變量process_指向的BrowserChildProcessHostImpl對象的成員函數GetHost獲得其內部的一個ChildProcessHostImpl對象。有了這個ChildProcessHostImpl對象之后，再調用它的成員函數CreateChannel創建一個IPC通道，如下所示：
std::string ChildProcessHostImpl::CreateChannel() {channel_id_ = IPC::Channel::GenerateVerifiedChannelID(std::string());channel_ = IPC::Channel::CreateServer(channel_id_, this);if (!channel_->Connect())return std::string();......return channel_id_; }? ? ? ?這個函數定義在文件external/chromium_org/content/common/child_process_host_impl.cc中。? ? ? ?ChildProcessHostImpl類的成員函數CreateChannel首先是調用IPC::Channel類的靜態成員函數GenerateVerifiedChannelID生成一個唯一的UNIX Socket名稱，接著再調用IPC::Channel類的靜態成員函數CreateServer根據上述UNIX Socket名稱創建一個UNIX Socket。
? ? ? ?IPC::Channel類的靜態成員函數GenerateVerifiedChannelID的實現可以參考前面Chromium的Render進程啟動過程分析一文，它的另外一個靜態成員函數CreateServer的實現如下所示：
scoped_ptr<Channel> Channel::CreateServer(const IPC::ChannelHandle &channel_handle, Listener* listener) {return Channel::Create(channel_handle, Channel::MODE_SERVER, listener); }? ? ? ?這個函數定義在文件external/chromium_org/ipc/ipc_channel_common.cc中。? ? ? ?IPC::Channel類的靜態成員函數CreateServer調用了Channel類的靜態成員函數Create創建了一個UNIX Socket，并且將其Server端文件描述符封裝在一個ChannelPosix對象。這個過程可以參考前面Chromium的Render進程啟動過程分析一文。
? ? ? ?回到ChildProcessHostImpl類的成員函數CreateChannel中，它通過IPC::Channel類的靜態成員函數CreateServer獲得一個ChannelPosix對象之后，再調用該ChannelPosix對象的成員函數Connect，這樣就可以將前面所創建的一個UNIX Socket的Server端文件描述符增加到當前進程的IO線程的消息隊列中去監控，也就是監控它的IO事件，用來接收以后GPU進程或者GPU線程給它發送的IPC消息。這個過程也可以參考前面Chromium的Render進程啟動過程分析一文。
? ? ? ?再回到GpuProcessHost類的成員函數Init中，它調用ChildProcessHostImpl類的成員函數CreateChannel創建了一個Server端的IPC通道之后，接下來根據成員變量in_process_的值決定是要在當前進程中創建一個GPU線程，還是要創建一個獨立的GPU進程。
? ? ? ?根據前面的分析，當GpuProcessHost類的成員變量in_process_的值等于true的時候，表示要在當前進程，也就是Browser進程，創建一個GPU線程。接下來我們就首先分析GPU線程的創建過程。
? ? ? ?g_gpu_main_thread_factory是一個類型為GpuMainThreadFactoryFunction的函數指針，它的定義如下所示：
GpuMainThreadFactoryFunction g_gpu_main_thread_factory = NULL;? ? ? ?這個全局變量定義在文件external/chromium_org/content/browser/gpu/gpu_process_host.cc中。
? ? ? ?GpuMainThreadFactoryFunction的定義如下所示：
typedef base::Thread* (*GpuMainThreadFactoryFunction)(const std::string& id);? ? ? ?這個函數指針類型定義在文件external/chromium_org/content/browser/gpu/gpu_process_host.h中。? ? ? ?從這里可以看到，GpuMainThreadFactoryFunction函數指針指向的函數有一個類型為std::string&的參數，這個參數描述的是一個UNIX Socket名稱，并且該函數的返回值是一個 Thread對象，該Thread對象描述的就是一個線程。
? ? ? ?Browser進程啟動的過程中，會調用一個函數RegisterMainThreadFactories設置全局變量g_gpu_main_thread_factory的值，如下所示：
static void RegisterMainThreadFactories() {......GpuProcessHost::RegisterGpuMainThreadFactory(CreateInProcessGpuThread);...... }? ? ? 這個函數定義在文件external/chromium_org/content/app/content_main_runner.cc中。? ? ? 函數RegisterMainThreadFactories通過調用GpuProcessHost類的靜態成員函數RegisterGpuMainThreadFactory設置全局變量g_gpu_main_thread_factory的值，如下所示：
void GpuProcessHost::RegisterGpuMainThreadFactory(GpuMainThreadFactoryFunction create) {g_gpu_main_thread_factory = create; }? ? ? ?這個函數指針類型定義在文件external/chromium_org/content/browser/gpu/gpu_process_host.cc中。? ? ? ?這意味著全局變量g_gpu_main_thread_factory指向的函數為CreateInProcessGpuThread。
? ? ? ?回到GpuProcessHost類的成員數Init中，它首先通過調用全局變量g_gpu_main_thread_factory指向的函數創建一個線程對象，也就是通過調用函數CreateInProcessGpuThread創建一個線程對象，接著再調用該線程對象的成員函數Start啟動一個GPU線程。?
? ? ? ?函數CreateInProcessGpuThread的實現如下所示：
base::Thread* CreateInProcessGpuThread(const std::string& channel_id) {return new InProcessGpuThread(channel_id); }? ? ? ?這個函數定義在文件external/chromium_org/content/gpu/in_process_gpu_thread.cc中。? ? ? ?函數CreateInProcessGpuThread返回的是一個InProcessGpuThread對象，該對象的創建過程如下所示：
InProcessGpuThread::InProcessGpuThread(const std::string& channel_id): base::Thread("Chrome_InProcGpuThread"),channel_id_(channel_id),gpu_process_(NULL) { }? ? ? ?這個函數定義在文件external/chromium_org/content/gpu/in_process_gpu_thread.cc中。? ? ? ?InProcessGpuThread類的構造函數主要做兩件事件。第一件事情是調用父類Thread的構造函數對父類部分對象進行初始化，第二件事件是將前面創建的一個UNIX Socket的名稱保存在成員變量channel_id_中。
? ? ? ?這意味著，Browser進程中的GPU線程是通過一個InProcessGpuThread對象來描述的。從前面Chromium多線程模型設計和實現分析一文可以知道，當調用這個InProcessGpuThread對象的成員函數Start（從父類Thread繼承下來）的時候，就可以啟動一個線程。這個線程在進入消息循環之前，會先調用由子類實現的成員函數Init，也就是InProcessGpuThread類的成員函數Init，對線程執行初始化工作。
? ? ? ?InProcessGpuThread類的成員函數Init的實現如下所示：
void InProcessGpuThread::Init() {gpu_process_ = new GpuProcess();// The process object takes ownership of the thread object, so do not// save and delete the pointer.gpu_process_->set_main_thread(new GpuChildThread(channel_id_)); }? ? ? ?這個函數定義在文件external/chromium_org/content/gpu/in_process_gpu_thread.cc中。
? ? ? ?InProcessGpuThread類的成員函數Init首先創建了一個GpuProcess對象，并且保存在成員變量gpu_process_中。這個GpuProcess對象就是圖1所示的GpuProcess對象，用來與Browser進程進行IPC。這個GpuProcess對象本來是應該在GPU進程中創建的，但是由于在我們這個情景中，只有GPU線程沒有GPU進程，不過兩者是等價的，因此，在GPU線程中創建一個GpuProcess對象起到的效果和作用與在GPU進程中創建一個GpuProcess對象是相同的。
? ? ? ?GpuProcess類是從ChildProcess類繼承下來的，如下所示：
class GpuProcess : public ChildProcess {..... };? ? ? ?這個類定義在文件external/chromium_org/content/gpu/gpu_process.h中。? ? ? ?這意味著在創建GpuProcess對象的過程中，會觸發對ChildProcess類的構造函數的調用，如下所示：
GpuProcess::GpuProcess() { }? ? ? ?這個函數定義在文件external/chromium_org/content/gpu/gpu_process.cc中。? ? ? ?GpuProcess類的構造函數調用的是父類ChildProcess的默認構造函數。我們在前面Chromium的Render進程啟動過程分析一文中已經分析過ChildProcess的默認構造函數了，它主要就是創建一個IO線程。這個IO線程就是負責與Browser進程或者其它進程（例如Render進程和Plugin進程）的IO線程進行IPC的。
? ? ? ?回到InProcessGpuThread類的成員函數Init中，它在GPU線程中創建了一個GpuProcess對象之后，就獲得了一個IO線程，接下來它又創建了一個GpuChildThread對象。這個GpuChildThread對象也是用來描述當前所在的GPU線程，并且這個GpuChildThread對象會被設置到前面創建的GpuProcess對象中，表示前面創建的GpuProcess對象所描述的“進程”的主線程就是這里創建的GpuChildThread對象所描述的GPU線程。
? ? ? ?GpuChildThread對象的創建過程如下所示：
GpuChildThread::GpuChildThread(const std::string& channel_id): ChildThread(channel_id),......,in_browser_process_(true) {...... #if !defined(OS_ANDROID)// For single process and in-process GPU mode, we need to load and// initialize the GL implementation and locate the GL entry points here.// On Android, GLSurface::InitializeOneOff() is called from BrowserMainLoop// before getting here. crbug.com/326295if (!gfx::GLSurface::InitializeOneOff())VLOG(1) << "gfx::GLSurface::InitializeOneOff failed"; #endif...... }? ? ? 這個函數定義在文件external/chromium_org/content/gpu/gpu_child_thread.cc。? ? ??GpuChildThread類的構造函數主要做兩件事情。
? ? ? 第一件事情是將參數channel_id描述的UNIX Socket的名稱傳遞給父類ChildThread的構造函數，以便后者可以根據該UNIX Socket的名稱獲得前面在ChildProcessHostImpl類的成員函數CreateChannel中創建的一個UNIX Socket的Client端文件描述符。有了這個UNIX Socket的Client端文件描述符之后，就可以創建一個Client端IPC通道了。這個Client端IPC通道以后就可以用來與Browser進程或者其它進程（例如Render進程和Plugin進程）的Server端IPC通道進行通信。ChildThread類的構造函數創建Client端IPC通道的過程可以參考前面Chromium的Render進程啟動過程分析一文。
? ? ? 第二件事情是在非Android平臺才會做的，就是調用前面分析過的gfx::GLSurface類的靜態成員函數InitializeOneOff在當前進程中加載OpenGL相關的庫，以及創建一個EGLDisplay，以便以后可以創建OpenGL上下文。這是由于在Android平臺上，前面在調用BrowserMainLoop類的成員函數BrowserThreadsStarted的時候，已經調用過gfx::GLSurface類的靜態成員函數InitializeOneOff了，因此這里就不需要再重復調用。
? ? ? ?這樣，在Browser進程中創建一個GPU線程的過程就分析完成了。這個GPU線程通過InProcessGpuThread類描述，并且在它的啟動的過程中，主要是做了以下兩件事情：
? ? ? ?1. 創建了一個GpuProcess對象，用來描述一個假設存在的GPU進程，這將會觸發創建一個IO線程。注意，Browser進程本來也有一個IO線程。這個原有的IO線程是Browser進程用來與其它進程（例如GPU進程、Render進程和Plugin進程）進行IPC的。而這里新創建的IO線程是GPU線程用來與其他進程（例如Browser進程、Render進程和Plugin進程）進行IPC的。
? ? ? ?2. 創建了一個GpuChildThread對象，該GpuChildThread對象描述的也是Browser進程中的GPU線程，這將會觸發創建一個Client端IPC通道。這個Client端IPC通道是GPU線程用來與其他進程（例如Browser進程、Render進程和Plugin進程）的Server端IPC通道進行IPC的。
? ? ? ?上述兩個對象在GPU進程的啟動過程也同樣會創建的。正是通過這種相同的方式，使得Browser進程與GPU線程和GPU進程的通信方式和過程都是一樣的，也就是說，Browser進程需要執行GPU操作時，不需要知道這些GPU操作是在它的一個GPU線程中執行，還是在一個獨立的GPU進程中執行。同樣的，Render進程和Plugin進程需要執行GPU操作時，也不需要關心這些GPU操作是在Browser進程中的一個GPU線程中執行，還是在一個獨立日GPU進程中執行。
? ? ? ?回到GpuProcessHost類的成員函數Init中，接下來我們分析另外一個情景，即啟動GPU進程的情況。這是通過調用GpuProcessHost類的成員函數LaunchGpuProcess實現的，如下所示：
bool GpuProcessHost::LaunchGpuProcess(const std::string& channel_id) {......base::FilePath exe_path = ChildProcessHost::GetChildPath(child_flags);......CommandLine* cmd_line = new CommandLine(exe_path);cmd_line->AppendSwitchASCII(switches::kProcessType, switches::kGpuProcess);......process_->Launch(new GpuSandboxedProcessLauncherDelegate(cmd_line,process_->GetHost()),...... }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_process_host.cc中。
? ? ? ?GpuProcessHost類的成員函數LaunchGpuProcess首先是創建了GPU進程的命令行參數。這個命令行參數設置了一個重要的選項switches::kProcessType，它的值等于switches::kGpuProcess。
? ? ? ?GpuProcessHost類的成員函數LaunchGpuProcess接下來將上述命令行參數傳遞給成員變量process_指向的一個BrowserChildProcessHostImpl對象的成員函數Launch，以便后者可以啟動一個GPU進程。
? ? ? ?BrowserChildProcessHostImpl類的成員函數Launch的實現如下所示：
void BrowserChildProcessHostImpl::Launch(SandboxedProcessLauncherDelegate* delegate,CommandLine* cmd_line) {......child_process_.reset(new ChildProcessLauncher(delegate,cmd_line,data_.id,this)); }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/browser_child_process_host_impl.cc中。? ? ? ?從這里可以看到，BrowserChildProcessHostImpl類的成員函數Launch主要是創建了一個ChildProcessLauncher對象，并且保存在成員變量child_process_中。從前面Chromium的Render進程啟動過程分析一文可以知道，在ChildProcessLauncher對象的創建過程中，也就是在ChildProcessLauncher類的構造函數中，將會通過JNI調用Java層的一個Conext接口的成員函數bindService啟動一個Service進程。
? ? ? ?從前面Chromium的Render進程啟動過程分析一文還可以知道，當前進程，也就是Browser進程，會將前面在ChildProcessHostImpl類的成員函數CreateChannel中創建的一個UNIX Socket的Client端文件描述符通過Binder IPC傳遞給上述Service進程，以便后者可以創建一個Client端IPC通道與Browser進程進行通信。最后，上述Service進程會通過JNI調用Native層的函數RunNamedProcessTypeMain，后者的實現如下所示：
int RunNamedProcessTypeMain( const std::string& process_type, const MainFunctionParams& main_function_params, ContentMainDelegate* delegate) { static const MainFunction kMainFunctions[] = { #if !defined(CHROME_MULTIPLE_DLL_CHILD) { "", BrowserMain }, #endif #if !defined(CHROME_MULTIPLE_DLL_BROWSER) #if defined(ENABLE_PLUGINS) #if !defined(OS_LINUX) { switches::kPluginProcess, PluginMain }, #endif { switches::kWorkerProcess, WorkerMain }, { switches::kPpapiPluginProcess, PpapiPluginMain }, { switches::kPpapiBrokerProcess, PpapiBrokerMain }, #endif // ENABLE_PLUGINS { switches::kUtilityProcess, UtilityMain }, { switches::kRendererProcess, RendererMain }, { switches::kGpuProcess, GpuMain }, #endif // !CHROME_MULTIPLE_DLL_BROWSER }; ...... for (size_t i = 0; i < arraysize(kMainFunctions); ++i) { if (process_type == kMainFunctions[i].name) { if (delegate) { int exit_code = delegate->RunProcess(process_type, main_function_params); #if defined(OS_ANDROID) // In Android's browser process, the negative exit code doesn't mean the // default behavior should be used as the UI message loop is managed by // the Java and the browser process's default behavior is always // overridden. if (process_type.empty()) return exit_code; #endif if (exit_code >= 0) return exit_code; } return kMainFunctions[i].function(main_function_params); } } ...... } ? ? ? ?這個函數定義在文件external/chromium_org/content/app/content_main_runner.cc中。? ? ? ?在前面Chromium的Render進程啟動過程分析一文中，我們已經分析過函數RunNamedProcessTypeMain的實現了，不過這時候它的參數process_type的值等于switches::kGpuProcess，也就是來自于前面提到的命令行參數中的switches::kProcessType選項，因此接下來函數RunNamedProcessTypeMain將調用函數GpuMain作為GPU進程的入口函數。
? ? ? ?函數GpuMain的實現如下所示：
int GpuMain(const MainFunctionParams& parameters) {......base::MessageLoop main_message_loop(base::MessageLoop::TYPE_IO);......// Warm up resources that don't need access to GPUInfo.if (WarmUpSandbox(command_line)) {......// Determine if we need to initialize GL here or it has already been done.bool gl_already_initialized = false;......if (command_line.HasSwitch(switches::kInProcessGPU)) {// With in-process GPU, GLSurface::InitializeOneOff() is called from// GpuChildThread before getting here.gl_already_initialized = true;}// Load and initialize the GL implementation and locate the GL entry points.bool gl_initialized =gl_already_initialized? gfx::GetGLImplementation() != gfx::kGLImplementationNone: gfx::GLSurface::InitializeOneOff();......}......GpuProcess gpu_process;......GpuChildThread* child_thread = new GpuChildThread(watchdog_thread.get(),dead_on_arrival,gpu_info,deferred_messages.Get());......gpu_process.set_main_thread(child_thread);{......main_message_loop.Run();}......return 0; }? ? ? ?這個函數定義在文件external/chromium_org/content/gpu/gpu_main.cc中。? ? ? ?函數GpuMain主要做了以下幾件事情：
? ? ? ?1. 創建了一個IO類型的消息循環，后面將會將該消息循環作為當前線程的消息循環。
? ? ? ?2. 調用函數WarmUpSandbox判斷是否需要執行一些預加載操作。如果需要的話，接下來就會繼續判斷當前進程的命令行參數是否包含了switches::kInProcessGPU選項。如果沒有包括，那么再接下來就會調用我們前面分析過的gfx::GLSurface類的靜態成員函數InitializeOneOff在當前進程加載OpenGL相關的庫，以及創建一個EGLDisplay，以便以后可以用來創建OpenGL上下文。函數WarmUpSandbox的返回值總為true，并且當前進程的命令行參數沒有包含switches::kInProcessGPU選項，因此最后會調用gfx::GLSurface類的靜態成員函數InitializeOneOff。
? ? ? ?3. 創建了一個GpuProcess對象。從前面的分析可以知道，創建GpuProcess對象將會導致在當前進程中創建一個IO線程。這個IO線程是用來與其他進程（例如Browser進程、Render進程和Plugin進程）進行IPC的。
? ? ? ?4. 創建了一個GpuChildThread對象，該GpuChildThread對象描述的線程即為當前線程，并且會將當前線程設置為當前進程（也就是GPU進程）的主線程。從前面的分析可以知道，創建GpuChildThread對象將會觸發創建一個Client端IPC通道。這個Client端IPC通道是GPU進程用來與其他進程（例如Browser進程、Render進程和Plugin進程）的Server端IPC通道進行IPC的。
? ? ? ?5. 通過前面創建的消息循環使得當前線程進入消息循環狀態。
? ? ? ?這樣，GPU進程的啟動過程就完成了?；氐角懊娣治龅腉puProcessHost類的成員函數Init中，無論它之前啟動的是一個GPU線程，還是一個GPU進程，都會向它發送一個類型為GpuMsg_Initialize的IPC消息，用來對GPU進程執行初始化工作。
? ? ? ?GpuMsg_Initialize是一個類型為MSG_ROUTING_CONTROL的IPC消息，根據前面Chromium的IPC消息發送、接收和分發機制分析一文的IPC消息分發機制，這個消息首先是分給在GPU進程或者GPU線程中創建的GpuChildThread對象的父類ChildThread的成員函數OnMessageReceived處理，如下所示：
bool ChildThread::OnMessageReceived(const IPC::Message& msg) {......if (msg.routing_id() == MSG_ROUTING_CONTROL)return OnControlMessageReceived(msg);...... }? ? ? ?這個函數定義在文件external/chromium_org/content/child/child_thread.cc中。? ? ? ?ChildThread的成員函數OnMessageReceived發現這是一個類型為MSG_ROUTING_CONTROL的IPC消息，于是就會將它分發給另外一個成員函數OnControlMessageReceived處理。GpuChildThread類重寫了父類ChildThread的成員函數OnControlMessageReceived，因此接下來參數msg描述的IPC消息繼續分發給GpuChildThread類的成員函數OnControlMessageReceived處理。
? ? ? ?GpuChildThread類的成員函數OnControlMessageReceived的實現如下所示：
bool GpuChildThread::OnControlMessageReceived(const IPC::Message& msg) {bool handled = true;IPC_BEGIN_MESSAGE_MAP(GpuChildThread, msg)IPC_MESSAGE_HANDLER(GpuMsg_Initialize, OnInitialize)......IPC_MESSAGE_UNHANDLED(handled = false)IPC_END_MESSAGE_MAP()if (handled)return true;...... }? ? ? ?這個函數定義在文件external/chromium_org/content/gpu/gpu_child_thread.cc中。? ? ? ?從這里可以看到，IPC消息GpuMsg_Initialize最后將由GpuChildThread類的成員函數OnInitialize進行處理，它的主要處理過程如下所示：
void GpuChildThread::OnInitialize() {......gpu_channel_manager_.reset(new GpuChannelManager(GetRouter(),watchdog_thread_.get(),ChildProcess::current()->io_message_loop_proxy(),ChildProcess::current()->GetShutDownEvent()));...... }? ? ? ?這個函數定義在文件external/chromium_org/content/gpu/gpu_child_thread.cc中。? ? ? ?GpuChildThread類的成員函數OnInitialize主要是創建了一個GpuChannelManager對象，并且保存在成員變量gpu_channel_manager_中。這個GpuChannelManager是用來負責管理GPU進程與其它進程之間的GPU通道的，接下來我們分析GPU通道的創建過程時就會看到這一點。
? ? ? ?注意，GpuChildThread類的成員函數OnInitialize在創建上述GpuChannelManager對象時，會傳遞給它兩個重要的參數，即第一個參數和第三個參數。其中，第三個參數是GPU進程負責用來與其它進程執行IPC的IO線程的消息循環。第一個參數是一個MessageRouter對象，是通過調用從父類ChildThread繼承下來的成員函數GetRouter獲得的，如下所示：
MessageRouter* ChildThread::GetRouter() {......return &router_; }? ? ? ?這個函數定義在文件external/chromium_org/content/child/child_thread.cc中。? ? ? ?ChildThread類的成員函數GetRouter返回的是成員變量router_描述的一個MessageRouter對象。后面我們分析GPU通道的創建過程時再解釋它的作用。
? ? ? ?上述兩個參數最后將會保存在GpuChannelManager類的成員變量router_和io_message_loop_中，如下所示：
GpuChannelManager::GpuChannelManager(MessageRouter* router,GpuWatchdog* watchdog,base::MessageLoopProxy* io_message_loop,base::WaitableEvent* shutdown_event): ......,io_message_loop_(io_message_loop),......,router_(router),...... {...... }? ? ? ?這個函數定義在文件external/chromium_org/content/common/gpu/gpu_channel_manager.cc。? ? ? ?以后涉及到IPC消息的分發過程中，在沒有必要的情況下，我們將會略過中間的分發過程，而直接進入到最終的處理函數。中間略過的過程讀者可以參考Chromium的IPC消息發送、接收和分發機制一文自行分析。
? ? ? ?這樣，Browser進程啟動GPU線程或者GPU進程的過程就分析完成了，但是這時候Browser進程與GPU線程或者GPU進程僅僅是建立了一個普通的IPC通道。從前面的圖1可以看到，Browser進程與GPU進程之間的GPU操作是通過一個專門的GPU通道進行的，這一點也適用于GPU線程。因此，接下來Browser進程還需要與GPU進程或者GPU線程建立一個GPU通道。
? ? ? ?前面分析EstablishRequest類的成員函數EstablishOnIO的時候提到，它在啟動了GPU進程或者GPU線程之后，會調用GpuProcessHost類的成員函數EstablishGpuChannel創建一個GPU通道，如下所示：
void GpuProcessHost::EstablishGpuChannel(int client_id,bool share_context,const EstablishChannelCallback& callback) {......if (Send(new GpuMsg_EstablishChannel(client_id, share_context))) {channel_requests_.push(callback);} ...... }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_process_host.cc中。? ? ? ?GpuProcessHost類的成員函數EstablishGpuChannel向剛才啟動起來的GPU進程或者GPU線程發送一個類型為GpuMsg_EstablishChannel的IPC消息。發送成功后，參數callback指向的一個EstablishChannelCallback對象將會保存在GpuProcessHost類的成員變量channel_requests_描述的一個std::queue中，以便等到發送出去的IPC消息得到回復時進行相應的處理。
? ? ? ?從前面的調用過程可以知道，參數callback指向的一個EstablishChannelCallback對象描述的是一個Task，該Task綁定的函數為BrowserGpuChannelHostFactory::EstablishRequest類的成員函數OnEstablishedOnIO，因此，當類型為GpuMsg_EstablishChannel的IPC消息得到回復時，BrowserGpuChannelHostFactory::EstablishRequest類的成員函數OnEstablishedOnIO會被調用。
? ? ? ?類型為GpuMsg_EstablishChannel的IPC消息由GpuChildThread類的成員函數OnControlMessageReceived分發給GpuChannelManager類的成員函數OnMessageReceived處理，如下所示：
bool GpuChildThread::OnControlMessageReceived(const IPC::Message& msg) {......return gpu_channel_manager_.get() &&gpu_channel_manager_->OnMessageReceived(msg); }? ? ? 這個函數定義在文件external/chromium_org/content/gpu/gpu_child_thread.cc中。? ? ? GpuChildThread類的成員變量gpu_channel_manager_指向的GpuChannelManager對象是GPU進程或者GPU線程前面接收到類型為GpuMsg_Initialize的IPC消息時創建的，GpuChildThread類的成員函數OnControlMessageReceived將類型為GpuMsg_EstablishChannel的IPC消息分給它處理，如下所示：
bool GpuChannelManager::OnMessageReceived(const IPC::Message& msg) {bool handled = true;IPC_BEGIN_MESSAGE_MAP(GpuChannelManager, msg)IPC_MESSAGE_HANDLER(GpuMsg_EstablishChannel, OnEstablishChannel)......IPC_MESSAGE_UNHANDLED(handled = false)IPC_END_MESSAGE_MAP()return handled; }? ? ? 這個函數定義在文件external/chromium_org/content/common/gpu/gpu_channel_manager.cc中。? ? ??GpuChannelManager類的成員函數OnMessageReceived將類型為GpuMsg_EstablishChannel的IPC消息分給另外一個成員函數OnEstablishChannel處理，如下所示：
void GpuChannelManager::OnEstablishChannel(int client_id, bool share_context) {IPC::ChannelHandle channel_handle;gfx::GLShareGroup* share_group = NULL;gpu::gles2::MailboxManager* mailbox_manager = NULL;if (share_context) {if (!share_group_.get()) {share_group_ = new gfx::GLShareGroup;DCHECK(!mailbox_manager_.get());mailbox_manager_ = new gpu::gles2::MailboxManager;}share_group = share_group_.get();mailbox_manager = mailbox_manager_.get();}scoped_ptr<GpuChannel> channel(new GpuChannel(this, watchdog_, share_group, mailbox_manager, client_id, false));channel->Init(io_message_loop_.get(), shutdown_event_);channel_handle.name = channel->GetChannelName();#if defined(OS_POSIX)// On POSIX, pass the renderer-side FD. Also mark it as auto-close so// that it gets closed after it has been sent.int renderer_fd = channel->TakeRendererFileDescriptor();DCHECK_NE(-1, renderer_fd);channel_handle.socket = base::FileDescriptor(renderer_fd, true); #endifgpu_channels_.set(client_id, channel.Pass());Send(new GpuHostMsg_ChannelEstablished(channel_handle)); }? ? ? ?這個函數定義在文件external/chromium_org/content/common/gpu/gpu_channel_manager.cc中。
? ? ? ?從前面的調用過程可以知道，參數share_context的值等于true，表示要創建的GPU通道與其它的GPU通道共享相同的OpenGL組，同時它們也共享相同的Mailbox管理器。這個相同的OpenGL共享組和Mailbox共享管理器由GpuChannelManager類的成員變量share_group_和mailbox_manager_描述。
? ? ? ?因此，當參數share_context的值等于true，并且GpuChannelManager類的成員變量share_group_和mailbox_manager_又等于NULL的時候，GpuChannelManager類的成員函數OnEstablishChannel就分別創建一個gfx::GLShareGroup對象和一個gpu::gles2::MailboxManager對象保存在它們之上。
? ? ? ?關于OpenGL共享組和Mailbox管理器，在后面一個系列的文章中分析Chromium的GPU渲染機制時，我們再詳細分析。
? ? ? ?GpuChannelManager類的成員函數OnEstablishChannel接下來創建了一個GpuChannel對象來描述一個GPU通道。這個GPU通道與前面分析的IPC通道一樣，底層都是通過一個UNIX Socket來描述的。在創建GpuChannel對象的過程中，也就是在GpuChannel類的構造函數的執行過程中，主要是生成了一個UNIX Socket的名稱，最后需要調用該GpuChannel對象的成員函數Init，才會根據前面生成的UINX Socket名稱創建一個UNIX Socket。
? ? ? ?調用前面創建的GpuChannel對象的成員函數GetChannelName和TakeRendererFileDescriptor可以分別獲得由它創建的UNIX Socket的名稱和Client端文件描述符。獲得的UNIX Socket的名稱和Client端文件描述符封裝在一個ChannelHandle對象中，該ChannelHandle對象又會進一步封裝在一個類型為GpuHostMsg_ChannelEstablished的IPC消息中。這個IPC消息最終被發送到Browser進程中去，作為Browser進程發送過來的類型為GpuMsg_EstablishChannel的IPC消息的回復。
? ? ? ?注意，類型為GpuMsg_EstablishChannel的IPC消息封裝的是一個ChannelHandle對象，也就是說，類型為GpuMsg_EstablishChannel的IPC消息的內容由ChannelHandle類描述。由于上述發送的類型為GpuMsg_EstablishChannel的IPC消息封裝的ChannelHandle對象包含了文件描述符，即一個UNIX Socket的Client端文件描述符，因此該IPC消息最后將通過sendmsg接口發送出去。這一點可以參考前面Chromium的IPC消息發送、接收和分發機制分析一文。
? ? ? ?參數client_id描述的是請求創建GPU通道的Client端的ID。從前面的調用過程可以知道，這個GPU通道的Client端即為Browser進程。最后，創建的GPU通道將會以參數client_id為鍵值，保存在GpuChannelManager類的成員變量gpu_channels_描述的一個GPU通道表中。也就是說，GpuChannelManager類負責管理GPU進程或者GPU線程中的所有GPU通道。
? ? ? ?接下來，我們分析GPU通道的創建過程，也就是GpuChannel類的構造函數和成員函數Init的實現。
? ? ? ?GpuChannel類的構造函數的實現如下所示：
GpuChannel::GpuChannel(GpuChannelManager* gpu_channel_manager,GpuWatchdog* watchdog,gfx::GLShareGroup* share_group,gpu::gles2::MailboxManager* mailbox,int client_id,bool software): gpu_channel_manager_(gpu_channel_manager),......,client_id_(client_id),share_group_(share_group ? share_group : new gfx::GLShareGroup),mailbox_manager_(mailbox ? mailbox : new gpu::gles2::MailboxManager),...... {......channel_id_ = IPC::Channel::GenerateVerifiedChannelID("gpu");...... }? ? ? ?這個函數定義在文件external/chromium_org/content/common/gpu/gpu_channel.cc中。
? ? ? ?GpuChannel類的構造函數調用IPC::Channel類的靜態成員函數GenerateVerifiedChannelID生成了一個UNIX Socket名稱，并且保存在成員變量中。這個UNIX Socket名稱接下來就是用來創建UNIX Socket的。
? ? ? ?此外，我們還可以看到，如果參數share_group和mailbox的值等于NULL，即當前正在創建的GPU通道不與其它GPU通道共享OpenGL組和Mailbox管理器，那么GpuChannel類的構造函數就會為當前正在創建的GPU通道創建一個獨享的OpenGL組和Mailbox管理器，并且分別保存在成員變量share_group_和mailbox_manager_中。
? ? ? ?GpuChannel類的成員函數Init的實現如下所示：
void GpuChannel::Init(base::MessageLoopProxy* io_message_loop,base::WaitableEvent* shutdown_event) {......// Map renderer ID to a (single) channel to that process.channel_ = IPC::SyncChannel::Create(channel_id_,IPC::Channel::MODE_SERVER,this,io_message_loop,false,shutdown_event);filter_ =new GpuChannelMessageFilter(weak_factory_.GetWeakPtr(),gpu_channel_manager_->sync_point_manager(),base::MessageLoopProxy::current());io_message_loop_ = io_message_loop;channel_->AddFilter(filter_.get());...... }? ? ? ?這個函數定義在文件external/chromium_org/content/common/gpu/gpu_channel.cc中。? ? ? ?GpuChannel類的成員函數Init調用IPC::SyncChannel類的靜態成員函數Create根據前面生成的名稱創建一個UNIX Socket，并且將這個UNIX Socket的Server端文件描述符封裝在一個SyncChannel對象中。這個SyncChannel對象保存在GpuChannel類的成員變量channel_中。IPC::SyncChannel類的靜態成員函數Create創建UNIX Socket以及Server端SyncChannel對象的過程可以參考前面Chromium的Render進程啟動過程分析一文。
? ? ? ?GpuChannel類的成員函數Init接下來創建了一個類型為GpuChannelMessageFilter的Filter，并且注冊到了前面創建的Server端SyncChannel對象中去。這樣以后通過該SyncChannel對象接收到的IPC消息，根據我們前面Chromium的IPC消息發送、接收和分發機制分析一文的分析，首先是分發給GpuChannelMessageFilter類的成員函數OnMessageReceived處理。如果GpuChannelMessageFilter類的成員函數OnMessageReceived不處理，那么再接著再分發給GpuChannel類的成員函數OnMessageReceived處理。GpuChannelMessageFilter類主要是用來攔截GPU相關的操作消息，然后做GPU調度狀態切換的。關于GPU調度，我們在后面一個系列文章中再詳細分析。
? ? ? ?這一步執行完成之后，回到GpuChannelManager類的成員函數OnEstablishChannel中，它最后將前面創建的UNIX Socket的名稱和Client端文件描述符通過一個類型為GpuHostMsg_ChannelEstablished的IPC消息發送給Browser進程。
? ? ? ?Browser進程通過GpuProcessHost類的成員函數OnMessageReceived接收上述類型為GpuHostMsg_ChannelEstablished的IPC消息，如下所示：
bool GpuProcessHost::OnMessageReceived(const IPC::Message& message) {......IPC_BEGIN_MESSAGE_MAP(GpuProcessHost, message)......IPC_MESSAGE_HANDLER(GpuHostMsg_ChannelEstablished, OnChannelEstablished)......IPC_END_MESSAGE_MAP()return true; }? ? ? 這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_process_host.cc中。? ? ? 從這里可以看到，GpuProcessHost類的成員函數OnMessageReceived將類型為GpuHostMsg_ChannelEstablished的IPC消息發分給另外一個成員函數OnChannelEstablished處理。
? ? ??GpuProcessHost類的成員函數OnChannelEstablished的實現如下所示：
void GpuProcessHost::OnChannelEstablished(const IPC::ChannelHandle& channel_handle) {......EstablishChannelCallback callback = channel_requests_.front();channel_requests_.pop();......callback.Run(channel_handle,GpuDataManagerImpl::GetInstance()->GetGPUInfo()); }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/gpu_process_host.cc中。? ? ? ?前面在分析GpuProcessHost類的成員函數EstablishGpuChannel時提到，Browser進程向GPU進程或者GPU線程發送一個類型為GpuMsg_EstablishChannel的IPC消息之后，會將一個綁定了BrowserGpuChannelHostFactory::EstablishRequest類的成員函數OnEstablishedOnIO的EstablishChannelCallback對象保存在GpuProcessHost類的成員變量channel_requests_描述的一個std::queue中。
? ? ? ?現在既然已經收到了類型為GpuMsg_EstablishChannel的IPC消息的回復，即一個類型為GpuHostMsg_ChannelEstablished的IPC消息，那么就可以調用上述EstablishChannelCallback對象綁定的函數了，即BrowserGpuChannelHostFactory::EstablishRequest類的成員函數OnEstablishedOnIO，它的實現如下所示：
void BrowserGpuChannelHostFactory::EstablishRequest::OnEstablishedOnIO(const IPC::ChannelHandle& channel_handle,const gpu::GPUInfo& gpu_info) {if (channel_handle.name.empty() && reused_gpu_process_) {// We failed after re-using the GPU process, but it may have died in the// mean time. Retry to have a chance to create a fresh GPU process.DVLOG(1) << "Failed to create channel on existing GPU process. Trying to ""restart GPU process.";EstablishOnIO();} else {channel_handle_ = channel_handle;gpu_info_ = gpu_info;FinishOnIO();} }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/browser_gpu_channel_host_factory.cc中。? ? ? ?從前面的分析過程可以知道，參數channel_handle指向的一個ChannelHandle對象的成員變量name描述的是一個用來創建GPU通道的UNIX Socket的名稱。當這個名稱不等于空的時候，就說明成功創建了一個GPU通道。在這種情況下，BrowserGpuChannelHostFactory::EstablishRequest類的成員函數OnEstablishedOnIO就會將參數channel_handle指向的一個ChannelHandle對象保存在成員變量channel_handle_中，并且將參數gpu_info指向的一個GPUInfo對象保存在成員變量gpu_info_中，該GPU對象描述的是GPU相關的信息。
? ? ? ?BrowserGpuChannelHostFactory::EstablishRequest類的成員函數OnEstablishedOnIO最后調用另外一個成員函數FinishOnIO根據接收到的UNIX Socket的Client端文件描述符創建一個Client端GPU通道。
? ? ? ?BrowserGpuChannelHostFactory::EstablishRequest類的成員函數FinishOnIO的實現如下所示：
void BrowserGpuChannelHostFactory::EstablishRequest::FinishOnIO() {event_.Signal();main_loop_->PostTask(FROM_HERE,base::Bind(&BrowserGpuChannelHostFactory::EstablishRequest::FinishOnMain,this)); }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/browser_gpu_channel_host_factory.cc中。? ? ? ?BrowserGpuChannelHostFactory::EstablishRequest類的成員函數FinishOnIO將創建Client端GPU通道的工作將給Browser進程的主線程處理，即在Browser進程的主線程中調用BrowserGpuChannelHostFactory::EstablishRequest類的成員函數FinishOnMain進行處理。
? ? ? ?BrowserGpuChannelHostFactory::EstablishRequest類的成員函數FinishOnMain的實現如下所示：
void BrowserGpuChannelHostFactory::EstablishRequest::FinishOnMain() {if (!finished_) {BrowserGpuChannelHostFactory* factory =BrowserGpuChannelHostFactory::instance();factory->GpuChannelEstablished();finished_ = true;} }? ? ??這個函數定義在文件external/chromium_org/content/browser/gpu/browser_gpu_channel_host_factory.cc中。
? ? ??BrowserGpuChannelHostFactory::EstablishRequest類的成員函數FinishOnMain首先獲得當前進程中的一個BrowserGpuChannelHostFactory單例，然后調用它的成員函數GpuChannelEstablished創建一個Client端GPU通道。
? ? ??BrowserGpuChannelHostFactory類的成員函數GpuChannelEstablished的實現如下所示：
void BrowserGpuChannelHostFactory::GpuChannelEstablished() {......if (pending_request_->channel_handle().name.empty()) {......} else {......gpu_channel_ = GpuChannelHost::Create(this,pending_request_->gpu_info(),pending_request_->channel_handle(),shutdown_event_.get());}......pending_request_ = NULL;...... }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/gpu/browser_gpu_channel_host_factory.cc中。? ? ? ?前面在分析BrowserGpuChannelHostFactory類的成員函數EstablishGpuChannel時提到，BrowserGpuChannelHostFactory類的成員變量pending_request_指向的是一個EstablishRequest對象，該EstablishRequest對象描述的是一個GPU通道創建請求。前面我們已經將接收到的用來創建Client端GPU通道的UNIX Socket的名稱和Client端文件描述符保存在了其成員變量channel_handle_描述的一個ChannelHandle對象中。這個ChannelHandle對象可以通過調用上述的EstablishRequest對象的成員函數channel_handle獲得。
? ? ? ?如前所述，當前面獲得的ChannelHandle對象的成員變量name描述的字符串不等于空的時候，就說明前面成功創建了一個Server端GPU通道。在這種情況下，BrowserGpuChannelHostFactory類的成員函數GpuChannelEstablished就調用GpuChannelHost類的靜態成員函數Create根據上述ChannelHandle對象創建一個Client端GPU通道，即一個GpuChannelHost對象，并且保存在成員變量gpu_channel_中。
? ? ? ?GpuChannelHost類的靜態成員函數Create的實現如下所示：
scoped_refptr<GpuChannelHost> GpuChannelHost::Create(GpuChannelHostFactory* factory,const gpu::GPUInfo& gpu_info,const IPC::ChannelHandle& channel_handle,base::WaitableEvent* shutdown_event) {......scoped_refptr<GpuChannelHost> host = new GpuChannelHost(factory, gpu_info);host->Connect(channel_handle, shutdown_event);return host; }? ? ? ?這個函數定義在文件external/chromium_org/content/common/gpu/client/gpu_channel_host.cc中。? ? ? ?GpuChannelHost類的靜態成員函數Create首先是創建了一個GpuChannelHost對象，接著調用該GpuChannelHost對象的成員函數Connect根據參數channel_handle描述的ChannelHandle對象創建一個Client端GPU通道。
? ? ? ?GpuChannelHost類的成員函數Connect的實現如下所示：
void GpuChannelHost::Connect(const IPC::ChannelHandle& channel_handle,base::WaitableEvent* shutdown_event) {// Open a channel to the GPU process. We pass NULL as the main listener here// since we need to filter everything to route it to the right thread.scoped_refptr<base::MessageLoopProxy> io_loop = factory_->GetIOLoopProxy();channel_ = IPC::SyncChannel::Create(channel_handle,IPC::Channel::MODE_CLIENT,NULL,io_loop.get(),true,shutdown_event);...... }
? ? ? ?這個函數定義在文件external/chromium_org/content/common/gpu/client/gpu_channel_host.cc中。
? ? ? ?GpuChannelHost類的成員函數Connect主要就是調用IPC::SyncChannel類的成員函數Create創建一個Client端GPU通道。從前面Chromium的Render進程啟動過程分析一文可以知道，IPC::SyncChannel類的成員函數Create最后會調用ChannelPosix類的成員函數CreatePipe創建前面在GPU進程或者GPU線程中創建的UNIX Socket的Client端文件描述符，如下所示：
bool ChannelPosix::CreatePipe(const IPC::ChannelHandle& channel_handle) {......int local_pipe = -1;if (channel_handle.socket.fd != -1) {......local_pipe = channel_handle.socket.fd;......} ......pipe_ = local_pipe;return true; }? ? ? ?這個函數定義在文件external/chromium_org/ipc/ipc_channel_posix.cc中。? ? ? ?從前面的調用過程可以知道，參數channel_handle指向的ChannelHandle對象包含了一個UNIX Socket的Client端文件描述符，這個Client端文件描述符就保存在該ChannelHandle對象的成員變量socket描述的一個FileDescriptor對象的成員變量fd中。因此，ChannelPosix類的成員函數CreatePipe就可以直接獲得該UNIX Socket的Client端文件描述符，并且保存在成員變量pipe_中，以后就可以通過它向GPU進程或者GPU線程請求執行GPU操作，也就是通過GPU通道向GPU進程或者GPU線程請求執行GPU操作。
? ? ? ?這一步執行完成之后，Browser進程與GPU進程或者GPU線程之間的GPU通道就創建完成了。這個GPU通道與普通的IPC通道一樣，都是通過UNIX Socket進行通信的，不過前者是專門用來執行GPU操作的。
? ? ? ?在Chromium中，除了Browser進程之外，Render進程和Plugin進程也需要執行GPU操作。這意味著Render進程和Plugin進程也需要和GPU進程或者GPU線程建立GPU通道。接下來我們就分析Render進程與GPU進程或者GPU線程建立GPU通道的過程。等到下一系列的文章分析完成Chromium的GPU渲染機制之后，我們再回頭來分析Plugin進程與GPU進程或者GPU線程建立GPU通道的過程。
? ? ? ?Render進程在兩種情況下需要使用GPU。第一種情況下是渲染網頁內容的時候，第二種情況是網頁包含了一個canvas標簽的時候。接下來我們就分別分析這兩種情況。
? ? ? ?Render進程使用一個content::RenderWidget對象來描述一個網頁。在使用GPU渲染網頁的時候，Render進程就會調用與該網頁關聯的content::RenderWidget對象的成員函數CreateOutputSurface創建一個繪圖表面。該繪圖表面最終會由交Browser進程與Chromium的其它UI進行合成，并且顯示在屏幕中。在繪圖表面的創建過程中，就會為之創建一個與GPU進程或者GPU線程進行通信的GPU通道，如下所示：
scoped_ptr<cc::OutputSurface> RenderWidget::CreateOutputSurface(bool fallback) {......#if defined(OS_ANDROID)if (SynchronousCompositorFactory* factory =SynchronousCompositorFactory::GetInstance()) {return factory->CreateOutputSurface(routing_id());} #endifconst CommandLine& command_line = *CommandLine::ForCurrentProcess();bool use_software = fallback;if (command_line.HasSwitch(switches::kDisableGpuCompositing))use_software = true;scoped_refptr<ContextProviderCommandBuffer> context_provider;if (!use_software) {context_provider = ContextProviderCommandBuffer::Create(CreateGraphicsContext3D(), "RenderCompositor");......}if (!context_provider.get()) {scoped_ptr<cc::SoftwareOutputDevice> software_device(new CompositorSoftwareOutputDevice());return scoped_ptr<cc::OutputSurface>(new CompositorOutputSurface(routing_id(),output_surface_id,NULL,software_device.Pass(),true));}......bool use_swap_compositor_frame_message = false;return scoped_ptr<cc::OutputSurface>(new CompositorOutputSurface(routing_id(),output_surface_id,context_provider,scoped_ptr<cc::SoftwareOutputDevice>(),use_swap_compositor_frame_message)); }? ? ? ?這個函數定義在文件external/chromium_org/content/renderer/render_widget.cc中。
? ? ? ?在WebView版的Chromium中，調用SynchronousCompositorFactory類的靜態成員函數GetInstance可以獲得一個SynchronousCompositorFactory對象，在這種情況下，調用獲得的SynchronousCompositorFactory對象的成員函數CreateOutputSurface創建一個繪圖表面。
? ? ? ?在非WebView版的Chromium中，SynchronousCompositorFactory類的靜態成員函數GetInstance的返回值為NULL，這時候RenderWidget類的成員函數CreateOutputSurface首先是檢查Chromium的命令行參數是否設置了switches::kDisableGpuCompositing選項。如果設置了，那么就需要使用軟件方式來渲染網頁，這時候本地變量use_software的值設置為true。否則的話，可能使用GPU來渲染網頁，取決于參數fallback的值。
? ? ? ?在使用GPU渲染的情況下，即本地變量use_software的值等于false的情況下，RenderWidget類的成員函數CreateOutputSurface首先調用另外一個成員函數CreateGraphicsContext3D創建圖1所示的一個WebGraphicsContext3DCommandBufferImpl對象。這個WebGraphicsContext3DCommandBufferImpl對象封裝了一個與GPU進程或者GPU線程通信的GPU通道。接下來這個WebGraphicsContext3DCommandBufferImpl對象又通過ContextProviderCommandBuffer類的靜態成員函數Create封裝在一個ContextProviderCommandBuffer對象中。最后這個ContextProviderCommandBuffer對象又被封裝在一個CompositorOutputSurface對象中，用來描述網頁的繪圖表面。以后我們分析網頁的渲染過程時，再詳細分析這些對象的作用?，F在，我們重點是要記住Render進程是通過WebGraphicsContext3DCommandBufferImpl類與GPU進程或者GPU線程建立GPU通道的。
? ? ? ?在使用軟件方式渲染的情況下，即本地變量use_software的值等于false的情況下，RenderWidget類的成員函數CreateOutputSurface首先創建一個軟件輸出設備對象，即一個SoftwareOutputDevice對象，接著再根據該SoftwareOutputDevice對象創建一個CompositorOutputSurface對象來描述網頁的繪圖表面。
? ? ? ?此外，如果前面不能成功創建一個ContextProviderCommandBuffer對象，這種情況是由于不能成功創建一個WebGraphicsContext3DCommandBufferImpl對象引發的，也就是不能成功創建一個到GPU進程或者GPU線程的GPU通道，那么也改為上述的軟件渲染方式。
? ? ? ?接下來我們假設Render進程通過GPU來渲染網頁，這時候最重要的事情就是調用RenderWidget類的成員函數CreateGraphicsContext3D創建一個到GPU進程或者GPU線程的通道，如下所示：
scoped_ptr<WebGraphicsContext3DCommandBufferImpl> RenderWidget::CreateGraphicsContext3D() {......CauseForGpuLaunch cause =CAUSE_FOR_GPU_LAUNCH_WEBGRAPHICSCONTEXT3DCOMMANDBUFFERIMPL_INITIALIZE;scoped_refptr<GpuChannelHost> gpu_channel_host(RenderThreadImpl::current()->EstablishGpuChannelSync(cause));blink::WebGraphicsContext3D::Attributes attributes;attributes.antialias = false;attributes.shareResources = true;attributes.noAutomaticFlushes = true;attributes.depth = false;attributes.stencil = false;......scoped_ptr<WebGraphicsContext3DCommandBufferImpl> context(new WebGraphicsContext3DCommandBufferImpl(surface_id(),GetURLForGraphicsContext3D(),gpu_channel_host.get(),attributes,lose_context_when_out_of_memory,limits,NULL));return context.Pass(); }? ? ? ?這個函數定義在文件external/chromium_org/content/renderer/render_widget.cc中。? ? ? ?RenderWidget類的成員函數CreateGraphicsContext3D首先是調用RenderThreadImpl類的靜態成員函數current獲得一個RenderThreadImpl對象。從前面Chromium的Render進程啟動過程分析一文可以知道，這個RenderThreadImpl對象是用來描述Render進程的主線程的，或者Browser進程中的Render線程的。
? ? ? ?RenderWidget類的成員函數CreateGraphicsContext3D接下來調用上面獲得的RenderThreadImpl對象的在成員函數EstablishGpuChannelSync創建一個GPU通道，并且將該GPU通道封裝在一個WebGraphicsContext3DCommandBufferImpl對象中。在創建這個WebGraphicsContext3DCommandBufferImpl對象的時候，通過一個WebGraphicsContext3D::Attributes對象描述它的屬性。其中，這個WebGraphicsContext3D::Attributes對象的成員變量shareResources的值被設置為true，表示以后通過前面創建的WebGraphicsContext3DCommandBufferImpl對象創建的OpenGL上下文是在OpenGL共享組中的。這一點我們在后面一個系列的文章中分析Chromium的GPU渲染機制時，才詳細分析。
? ? ? 接下來，我們繼續分析RenderThreadImpl類的在成員函數EstablishGpuChannelSync的實現，以便可以了解Render進程的GPU通道的創建過程，如下所示：
GpuChannelHost* RenderThreadImpl::EstablishGpuChannelSync(CauseForGpuLaunch cause_for_gpu_launch) {......// Ask the browser for the channel name.int client_id = 0;IPC::ChannelHandle channel_handle;gpu::GPUInfo gpu_info;if (!Send(new GpuHostMsg_EstablishGpuChannel(cause_for_gpu_launch,&client_id,&channel_handle,&gpu_info)) || #if defined(OS_POSIX)channel_handle.socket.fd == -1 || #endifchannel_handle.name.empty()) {// Otherwise cancel the connection.return NULL;}......// Cache some variables that are needed on the compositor thread for our// implementation of GpuChannelHostFactory.io_message_loop_proxy_ = ChildProcess::current()->io_message_loop_proxy();gpu_channel_ = GpuChannelHost::Create(this, gpu_info, channel_handle,ChildProcess::current()->GetShutDownEvent());return gpu_channel_.get(); }? ? ? ?這個函數定義在文件external/chromium_org/content$ vi renderer/render_thread_impl.cc中。? ? ? ?RenderThreadImpl類的成員函數EstablishGpuChannelSync通過向Browser進程發送一個類型為GpuHostMsg_EstablishGpuChannel的IPC消息請求創建一個到GPU進程或者GPU線程的GPU通道。注意，?類型為GpuHostMsg_EstablishGpuChannel的IPC消息是一個同步IPC消息，當從RenderThreadImpl類的成員函數Send返回的時候，本地變量channel_handle描述的一個ChannelHandle對象包含了要創建的GPU通道所使用的UNIX Socket的名稱和Client端文件描述符。關于同步IPC消息的發送過程，可以參考前面Chromium的IPC消息發送、接收和分發機制分析一文。
? ? ? 獲得了要創建的GPU通道所使用的UNIX Socket的名稱和Client端文件描述符之后，RenderThreadImpl類的成員函數EstablishGpuChannelSync就調用前面分析過的GpuChannelHost類的靜態成員函數Create創建一個Client端GPU通道。
? ? ? 在前面Chromium的Render進程啟動過程分析一文中提到，Browser進程在啟動Render進程之前，即在RenderProcessHostImpl類的成員函數Init中，會調用RenderProcessHostImpl類的成員的另外一個成員函數CreateMessageFilters注冊一系列的Filter，用來過濾從其它進程發送過來的IPC消息，如下所示：
void RenderProcessHostImpl::CreateMessageFilters() {......gpu_message_filter_ = new GpuMessageFilter(GetID(), widget_helper_.get());AddFilter(gpu_message_filter_);...... };? ? ? 這個函數定義在文件external/chromium_org/content/browser/renderer_host/render_process_host_impl.cc中。? ? ? 其中的一個Filter為GpuMessageFilter，它用來處理從Render進程發送過來的與GPU操作相關的IPC消息，如下所示：
bool GpuMessageFilter::OnMessageReceived(const IPC::Message& message) {bool handled = true;IPC_BEGIN_MESSAGE_MAP(GpuMessageFilter, message)IPC_MESSAGE_HANDLER_DELAY_REPLY(GpuHostMsg_EstablishGpuChannel,OnEstablishGpuChannel)......IPC_MESSAGE_UNHANDLED(handled = false)IPC_END_MESSAGE_MAP()return handled; }? ? ? 這個函數定義在文件external/chromium_org/content/browser/renderer_host/gpu_message_filter.cc中。? ? ? 從這里可以看到，從Render進程發送過來的類型為GpuHostMsg_EstablishGpuChannel的IPC消息由GpuMessageFilter類的成員函數OnEstablishGpuChannel處理，如下所示：
void GpuMessageFilter::OnEstablishGpuChannel(CauseForGpuLaunch cause_for_gpu_launch,IPC::Message* reply_ptr) {......scoped_ptr<IPC::Message> reply(reply_ptr);......GpuProcessHost* host = GpuProcessHost::FromID(gpu_process_id_);if (!host) {host = GpuProcessHost::Get(GpuProcessHost::GPU_PROCESS_KIND_SANDBOXED,cause_for_gpu_launch);......gpu_process_id_ = host->host_id();......}bool share_contexts = true;host->EstablishGpuChannel(render_process_id_,share_contexts,base::Bind(&GpuMessageFilter::EstablishChannelCallback,weak_ptr_factory_.GetWeakPtr(),base::Passed(&reply))); }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/renderer_host/gpu_message_filter.cc中。? ? ? ?與前面分析的Browser進程創建一個GPU通道的過程類似，Browser進程在收到Render進程發送過來的創建GPU通道的請求時，首先是調用GpuProcessHost類的靜態成員函數FromID檢查GPU進程是否已經啟動。如果還沒有啟動，即GpuProcessHost類的靜態成員函數FromID的返回值為NULL，那么就會調用GpuProcessHost類的靜態成員函數Get啟動一個類型為GpuProcessHost::GPU_PROCESS_KIND_SANDBOXED的GPU進程或者GPU線程，即一個運行在沙箱中的GPU進程或者GPU線程，并且將分配給該GPU進程或者GPU線程的ID保存在GpuMessageFilter類的成員變量gpu_process_id_中。
? ? ? ?一旦GPU進程啟動成功，或者GPU進程之前已經啟動過，那么GpuMessageFilter類的成員函數OnEstablishGpuChannel會獲得一個對應的GpuProcessHost對象，調用該GpuProcessHost對象的成員函數EstablishGpuChannel即可創建一個到GPU進程或者GPU線程的GPU通道。這一點前面已經分析過。
? ? ? ?在調用GpuProcessHost類的成員函數EstablishGpuChannel創建一個到GPU進程或者GPU線程的GPU通道的時候，指定的第二個參數share_contexts的值為true。根據前面的分析可以知道，在這種情況下，創建的GPU通道與其它GPU通道共享同一個OpenGL組。
? ? ? ?在調用GpuProcessHost類的成員函數EstablishGpuChannel創建一個到GPU進程或者GPU線程的GPU通道的時候，指定的第三個參數是一個綁定了GpuMessageFilter類的成員函數EstablishChannelCallback的Task。從前面的分析可以知道，當GPU進程成功創建了一個Server端GPU通道之后，就會將該Server端GPU通道使用的UNIX Socket的名稱和Client端文件描述符通過一個類型為GpuHostMsg_ChannelEstablished的IPC返回給Browser進程，這時候GpuMessageFilter類的成員函數EstablishChannelCallback就會被調用，如下所示：
void GpuMessageFilter::EstablishChannelCallback(scoped_ptr<IPC::Message> reply,const IPC::ChannelHandle& channel,const gpu::GPUInfo& gpu_info) {......GpuHostMsg_EstablishGpuChannel::WriteReplyParams(reply.get(), render_process_id_, channel, gpu_info);Send(reply.release()); }? ? ? ?這個函數定義在文件external/chromium_org/content/browser/renderer_host/gpu_message_filter.cc中。? ? ? ?GpuMessageFilter類的成員函數EstablishChannelCallback獲得的UNIX Socket的名稱和Client端文件描述符封裝在參數channel描述的一個ChannelHandle對象，這個ChannelHandle對象的內容最終會被寫入到參數reply描述的一個IPC消息中，該IPC消息最終會被發送給Render進程，作為前面Render進程發送的類型為GpuHostMsg_EstablishGpuChannel的IPC消息的回復，使得Render進程可以獲得上述的UNIX Socket的名稱和Client端文件描述符，從而創建一個Client端GPU通道。
? ? ? ?這樣，Render進程渲染網頁所要用到的GPU通道就創建完成了，以后Render進程就可以通過該GPU通道來渲染網頁了。
? ? ? ?接下來，我們再分析當網頁包含了一個canvas標簽時創建GPU通道的過程。當網頁包含了一個canvas標簽時，我們可以通過JS獲得一個3D繪圖接口，然后通過GPU來渲染canvas標簽的內容，如下所示：
? ? ? 這個函數定義在文件external/chromium_org/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp中。
? ? ? 當參數type的值等于“2d”的時候，表示要創建的是一個2D繪圖接口，這時候HTMLCanvasElement類的成員函數getContext返回一個CanvasRenderingContext2D對象來描述該2D繪圖接口，這是通過調用CanvasRenderingContext2D類的靜態成員函數create創建的。
? ? ? 當參數type的值等于"webgl"的時候，表示要創建的是一個3D繪圖接口，這時候HTMLCanvasElement類的成員函數getContext返回一個WebGLRenderingContext對象來描述該3D繪圖接口，這是通過調用WebGLRenderingContext類的靜態成員函數create創建的。
? ? ? 接下來我們就主要分析3D繪圖接口的創建過程，也就是WebGLRenderingContext類的靜態成員函數create的實現，如下所示：
PassOwnPtrWillBeRawPtr<WebGLRenderingContext> WebGLRenderingContext::create(HTMLCanvasElement* canvas, WebGLContextAttributes* attrs) {Document& document = canvas->document();LocalFrame* frame = document.frame();......Settings* settings = frame->settings();......blink::WebGraphicsContext3D::Attributes attributes = attrs->attributes(document.topDocument().url().string(), settings);OwnPtr<blink::WebGraphicsContext3D> context = adoptPtr(blink::Platform::current()->createOffscreenGraphicsContext3D(attributes, 0));......OwnPtrWillBeRawPtr<WebGLRenderingContext> renderingContext = adoptPtrWillBeNoop(new WebGLRenderingContext(canvas, context.release(), attrs));......return renderingContext.release(); }? ? ? ?這個函數定義在文件external/chromium_org/third_party/WebKit/Source/core/html/canvas/WebGLRenderingContext.cpp中。? ? ? ?blink::Platform類的靜態成員函數current返回的是一個RendererWebKitPlatformSupportImpl對象，這是一個描述平臺相關屬性的平臺，WebGLRenderingContext類的靜態成員函數create主要就是通過調用它的成員函數createOffscreenGraphicsContext3D為JS創建一個3D繪圖上下文，最后將它封裝在一個WebGLRenderingContext對象中返回給調用者。
? ? ? ?在Android平臺上，RendererWebKitPlatformSupportImpl類的成員函數createOffscreenGraphicsContext3D的實現如下所示：
blink::WebGraphicsContext3D* RendererWebKitPlatformSupportImpl::createOffscreenGraphicsContext3D(const blink::WebGraphicsContext3D::Attributes& attributes) {return createOffscreenGraphicsContext3D(attributes, NULL); }? ? ? 這個函數定義在文件external/chromium_org/content/renderer/renderer_webkitplatformsupport_impl.cc中。? ? ??RendererWebKitPlatformSupportImpl類的成員函數createOffscreenGraphicsContext3D調用另外一個重載版本的成員函數createOffscreenGraphicsContext3D來創建一個WebGraphicsContext3D對象，如下所示：
? ? ? ?RendererWebKitPlatformSupportImpl類的成員函數createOffscreenGraphicsContext3D與前面分析的RenderWidget類的成員函數CreateGraphicsContext3D的實現是差不多，它們都是首先通過調用RenderThreadImpl類的成員函數EstablishGpuChannelSync請求Browser進程創建一個到GPU進程或者GPU線程的GPU通道，接著再將該GPU通道封裝在一個WebGraphicsContext3DCommandBufferImpl對象中。
? ? ? ?不過，RendererWebKitPlatformSupportImpl類的成員函數createOffscreenGraphicsContext3D通過調用WebGraphicsContext3DCommandBufferImpl類的靜態成員函數CreateOffscreenContext來創建一個WebGraphicsContext3DCommandBufferImpl對象，如下所示：
WebGraphicsContext3DCommandBufferImpl* WebGraphicsContext3DCommandBufferImpl::CreateOffscreenContext(GpuChannelHost* host,const WebGraphicsContext3D::Attributes& attributes,bool lose_context_when_out_of_memory,const GURL& active_url,const SharedMemoryLimits& limits,WebGraphicsContext3DCommandBufferImpl* share_context) {......return new WebGraphicsContext3DCommandBufferImpl(0,active_url,host,attributes,lose_context_when_out_of_memory,limits,share_context); }? ? ? ?這個函數定義在文件external/chromium_org/content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc中。? ? ? ?WebGraphicsContext3DCommandBufferImpl類的靜態成員函數CreateOffscreenContext與RenderWidget類的成員函數CreateGraphicsContext3D的主要不同之處在于，前者
創建的WebGraphicsContext3DCommandBufferImpl對象關聯的Surface ID值為0，而后者創建的WebGraphicsContext3DCommandBufferImpl對象關聯的Surface ID值不為0。Surface ID描述的是一個OpenGL上下文所對應的繪圖表面的，這個繪圖表面綁定在一個EGLSurface中。在接下來一個系列的文章中分析Chromium的GPU渲染機制時，我們再詳細分析OpenGL上下文相關的概念。
? ? ? ?這樣，JS在使用3D繪圖接口時所要用到的GPU通道就創建完成了，以后JS就可以通過該GPU通道來繪制相對標簽的內容了。
? ? ? ?至此，我們就分析完成GPU進程或者GPU線程的啟動過程，以及Browser進程和Render進程與GPU進程或者GPU線程建立GPU通道的過程了。事實上，Plugin進程在需要使用3D繪圖接口的時候，也會像Render進程一樣，請求Browser進程為其創建一個到GPU進程或者GPU線程的GPU通道。在接下來的一篇文章中，我們就繼續分析Plugin進程的啟動過程，等下一個系列的文章分析完成Chromium的GPU渲染機制之后，我們再回過頭來分析Plugin進程創建到GPU進程或者GPU線程的GPU通道的過程，以及Plugin進程其于上述GPU通道使用GPU渲染UI的過程，敬請關注！更多的信息也可以關注老羅的新浪微博：http://weibo.com/shengyangluo。
總結
以上是生活随笔為你收集整理的Chromium的GPU进程启动过程分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 会声会影2023专业版视频处理制作软件功
- 下一篇： LeetCode-241. Differ