Add functions to support NV_path_rendering in OpenGL ES

Add functions to support NV_path_rendering in OpenGL ES

Add OpenGL ES extension functions needed to support NV_path_rendering in OpenGL
ES.

The added glProgramPathFragmentInputGenNV call is defined in NV_path_rendering
revision 30, similar to following:

    Append to the end of the "Shader Inputs" subsection of Section 3.12.2
    "Shader Execution":

    The command

        void ProgramPathFragmentInputGenNV(uint program,
                                           int location,
                                           enum genMode,
                                           int components,
                                           const float *coeffs);

    controls how a user-defined (non-built-in) fragment input of a
    GLSL program object is computed for fragment shading operations that
    occur as a result of CoverFillPathNV or CoverStrokePathNV.

    /program/ names a GLSL program object.  If /program/ has not been
    successfully linked, the error INVALID_OPERATION is generated.

    The given fragment input generation state is loaded into the fragment
    input variable location identified by /location/.  This location
    is a value returned either by GetProgramResourceLocation with a
    /programInterface/ of FRAGMENT_INPUT_NV and a given fragment shader
    input variable name or by GetProgramResourceiv with FRAGMENT_INPUT_NV
    for the /programInterface/ and LOCATION for the property for a given
    fragment input resource index.

    ....

glProgramPathFragmentInputGenNV will be used instead of glPathTexGen,
because the latter depends on fixed function pipeline that is not
exposed in ES.

Also add glGetProgramResourceLocation from OpenGL 4.3 or
ARB_program_interface_query.

Also add FRAGMENT_INPUT define to be used with glGetProgramResourceLocation.

The added functions are not used yet, but they're needed when implementing
NV_path_rendering support for OpenGL ES. They can also be used on OpenGL.

Remove uncalled NV_path_rendering functions, so they do not cause confusion
or take space in the interface definition. The ones that are later used
can be re-added when needed.

Remove definitions NV_path_rendering that are for NV_path_rendering function
parameters that are not used. The ones that are later used
can be re-added when needed.

Committed: https://skia.googlesource.com/skia/+/4a995dfff2ecf91e8bf999d77e3218cec596232c

Committed: https://skia.googlesource.com/skia/+/32b9a3b02ed6b8bab4a25b6cb8853f5bea4b87ba

[Kimmo Kinnunen, 2014-06-19 07:08:19]

PTAL?
Depends on the 'es on desktop' patch.

[bsalomon, 2014-06-19 13:10:37]

lgtm, will land after the other patch lands.

[Kimmo Kinnunen, 2014-06-23 06:15:59]

The CQ bit was checked by kkinnunen@nvidia.com

[commit-bot: I haz the power, 2014-06-23 06:16:52]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/kkinnunen@nvidia.com/345723002/60001

[commit-bot: I haz the power, 2014-06-23 06:32:36]

Change committed as 4a995dfff2ecf91e8bf999d77e3218cec596232c

[rmistry, 2014-06-23 13:06:07]

A revert of this CL has been created in
https://codereview.chromium.org/349983002/ by rmistry@google.com.

The reason for reverting is: Will have to unfortunately revert this CL in order
to revert https://codereview.chromium.org/319043005/.

[Kimmo Kinnunen, 2014-07-02 11:14:20]

Had to change this slightly after LGTM.

Defining sensible EXT_direct_state_access for ES seems to take a long time. We
might want to just assume the matrix functions are present if NV_path_rendering
is present..

Also the GLCaps enabling the path rendering changed a bit.

[bsalomon, 2014-07-02 13:25:33]

lgtm

https://codereview.chromium.org/345723002/diff/120001/src/gpu/gl/GrGLCaps.cpp
File src/gpu/gl/GrGLCaps.cpp (right):

https://codereview.chromium.org/345723002/diff/120001/src/gpu/gl/GrGLCaps.cpp...
src/gpu/gl/GrGLCaps.cpp:324: NULL !=
gli->fFunctions.fProgramPathFragmentInputGen));
Can you explain in a comment why you're looking for presence of a specific
function here? I'm guessing that it is to distinguish between newer and older
versions of the NV_PR extension. Otherwise, this lgtm.

[Kimmo Kinnunen, 2014-07-03 05:43:20]

Thanks for the review.

https://codereview.chromium.org/345723002/diff/120001/src/gpu/gl/GrGLCaps.cpp
File src/gpu/gl/GrGLCaps.cpp (right):

https://codereview.chromium.org/345723002/diff/120001/src/gpu/gl/GrGLCaps.cpp...
src/gpu/gl/GrGLCaps.cpp:324: NULL !=
gli->fFunctions.fProgramPathFragmentInputGen));
On 2014/07/02 13:25:33, bsalomon wrote:
> Can you explain in a comment why you're looking for presence of a specific
> function here? I'm guessing that it is to distinguish between newer and older
> versions of the NV_PR extension. Otherwise, this lgtm.

Added following:
// We need one of the two possible texturing methods: using fixed function
pipeline
// (PathTexGen, texcoords, ...)  or using the newer NVPR API additions that
support
// setting individual fragment inputs with ProgramPathFragmentInputGen. The API
// additions are detected by checking the existence of the function. Eventually
we may
// choose to remove the fixed function codepath.

[Kimmo Kinnunen, 2014-07-03 05:43:42]

The CQ bit was checked by kkinnunen@nvidia.com

[commit-bot: I haz the power, 2014-07-03 05:44:19]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/kkinnunen@nvidia.com/345723002/140001

[commit-bot: I haz the power, 2014-07-03 05:56:44]

Change committed as 32b9a3b02ed6b8bab4a25b6cb8853f5bea4b87ba

[Kimmo Kinnunen, 2014-07-03 11:39:23]

For some reason, caused Test-Win7-ShuttleA-HD2000-x86-Release-ANGLE to fail. 
http://108.170.220.120:10117/builders/Test-Win7-ShuttleA-HD2000-x86-Release-A...

Can't repro on NV HW. I'm in process of getting some non-NV hw to test with..

[Kimmo Kinnunen, 2014-07-03 11:59:11]

Mike, this broke the Test-Win7-ShuttleA-HD2000-x86-Release-ANGLE .. It probably
takes me a while to get the HW, so in the mean time, if the bot/test is known to
be stable, the commit could be reverted..