1# ANGLE Development Update - July 4, 2012 2 3We haven't posted an update on the development status of ANGLE in quite some 4time and we'd like to provide an update on some of the new features and 5improvements that we've been working on. 6 7## Conformance 8 9As announced in the [Chromium Blog] 10(http://blog.chromium.org/2011/11/opengl-es-20-certification-for-angle.html), 11ANGLE v1.0 has passed the Khronos OpenGL ES 2.0 certification process and is now 12a [conformant](http://www.khronos.org/conformance/adopters/conformant-products/) 13OpenGL ES 2.0 implementation. 14 15## Extensions 16 17We have recently completed the implementation of depth texture support 18([ANGLE\_depth\_texture] 19(https://code.google.com/p/angleproject/source/browse/extensions/ANGLE_depth_texture.txt?name=master)) 20and earlier in the year we added support for instancing via attribute array 21divisors ([ANGLE\_instanced\_arrays] 22(https://code.google.com/p/angleproject/source/browse/extensions/ANGLE_instanced_arrays.txt?name=master)). 23See ExtensionSupport for a complete list of extensions that are supported by 24ANGLE. 25 26## Shader Compiler 27 28We have also made a number of improvements in the shader compiler. 29 30* We addressed a number of defects related to scoping differences between HLSL and 31GLSL and improved the scoping support in ANGLE's compiler front-end. We also 32worked with The Khronos Group to get an ESSL spec bug fixed and several items 33clarified. 34* We addressed a number of correctness issues in the GLSL to HLSL 35translation process. We fixed some bugs related to constant propagation and 36comma conditional assignments. More importantly, we fully implemented support 37for short-circuiting boolean logic operations. In GLSL, Boolean expressions do 38short-circuit evaluation as in C, but HLSL evaluates them entirely. This only 39has an observable effect if a short-circuited operation has side effects, such 40as a function call that modifies global variables. 41* We implemented detection 42for discontinuous gradient or derivative computations inside loops and replace 43them with explicitly defined continuous behaviour. HLSL and GLSL differ in their 44specified behaviour for operations which compute gradients or derivatives. 45Gradients are computed by texture sampling functions which don't specify a 46specific mipmap LOD level, and by the OES\_standard\_derivatives built-in 47functions. To determine the gradient, the corresponding values in neighbouring 48pixels are differentiated. If neighbouring pixels execute different paths 49through the shader this can cause a discontinuity in the gradient. GLSL 50specifies that in these cases the gradient is undefined. HLSL tries to avoid the 51discontinuity in the compiler by unrolling loops so that every pixel executes 52all iterations. This can make the D3D HLSL compiler spend a long time generating 53code permutations, and possibly even fail compilation due to running out of 54instruction slots or registers. Because the GLSL specification allows undefined 55behaviour, we can define such texture sampling functions to use mipmap LOD level 560, and have the derivatives functions return 0.0. To do this we examine the GLSL 57code's abstract syntax tree and detect whether the shader contains any loops 58with discontinuities and gradient operations. Within such loops, we generate 59HLSL code that uses explicitly defined texture LODs and derivative information. 60One additional consideration is that within these loops there can be calls to 61user-defined functions which may contain gradient operations. In this case, we 62generate variants of user-defined functions where these operations are 63explicitly defined. We use these new functions instead of the original ones in 64loops with discontinuities. 65 66These fixes result in ANGLE being able successfully compile a number of the more 67complex shaders. Unfortunately there are still some complex shaders which we 68have not yet been able to obtain solutions for. Ultimately Direct3D 9 SM3 69shaders are more restricted than what can be expressed in GLSL. Most of the 70problematic shaders we've encountered will also not compile successfully on 71current ES 2.0 implementations. We would only be able to achieve parity with 72Desktop GL implementations by using Direct3D 10 or above. 73 74## Texture Origin Changes 75 76We have also made a major change to ANGLE in the way the origin difference 77between D3D and OpenGL is handled. This difference is normally observable when 78using render-to-texture techniques, and if not accounted for, it would appear 79that images rendered to textures are upside down. In recent versions of ANGLE 80(r536 (on Google Code)-r1161 (on Google Code)), we have been storing surfaces 81following the D3D Y convention where (0, 0) is the top-left, rather than GL's 82bottom-left convention. This was done by vertically flipping textures on load 83and then adjusting the texture coordinates in the shaders to compensate. This 84approach worked well, but it did leave the orientation of pbuffers inverted when 85compared to native GL implementations. As of ANGLE r1162 (on Google Code), we 86have changed this back to the original way it was implemented - textures are 87loaded and stored in the GL orientation, and the final rendered scene is flipped 88when it is displayed to a window by eglSwapBuffers. This should be essentially 89transparent to applications except that orientation of pbuffers will change. In 90addition to fixing the pbuffer orientation, this change: 91 92* eliminates 93dependent-texture look-ups in the shaders, caused by flipping the texture 94y-coordinates 95* rounding of texture coordinates (while previously within spec) 96will be more consistent with other implementations, and 97* allows potential 98faster paths for loading texture data to be implemented. The only potential 99downside to this approach is that window-based rendering may be a bit slower for 100simple scenes. The good news is that this path is not used by browser 101implementations on most versions of Windows. 102 103## Preprocessor 104 105Finally, Alok P. from Google has been working on implementing a new shader 106preprocessor for the last number of months and this effort is nearly complete. 107This new preprocessor should be more robust and much more maintainable. It also 108includes many (~5000) unit tests and passes all WebGL conformance tests. If you 109wish to try this out before it is enabled by default, define 110ANGLE\_USE\_NEW\_PREPROCESSOR=1 in your project settings for the 111translator\_common project. 112 113## Contributions 114 115As always we welcome contributions either in the bug reports (preferably with an 116isolated test-case) or in the form of code contributions. We have added a 117[ContributingCode](ContributingCode.md) wiki page documenting the preferred 118process for contributing code. We do need to ask that you sign a Contributor 119License Agreement before we can integrate your patches. 120