command_buffer: Implement CHROMIUM_framebuffer_mixed_samples extension

gpu/GLES2/extensions/CHROMIUM/CHROMIUM_framebuffer_mixed_samples.txt

Index: gpu/GLES2/extensions/CHROMIUM/CHROMIUM_framebuffer_mixed_samples.txt
diff --git a/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_framebuffer_mixed_samples.txt b/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_framebuffer_mixed_samples.txt
new file mode 100644
index 0000000000000000000000000000000000000000..df65d8f81652eb40817d24bcb6cbcae8256ad0fd
--- /dev/null
+++ b/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_framebuffer_mixed_samples.txt
@@ -0,0 +1,147 @@
+Name
+
+    CHROMIUM_framebuffer_mixed_samples
+
+Name Strings
+
+    GL_CHROMIUM_framebuffer_mixed_samples
+
+Version
+
+    Last Modifed Date: 7. December, 2015
+
+Dependencies
+
+    OpenGL ES 2.0 is required.
+
+    This extension interacts with CHROMIUM_framebuffer_multisample.
+
+Overview
+
+    This extension allows multisample rendering with a raster and
+    depth/stencil sample count that is larger than the color sample count.
+    Rasterization and the results of the depth and stencil tests together
+    determine the portion of a pixel that is "covered".  It can be useful to
+    evaluate coverage at a higher frequency than color samples are stored.
+    This coverage is then "reduced" to a collection of covered color samples,
+    each having an opacity value corresponding to the fraction of the color
+    sample covered.  The opacity can optionally be blended into individual
+    color samples.
+
+  The key features of this extension are:
+
+    - It allows a framebuffer object to be considered complete when its depth
+      or stencil samples are a multiple of the number of color samples.

[Zhenyao Mo, 2015/12/16 01:48:58]

Should this change the DoCheckFramebufferStatue()? I don't think we check for
sample matching right now, but we definitely will add it for ES3.

[Kimmo Kinnunen, 2015/12/17 13:47:23]

I don't know? I didn't add relaxation of the error checking, since the checks
did not exist in the first place.

The problem with me adding the error checking is that the errors are defined in
either ES3 or CHROMIUM_framebuffer_multisample. The former is not implemented
and the latter is not specified. So I'd need to either use ES3 as the spec or
first specify CHROMIUM_framebuffer_multisample.

I think me adding ES3 checks while not actually implementing ES3, and not being
in sync with the primary ES3 implementors is quite problematic.

I think specifying CHROMIUM_framebuffer_multisample is a huge task.

[Zhenyao Mo, 2015/12/17 21:25:38]

I'll ask around why CHROMIUM_framebuffer_multisample isn't specified.  I don't
expect it to be a huge task, because we already have
ANGLE_framebuffer_multisample specified and we can just copy from that.

As for the CheckFramebufferStatus(), I do think we need to handle it and take
into consideration this extension.  But this CL can land as is.

+
+    - It redefines SAMPLES to be the number of depth/stencil samples (if any);
+      otherwise, it uses the number of color samples. SAMPLE_BUFFERS is one if
+      there are multisample depth/stencil attachments.  Multisample
+      rasterization and multisample fragment ops are allowed if SAMPLE_BUFFERS
+      is one.
+
+    - It replaces several error checks involving SAMPLE_BUFFERS by error
+      checks directly referencing the number of samples in the relevant
+      attachments.

[Zhenyao Mo, 2015/12/16 01:48:58]

Should the above two features be implemented in the command buffer?

[Kimmo Kinnunen, 2015/12/17 13:47:23]

Do you mean, currently or my opinion about ideal world / entirely finished
command buffer implementation?

If I understand correctly, current command buffer relies on the underlying
driver for all sorts of checks related to multisampling state.

For this patch, it continues to rely on the underlying driver.

[Zhenyao Mo, 2015/12/17 21:25:38]

My concern is it really depends on command buffer implementation, because we
don't have to go to the driver to query these values.  We could return based on
the data in command buffer.  Again, this CL can land as is.  We just need to
create a bug to log these behaviors and make sure we handle it later.

