xref: /aosp_15_r20/external/angle/doc/Update20120704.md (revision 8975f5c5ed3d1c378011245431ada316dfb6f244)

# ANGLE Development Update - July 4, 2012

We haven't posted an update on the development status of ANGLE in quite some
time and we'd like to provide an update on some of the new features and
improvements that we've been working on.

## Conformance

As announced in the [Chromium Blog]
(http://blog.chromium.org/2011/11/opengl-es-20-certification-for-angle.html),
ANGLE v1.0 has passed the Khronos OpenGL ES 2.0 certification process and is now
a [conformant](http://www.khronos.org/conformance/adopters/conformant-products/)
OpenGL ES 2.0 implementation.

## Extensions

We have recently completed the implementation of depth texture support
([ANGLE\_depth\_texture]
(https://code.google.com/p/angleproject/source/browse/extensions/ANGLE_depth_texture.txt?name=master))
and earlier in the year we added support for instancing via attribute array
divisors ([ANGLE\_instanced\_arrays]
(https://code.google.com/p/angleproject/source/browse/extensions/ANGLE_instanced_arrays.txt?name=master)).
See ExtensionSupport for a complete list of extensions that are supported by
ANGLE.

## Shader Compiler

We have also made a number of improvements in the shader compiler.

* We addressed a number of defects related to scoping differences between HLSL and
GLSL and improved the scoping support in ANGLE's compiler front-end. We also
worked with The Khronos Group to get an ESSL spec bug fixed and several items
clarified.
* We addressed a number of correctness issues in the GLSL to HLSL
translation process. We fixed some bugs related to constant propagation and
comma conditional assignments. More importantly, we fully implemented support
for short-circuiting boolean logic operations. In GLSL, Boolean expressions do
short-circuit evaluation as in C, but HLSL evaluates them entirely. This only
has an observable effect if a short-circuited operation has side effects, such
as a function call that modifies global variables.
* We implemented detection
for discontinuous gradient or derivative computations inside loops and replace
them with explicitly defined continuous behaviour. HLSL and GLSL differ in their
specified behaviour for operations which compute gradients or derivatives.
Gradients are computed by texture sampling functions which don't specify a
specific mipmap LOD level, and by the OES\_standard\_derivatives built-in
functions. To determine the gradient, the corresponding values in neighbouring
pixels are differentiated. If neighbouring pixels execute different paths
through the shader this can cause a discontinuity in the gradient. GLSL
specifies that in these cases the gradient is undefined. HLSL tries to avoid the
discontinuity in the compiler by unrolling loops so that every pixel executes
all iterations. This can make the D3D HLSL compiler spend a long time generating
code permutations, and possibly even fail compilation due to running out of
instruction slots or registers. Because the GLSL specification allows undefined
behaviour, we can define such texture sampling functions to use mipmap LOD level
0, and have the derivatives functions return 0.0. To do this we examine the GLSL
code's abstract syntax tree and detect whether the shader contains any loops
with discontinuities and gradient operations. Within such loops, we generate
HLSL code that uses explicitly defined texture LODs and derivative information.
One additional consideration is that within these loops there can be calls to
user-defined functions which may contain gradient operations. In this case, we
generate variants of user-defined functions where these operations are
explicitly defined. We use these new functions instead of the original ones in
loops with discontinuities.

These fixes result in ANGLE being able successfully compile a number of the more
complex shaders. Unfortunately there are still some complex shaders which we
have not yet been able to obtain solutions for. Ultimately Direct3D 9 SM3
shaders are more restricted than what can be expressed in GLSL.  Most of the
problematic shaders we've encountered will also not compile successfully on
current ES 2.0 implementations.  We would only be able to achieve parity with
Desktop GL implementations by using Direct3D 10 or above.

## Texture Origin Changes

We have also made a major change to ANGLE in the way the origin difference
between D3D and OpenGL is handled. This difference is normally observable when
using render-to-texture techniques, and if not accounted for, it would appear
that images rendered to textures are upside down. In recent versions of ANGLE
(r536 (on Google Code)-r1161 (on Google Code)), we have been storing surfaces
following the D3D Y convention where (0, 0) is the top-left, rather than GL's
bottom-left convention. This was done by vertically flipping textures on load
and then adjusting the texture coordinates in the shaders to compensate. This
approach worked well, but it did leave the orientation of pbuffers inverted when
compared to native GL implementations. As of ANGLE r1162 (on Google Code), we
have changed this back to the original way it was implemented - textures are
loaded and stored in the GL orientation, and the final rendered scene is flipped
when it is displayed to a window by eglSwapBuffers. This should be essentially
transparent to applications except that orientation of pbuffers will change.  In
addition to fixing the pbuffer orientation, this change:

* eliminates
dependent-texture look-ups in the shaders, caused by flipping the texture
y-coordinates
* rounding of texture coordinates (while previously within spec)
will be more consistent with other implementations, and
* allows potential
faster paths for loading texture data to be implemented. The only potential
downside to this approach is that window-based rendering may be a bit slower for
simple scenes. The good news is that this path is not used by browser
implementations on most versions of Windows.

## Preprocessor

Finally, Alok P. from Google has been working on implementing a new shader
preprocessor for the last number of months and this effort is nearly complete.
This new preprocessor should be more robust and much more maintainable. It also
includes many (~5000) unit tests and passes all WebGL conformance tests. If you
wish to try this out before it is enabled by default, define
ANGLE\_USE\_NEW\_PREPROCESSOR=1 in your project settings for the
translator\_common project.

## Contributions

As always we welcome contributions either in the bug reports (preferably with an
isolated test-case) or in the form of code contributions. We have added a
[ContributingCode](ContributingCode.md) wiki page documenting the preferred
process for contributing code. We do need to ask that you sign a Contributor
License Agreement before we can integrate your patches.