Add "sample locations" feature to GrProcessor

include/gpu/GrRenderTarget.h

 /*
  * Copyright 2011 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #ifndef GrRenderTarget_DEFINED
 #define GrRenderTarget_DEFINED
 
@@ skipping 175 matching lines @@
     SkIRect               fResolveRect;
 
     // The last drawTarget that wrote to or is currently going to write to this renderTarget
     // The drawTarget can be closed (e.g., no draw context is currently bound
     // to this renderTarget).
     // This back-pointer is required so that we can add a dependancy between
     // the drawTarget used to create the current contents of this renderTarget
     // and the drawTarget of a destination renderTarget to which this one is being drawn.
     GrDrawTarget* fLastDrawTarget;
 
+    /**
+     * Info struct filled out by GrGpu that contains hardware-specific multisample info.
+     */
+    struct MultisampleSpecs {
+        MultisampleSpecs() { memset(this, 0, sizeof(*this)); }
+        /**
+         * The actual number of samples allocated for the render target. NOTE: this value can be
+         * greater than the surface descriptor's sample count.

[bsalomon, 2016/02/22 20:28:25]

How does that happen? Is it referring to the fact that the desc's sample count
request gets rounded up to a value supported by the GL impl?

[Chris Dalton, 2016/02/22 21:19:11]

Yeah, it's in 4.4.2 of the 3.0 spec:

 If samples is zero, then RENDERBUFFER_SAMPLES is set to zero. Otherwise
 samples represents a request for a desired minimum number of samples. Since
 different implementations may support different sample counts for multisample
 rendering, the actual number of samples allocated for the renderbuffer image is
 implementation-dependent. However, the resulting value for RENDERBUFFER_-
 SAMPLES is guaranteed to be greater than or equal to samples and no more than
 the next larger sample count supported by the implementation.

This isn't something we can always determine at creation time either:
- Mixed sampled render target won't have a stencil attachment yet.
- EXT_raster_multisample allows for the sample pattern to be different, and
never specifies whether the implementation-dependent sample count has to match
(though I can't imagine it ever not matching.)

+         */
+        int             fEffectiveSampleCnt;
+        /**
+         * If sample locations are supported, contains a unique ID that identifies the render
+         * target's sample pattern. Otherwise 0.
+         */
+        uint16_t        fSamplePatternID;
+        /**
+         * If supported, references the render target's sample locations. Otherwise nullptr. The
+         * locations are stored as offsets in device space from the center of the pixel.
+         */
+        const SkPoint*  fSampleLocations;
+    };
+
+    SkAutoTDelete<MultisampleSpecs> fMultisampleSpecs;
+
     typedef GrSurface INHERITED;
 };
 
 
 #endif