+
+    - A coverage reduction step is added to Per-Fragment Operations which
+      converts a set of covered raster/depth/stencil samples to a set of
+      covered color samples.  The coverage reduction step also includes an
+      optional coverage modulation step, multiplying color values by a
+      fractional opacity corresponding to the number of associated
+      raster/depth/stencil samples covered.
+
+New Procedures and Functions
+
+    void CoverageModulationCHROMIUM(enum components);
+
+New Tokens
+
+    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv and
+    GetFloatv:
+
+    COVERAGE_MODULATION_CHROMIUM                          0x9332
+
+
+Additions to specification text related to framebuffers and framebuffer objects
+(Framebuffers and Framebuffer Objects)
+
+    Pending CHROMIUM_framebuffer_multisample specification.
+    Apply relevant rules in spirit of the overview to the specification text.
+
+
+
+Additions to Chapter 3 of OpenGL ES 2.0 Specification (Rasterization)
+
+
+    Modify Section 3.2 (Multisampling)
+
+    Pending CHROMIUM_framebuffer_multisample specification.
+    Apply relevant rules in spirit of the overview to the specification text.
+
+Additions to Chapter 4 of OpenGL ES 2.0 Specification
+(Per-Fragment Operations and the Framebuffer)
+
+     Modify Figure 4.1 (Per-fragment operations)
+
+    Add a new stage called "Coverage Reduction" between "Dept Buffer Test" and
+    "Blending".
+
+    Add a new Section 4.1.Y (Coverage Reduction) after 4.1.5.
+
+    If the value of effective raster samples is greater than the value of
+    color samples, a fragment's coverage is reduced from
+    effective raster samples bits to color samples bits. There is an
+    implementation-dependent association of raster samples to color samples.
+    The reduced "color coverage" is computed such that the coverage bit for
+    each color sample is 1 if any of the associated bits in the fragment's
+    coverage is on, and 0 otherwise.  Blending and writes to the framebuffer
+    are not performed on samples whose color coverage bit is zero.
+
+    For each color sample, the associated bits of the fragment's coverage are
+    counted and divided by the number of associated bits to produce a
+    modulation factor R in the range (0,1] (a value of zero would have been
+    killed due to a color coverage of 0). Specifically:
+
+        N = value of effective raster samples;
+        M = value of color samples;
+        R = popcount(associated coverage bits) / (N / M);
+
+    For each draw buffer with a floating point or normalized color format, the
+    fragment's color value is replicated to M values which may each be
+    modulated (multiplied) by that color sample's associated value of R. This
+    modulation is controlled by the function:
+
+        CoverageModulationCHROMIUM(enum components);
+
+    <components> may be RGB, RGBA, ALPHA, or NONE. If <components> is RGB or
+    RGBA, the red, green, and blue components are modulated. If components is
+    RGBA or ALPHA, the alpha component is modulated. The initial value of
+    COVERAGE_MODULATION_CHROMIUM is NONE.
+
+New State
+
+    Get Value                       Get Command    Type    Initial Value    Description                 Sec.    Attribute
+    ---------                       -----------    ----    -------------    -----------                 ----    ---------
+
+    COVERAGE_MODULATION_CHROMIUM    GetIntegerv    E       NONE             Which components are        4.1.Y  -
+                                                                            multiplied by coverage
+                                                                            fraction
+Issues
+
+    (1) How is coverage modulation intended to be used?
+
+    RESOLVED: Coverage modulation allows the coverage to be converted to
+    "opacity", which can then be blended into the color buffer to accomplish
+    antialiasing. This is similar to the intent of POLYGON_SMOOTH. For example,
+    if non-premultiplied alpha colors are in use (common OpenGL usage):
+
+        glCoverageModulationCHROMIUM(GL_ALPHA);
+        glEnable(GL_BLEND);
+        glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
+                            GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
+
+    or if using pre-multiplied alpha colors (common in 2D rendering):
+
+        glCoverageModulationCHROMIUM(GL_RGBA);
+        glEnable(GL_BLEND);
+        glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);