Add "sample locations" feature to GrProcessor

src/gpu/gl/GrGLGpu.cpp

Index: src/gpu/gl/GrGLGpu.cpp
diff --git a/src/gpu/gl/GrGLGpu.cpp b/src/gpu/gl/GrGLGpu.cpp
index 29841331c01d308d45b7c1948db0dfe54547a4a6..3688f8bf76f52ec575256220ab4fab7fb8ce9fee 100644
--- a/src/gpu/gl/GrGLGpu.cpp
+++ b/src/gpu/gl/GrGLGpu.cpp
@@ -4138,6 +4138,33 @@ bool GrGLGpu::copySurfaceAsBlitFramebuffer(GrSurface* dst,
     return true;
 }
 
+void GrGLGpu::onGetMultisampleSpecs(GrRenderTarget* rt,
+                                    const GrStencilSettings& stencil,
+                                    int* effectiveSampleCnt,
+                                    SamplePattern* pattern) {
+    SkASSERT(!rt->hasMixedSamples() || rt->renderTargetPriv().getStencilAttachment() ||
+             stencil.isDisabled());
+
+    this->flushStencil(stencil);
+    this->flushHWAAState(rt, true, !stencil.isDisabled());
+    this->flushRenderTarget(static_cast<GrGLRenderTarget*>(rt), &SkIRect::EmptyIRect());

[bsalomon, 2016/03/01 14:28:55]

Is this why we wind up caching this on the RT? Is there no way to query GL for
the effective sample count and locations given some info about the
renderbuffer/texture that we want to create (like its internal format and
requested sample count).

The dual caching on the RT and GPU objects is the part of this CL I find the
most confusing. I think I understand what's going on, but it seems unfortunately
convoluted. Also, unfortunate that we're going to make this same query for each
target even though I assume we'll get the same sample count/pattern for any
given format/sample count request.

Even if we can't query without first binding a render target are there any
invariants guaranteed by the spec? e.g. same sized internal format and same
requested sample count -> the same actual sample count and locations?

[Chris Dalton, 2016/03/01 20:37:47]

EXT_raster_multisample says: 

  "The sample locations chosen are a function of only the
   parameters to RasterSamplesEXT and not of any other state."

(https://developer.nvidia.com/sites/default/files/akamai/opengl/specs/GL_EXT_r...)

This is the reason why raster multisample state is getting cached on the GPU. 

But unfortunately, the spec for glGetMultisamplefv is very poorly written and
gives no indication of what state may affect sample locations.

(https://www.khronos.org/registry/gles/specs/3.1/es_spec_3.1.pdf p. 294)

Come to think of it, caching sample locations on the render target is just
speculatively guessing what state may affect sample locations, but still
assuming other state will not (e.g. blend state, depth test, scissor, phase of
the moon...)

I can guarantee that on NVIDIA, sample count is the only state that will affect
the sample pattern. And I think this is all but implied by the fact that it's
valid to swap a stencil buffer to any other render target as long as the sample
counts match. (e.g. how could it make any sense to swap stencil buffers around
if the sample locations didn't match?
https://www.khronos.org/opengles/sdk/docs/man3/html/glCheckFramebufferStatus....)

How about this: why don't we just cache sample patters on the GPU based on
sample count and origin? Then in debug mode we can call getMultisamplefv every
time and verify the cached sample pattern is correct.

+
+    if (0 != this->caps()->maxRasterSamples()) {
+        GR_GL_GetIntegerv(this->glInterface(), GR_GL_EFFECTIVE_RASTER_SAMPLES, effectiveSampleCnt);
+    } else {
+        GR_GL_GetIntegerv(this->glInterface(), GR_GL_SAMPLES, effectiveSampleCnt);
+    }
+    if (this->caps()->sampleLocationsSupport()) {
+        pattern->reset(*effectiveSampleCnt);
+        for (int i = 0; i < *effectiveSampleCnt; ++i) {
+            GrGLfloat pos[2];
+            GL_CALL(GetMultisamplefv(GR_GL_SAMPLE_POSITION, i, pos));
+            // OpenGL window space and Skia device space have inverted y directions.
+            (*pattern)[i].set(pos[0], 1 - pos[1]);

[bsalomon, 2016/03/01 14:28:55]

Skia conceptually places the origin at the top of its canvas but we can render
either upside-down or right-side up from OpenGL's point of view. E.g. when we
render into the default framebuffer we don't want to render upside down so the
client will specify that the origin is kBottomLeft_GrSurfaceOrigin and we will
flip in the vertex shader. You can see how this works in 
GrGLSLFragmentShaderBuilder::fragmentPosition() we may or may not have to flip
gl_FragCoord. Seems like that surface origin property is is relevant here.

[Chris Dalton, 2016/03/01 20:37:47]

Ah, good point. Device space is a Skia concept, so this should follow the Skia
conventions.

It looks like GrGLIRect::setRelativeTo also gives a good definition of how to
convert between window space and device space. I'll model that.

[Chris Dalton, 2016/03/07 16:09:38]

Done.

+        }
+    }
+}
+
 void GrGLGpu::xferBarrier(GrRenderTarget* rt, GrXferBarrierType type) {
     SkASSERT(type);
     switch (type) {