| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement support for NV_path_rendering on OpenGL ES. Use
glProgramPathFragmentInputGenNV function call instead of glPathTexGenNV to
communicate transforms to fragment shader.
The intention is that the NVPR paths will be drawn with the same shader program
as non-NVPR geometry. For NVPR calls, the GPU will skip the vertex shader and
just run the fragment shader.
After program is linked, query the locations of the fragment shader inputs with
glGetResourceLocation. The location will be used to set the transforms with
glProgramPathFragmentInputGenNV.
The functions and their workings are documented in:
glProgramPathFragmentInputGenNV
https://www.opengl.org/registry/specs/NV/path_rendering.txt
(note: addition as of API version 1.3)
glGetResourceLocation
https://www.opengl.org/registry/specs/ARB/program_interface_query.txt
http://www.opengl.org/registry/doc/glspec44.core.pdf
(function is in core Open GL 4.4)
Note: glProgramPathFragmentInputGenNV could be used also for OpenGL. However,
using seems to trigger a bug in the driver. Disable this feature on OpenGL at
least until the driver is fixed and released. The bug manifests in shadertext
test, where the lower-left text pair is missing. Valgrind catches a bad read
for the test and causes the context to OOM reproducibly.
R=bsalomon@google.com, cdalton@nvidia.com, joshualitt@google.com, joshualitt@chromium.org
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/367643004
|
| |
|
|
|
|
|
|
|
|
|
| |
gitignore for eclipse
BUG=skia:
R=bsalomon@google.com, bsalomon@chromium.org
Author: joshualitt@chromium.org
Review URL: https://codereview.chromium.org/491673002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GL APIs such as glProgramPathFragmentInputGenNV need the explicit program id in
order to set the program resources. For GrGLProgramDataManager to call the APIs,
the program id needs to be available to the GrGLProgramDataManager.
One GrGLProgramDataManager is used to explicitly manage the resources of one
GrGLProgram. Refactor the classes to reflect this: make GrGLProgram create and
own GrGLProgramDataManager. This way the program id can be made available through
GrGLProgram backpointer.
In order to do this, remove the population of the program link results
information for uniforms in GrGLProgramDataManager during shader generation.
Instead, accumulate the info to the uniform list of GrGLShaderBuilder. After the
generation, compilation and link is successful, this info can be used to
construct both GrGLProgram and GrGLProgramDataManager.
Changes names of functions to create UniformHandles and convert them to list
indices. This tries to highlight that they're different lists, even though at
the moment they match index-wise. E.g the contract is that handles can be
created based on the shader builder state, and the object can later be set with
the handle and the manager that was created with the builder.
This is needed to support NV_path_rendering for GLES.
R=bsalomon@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/426553011
|
|
|
Rename GrGLUniformManager to GrGLProgramDataManager in anticipation that the
class would be used to manage shader resources that are not uniforms.
This is needed in order to implement NVPR on GLES.
R=bsalomon@google.com
Author: kkinnunen@nvidia.com
Review URL: https://codereview.chromium.org/365853002
|
kkinnunen
joshualitt