Add the SH_CSS_SHADERS_SPEC flag.

Add the SH_CSS_SHADERS_SPEC flag.

The only change to the ANGLE API is the new SH_CSS_SHADERS_SPEC flag.

Background:
This patch implements the shader validation and rewriting that is required for CSS Shaders on the ANGLE end. 

Basically, CSS Shaders will not allow direct access to the DOM element texture in order to prevent timing attacks. Instead, the result of a CSS fragment shader will be blended and composited with the DOM element texture. The browser will insert shader code that does this blending and compositing operation. CSS Shaders needs ANGLE to prepare the shader for code insertion by the browser.

The comment above the SH_CSS_SHADERS_SPEC flag in ShaderLang.h gives you the details:

  // The CSS Shaders spec is a subset of the WebGL spec.
  //
  // In both CSS vertex and fragment shaders, ANGLE reserves the "css_" prefix
  // and renames the main function to css_main.
  //
  // In CSS fragment shaders, ANGLE disables the gl_FragColor built-in and
  // enables the css_MixColor and css_ColorMatrix built-ins.
  //
  // After passing a CSS shader through ANGLE, the browser is expected to append
  // a new main function to it.
  // This new main function will call the css_main function.
  // It may also perform additional operations like varying assignment, texture
  // access, and gl_FragColor assignment in order to implement the CSS Shaders
  // blend modes.
  //

I'm working closely with one of the CSS Shaders spec editors, Vincent Hardy. He is in the process of updating the CSS Shaders spec to reflect this implementation.

BUG=NONE
TEST=Run the translator with "-s=c" on a shader to use the SH_CSS_SHADERS_SPEC flag.

[mvujovic, 2012-06-07 16:42:37]

Nicolas, Ken, or Daniel,

Could you take a look at this when you have a chance? We need it to enable CSS
Shaders in WebKit.

Thanks,
Max

[kbr1, 2012-06-07 20:50:29]

This looks good to me but Nicolas should sign off on it. One comment.

https://codereview.appspot.com/6270050/diff/2001/src/compiler/Initialize.cpp
File src/compiler/Initialize.cpp (right):

https://codereview.appspot.com/6270050/diff/2001/src/compiler/Initialize.cpp#...
src/compiler/Initialize.cpp:539: symbolTable.insert(*new
TVariable(NewPoolTString("css_ColorMatrix"),            TType(EbtFloat, EbpHigh,
EvqGlobal,      4, true)));
Are you sure you want to use high precision for these? It might prevent the code
from running on some OpenGL ES 2.0 devices.

[nicolas, 2012-06-07 21:16:55]

If I understand correctly, for CSS shaders to work you need to bind a texture to
blend into but this particular texture should not be accessible to user code,
just the browser, right? Hence there are no limitations on vertex textures?

In that case it all looks good to me.

[mvujovic, 2012-06-07 22:29:46]

On 2012/06/07 20:50:29, kbr1 wrote:
> This looks good to me but Nicolas should sign off on it. One comment.
> 
> https://codereview.appspot.com/6270050/diff/2001/src/compiler/Initialize.cpp
> File src/compiler/Initialize.cpp (right):
> 
>
https://codereview.appspot.com/6270050/diff/2001/src/compiler/Initialize.cpp#...
> src/compiler/Initialize.cpp:539: symbolTable.insert(*new
> TVariable(NewPoolTString("css_ColorMatrix"),            TType(EbtFloat,
EbpHigh,
> EvqGlobal,      4, true)));
> Are you sure you want to use high precision for these? It might prevent the
code
> from running on some OpenGL ES 2.0 devices.

Good catch! I didn't know highp required an extension. I'll change it to mediump
like the other built-ins.

[mvujovic, 2012-06-07 22:48:28]

On 2012/06/07 21:16:55, nicolas wrote:
> If I understand correctly, for CSS shaders to work you need to bind a texture
to
> blend into but this particular texture should not be accessible to user code,
> just the browser, right? 

Yes, exactly. The browser will add the texture uniform declaration and blending
code at the end of the fragment shader. This texture uniform won't be accessible
to the user code because it's (1) behind the "css_" prefix and (2) defined after
all of the user code.

> Hence there are no limitations on vertex textures?

We have the same restrictions on textures in both the vertex shader and the
fragment shader. The texture uniform containing the image of the DOM element
won't be accessible to user code in either shader. Other user-defined textures
will be subject to CORS, like WebGL. 

Does that make sense?

> In that case it all looks good to me.

Great. Thanks!

[dgkoch, 2012-06-08 00:35:41]

LGTM  

Just one question, but it's probably more about the CSS spec than anything else.

https://codereview.appspot.com/6270050/diff/2001/src/compiler/Initialize.cpp
File src/compiler/Initialize.cpp (right):

https://codereview.appspot.com/6270050/diff/2001/src/compiler/Initialize.cpp#...
src/compiler/Initialize.cpp:531: symbolTable.insert(*new
TVariable(NewPoolTString("gl_FragData[gl_MaxDrawBuffers]"), TType(EbtFloat,
EbpMedium, EvqFragData,    4)));
Shouldn't CSS shaders remove gl_FragData as well?

[mvujovic, 2012-06-08 16:40:55]

On 2012/06/08 00:35:41, dgkoch wrote:
> LGTM 
>
> Just one question, but it's probably more about the CSS spec than anything
else.
> https://codereview.appspot.com/6270050/diff/2001/src/compiler/Initialize.cpp
> File src/compiler/Initialize.cpp (right):
>
>
https://codereview.appspot.com/6270050/diff/2001/src/compiler/Initialize.cpp#...
> src/compiler/Initialize.cpp:531: symbolTable.insert(*new
> TVariable(NewPoolTString("gl_FragData[gl_MaxDrawBuffers]"), TType(EbtFloat,
> EbpMedium, EvqFragData,    4)));
> Shouldn't CSS shaders remove gl_FragData as well?

Yes, you're absolutely right. I've posted an updated patch that disables
gl_FragData and gl_MaxDrawBuffers with CSS Shaders.

Do the new changes in Initialize.cpp look ok?

[dgkoch, 2012-06-08 17:32:28]

Yeah the changes look fine to me.

[mvujovic, 2012-06-08 17:49:10]

On 2012/06/08 17:32:28, dgkoch wrote:
> Yeah the changes look fine to me.

Great, thanks Daniel. Committed in r1145.