Leave ShaderMode part of GrGLShaderBuilder, but use it less

OK, smaller change: leave ShaderMode out there so ColorTable can hardwire it, but don't use it in GrGLProgram.

[twiz1, 2012-08-02 19:48:23]

On 2012/08/02 19:41:09, TomH wrote:

Is this change preferred over codereview.appspot.com/6458067, because some
custom effects may want to do projective texturing?  

If an effect wants to use projective texturing, they need the enum, unless we
are going to force them to manage their own projective divide.

[TomH, 2012-08-02 19:53:35]

On 2012/08/02 19:48:23, twiz1 wrote:
> Is this change preferred over codereview.appspot.com/6458067, because some
> custom effects may want to do projective texturing?  
> 
> If an effect wants to use projective texturing, they need the enum, unless we
> are going to force them to manage their own projective divide.

Yes, that's why I closed the other CL and submitted this.
But Brian thinks we want to force them to manage a lot of this stuff.

[bsalomon, 2012-08-02 19:54:05]

On 2012/08/02 19:48:23, twiz1 wrote:
> On 2012/08/02 19:41:09, TomH wrote:
> 
> Is this change preferred over codereview.appspot.com/6458067, because some
> custom effects may want to do projective texturing?  
> 
> If an effect wants to use projective texturing, they need the enum, unless we
> are going to force them to manage their own projective divide.

Right, that change was abandoned because we will continue to need the enum. What
we are working towards is having the default fetch go through your new function
and to always have a GrTextureAccess for every texture. In the existing world
(mess) the SampleMode for the default fetch users is already implied by the
varying dims, making the sample mode passed to setupTextureAccess redundant.

This LGTM.

[TomH, 2012-08-02 20:20:27]

Committed in r4940.