Use glDiscardFramebuffer to save memory bandwidth in PNaCl

gpu/command_buffer/service/gles2_cmd_decoder.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "gpu/command_buffer/service/gles2_cmd_decoder.h"
 
 #include <stdio.h>
 
 #include <algorithm>
 #include <list>
@@ skipping 9351 matching lines @@
             offscreen_saved_color_format_);
       } else {
         // Flip the textures in the parent context via the texture manager.
         if (!!offscreen_saved_color_texture_info_.get())
           offscreen_saved_color_texture_info_->texture()->
               SetServiceId(offscreen_target_color_texture_->id());
 
         offscreen_saved_color_texture_.swap(offscreen_target_color_texture_);
         offscreen_target_frame_buffer_->AttachRenderTexture(
             offscreen_target_color_texture_.get());
+
+        // Explicitly discard framebuffer to save GPU memory bandwidth for
+        // tile-based GPU arch.
+        if (feature_info_->feature_flags().ext_discard_framebuffer) {

[Hongbo Min, 2014/10/14 02:27:48]

According to my previous work, an attempt to clear a framebuffer on  tiled GPU
is time-consuming, if glDiscardFramebuffer is used, it gives a performance hint
and allow GPU driver to set the pixel vale to whatever it wishes, and the
glClear could be skipped (I have verified it on ASUS Nexus series, it works well
without glClear if glDiscardFramebuffer is used).

So my question is, where is glClear called to clear
|offscreen_target_frame_buffer_| and prepare a new frame? and can we skip that
glClear if have?

[dshwang, 2014/10/14 12:09:30]

As far as I understand, your CL didn't affect whether glClear is skipped or not.
WebGLRenderingContextBase::clearIfComposited still do glClear every frame.

Let me explain why your CL speed up in tiled-based GPU as I understand. When
binding another fbo, tiled-based GPU must stores tiled cache to gpu memory
(texture, stencil buffer and depth buffer). glDiscardFramebuffer hints GPU to
not read back tiled cache to gpu memory because the software don't need anymore
the changed fbo information. It saves huge gpu bandwidth.

Let's go back to your CL. The fbo lifecycle is as follows:
1. WebGL replaces color texture to front fbo. At that time, you hint
glDiscardFramebuffer because DrawingBuffer doesn't update fbo so you don't want
to copy tiled cache to color texture redundantly. It wastes bandwidth.
2. Something later, WebGLRenderingContextBase::clearIfComposited performs
glClear on the fbo.

My CL is the same to your WebGL CL. This code just bind fbo and replace color
texture, so we don't want to copy back tiled cache to color texture redundantly.
glDiscardFramebuffer can make it.
As I explain above, glClear is not related to glDiscardFramebuffer.

+          const GLenum attachments[3] = {
+              GL_COLOR_ATTACHMENT0, GL_DEPTH_ATTACHMENT, GL_STENCIL_ATTACHMENT};
+          glDiscardFramebufferEXT(GL_FRAMEBUFFER, 3, attachments);
+        }
       }
 
       // Ensure the side effects of the copy are visible to the parent
       // context. There is no need to do this for ANGLE because it uses a
       // single D3D device for all contexts.
       if (!feature_info_->feature_flags().is_angle)
         glFlush();
     }
   } else {
     if (!surface_->SwapBuffers()) {
@@ skipping 1763 matching lines @@
   }
 }
 
 // Include the auto-generated part of this file. We split this because it means
 // we can easily edit the non-auto generated parts right here in this file
 // instead of having to edit some template or the code generator.
 #include "gpu/command_buffer/service/gles2_cmd_decoder_autogen.h"
 
 }  // namespace gles2
 }  // namespace gpu