OpenGL ES Porting Guide
Note: | This chapter is currently under review. We recommend that before you use this information, check with your NVIDIA customer engineer (CE) for verification of its accuracy. |
This document contains important information to help you adapt applications running on NVIDIA® Tegra® 3/Tegra 2 family of processors to run on the following processors with minimal integration changes:
• NVIDIA® Tegra® code-name Parker
• NVIDIA® Tegra® X1
• NVIDIA® Tegra® K1 (32 bit)
• NVIDIA® Tegra® 4
For detailed listing of supported features, see the SDK Release Notes for your operating system supporting that processor.
Additional Resources
The following table shows the OpenGL version support for each processor:
Processor | Support OpenGL Version |
Tegra Parker | ES 3.2 |
Tegra X1 | ES 3.2 |
Tegra K1 (32-bit) | ES 3.1 |
Tegra 4 | ES 2.0 |
OpenGL ES 3.2 is backward compatible with OpenGL ES 2.0, with few exceptions. For more information, refer to the following:
• OpenGL ES Registry:
• OpenGL ES 3. 2 Specification:
• Consult Appendix E “Version 3.0 and Before” for a listing of new features.
• Consult Appendix F “OpenGL ES 2.0 Compatibility” for a listing of legacy features.
Mapping OpenGL ES 2 to OpenGL ES 3
The following table identifies the OpenGL ES 2.0 extensions supported on Tegra family of processors that are now part of the core OpenGL ES 3.0 specification. Instead of using these extensions, use the core functionality available in the specification. However, thisis not required as the extensions are available for backward compatibility with older applications.
Tegra Extensions Moved to Open GL ES 3.2 Core
The following Tegra extensions have moved to the OpenGL ES 3.2 specifications.
• GL_EXT_blend_minmax
• GL_OES_compressed_ETC1_RGB8_texture
• GL_NV_copy_buffer
• GL_NV_draw_buffers
• GL_NV_explicit_attrib_location
• GL_NV_fbo_color_attachments
• GL_OES_fbo_render_mipmap
• GL_NV_framebuffer_blit
• GL_EXT_map_buffer_range
• GL_OES_mapbuffer
• GL_NV_non_square_matrices
• GL_EXT_occlusion_query_boolean
• GL_NV_pack_subimage
• GL_NV_pixel_buffer_object
• GL_OES_rgb8_rgba8
• GL_OES_surfaceless_context
• GL_OES_texture_half_float
• GL_EXT_texture_rg
• GL_EXT_texture_storage
• GL_OES_vertex_half_float
• GL_OES_vertex_array_object
Unsupported Extensions
The following table identifies OpenGL ES 2.0 extensions that are currently available on earlier Tegra processors but are not yet available on the Tegra Parker and X1 processors.
Action | When Support will be Available | Description |
GL_EXT_read_format_bgra | TBD | GL_EXT_texture_format_BGRA8888 covers some of the functionality |
GL_NV_uniform_buffer_object | OpenGL ES 2.0 TBD | Functionality available in OpenGL ES 3.0 or later. |
Unsupported Extensions with Workarounds
The following table identifies extensions available on earlier Tegra processors that are no longer available on the Tegra Parker and X1 processors. Strategies and alternative implementation methods are identified where available.
Extension | Unsupported Feature | Workaround |
EGL_NV_coverage_sample | Virtual coverage sample anti-aliasing is not supported. | Use MSAA with 2, 4, or 8 samples per pixel. |
EGL_NV_coverage_sample_resolve | No support provided. | Not applicable, EGL_NV_coverage_sample is needed. |
EGL_NV_depth_nonlinear | Non-linear 16-bit depth buffer is not supported. | Use 24-bit depth or more depth buffers. |
NV_draw_path | No support provided. | Use GL_NV_path_rendering extension instead. This extension provides high quality path rendering using a Stencil then Cover approach. |
GL_NV_EGL_image_external_YUV | No support provided. | Use EGL streams instead. |
GL_EXT_multiview_draw_buffers | Partially supported through NV_drawbuffers and core OpenGL ES 3.1. Windows with stereo support are not supported. | If you need windows with stereo support, please contact NVIDIA. |
GL_NV_platform_binary | No support provided. Pragmas for compiling a shader program against a specific GL state is also not supported. | Shaders compiled for Tegra 3 family of processors is NOT compatible with Tegra K1 family processors. Use source shaders. To reduce compile time, the driver keeps shader cache on the disk. This type of cache is available on Tegra 3 family of processors and can be enabled on demand. OpenGL ES 3.2 provides glProgramBinary for applications saved in binary program loading. The application must: • Check the return status. • If the binary program is not compatible, load the binary program using the original shader source, and then compile, and link. • Retrieve the binary for future use. For more details, see Section 7.5 in the OpenGL ES 3.2 Specification. An NVIDIA offline compiler for OpenGL ES programs loadable by glProgramBinary is planned for future release. |
GL_NV_shader_framebuffer_fetch | Deprecated on earlier Tegra processors. Not available on Tegra Parker and X1 processors. | The Tegra Parker and X1 processors performs blending in a separate hardware unit. In addition to the normal blend modes defined by OpenGL ES 3.2, you can use the NV_blend_equation_advanced and NV_blend_equation_advanced_coherent extensions to implement more advanced blending. |
GL_NV_texture_npot_2D_mipmap | No support provided. | Use OES_texture_npot in OpenGL ES 2.0 or OpenGL ES 3.2. The functionality in OES_texture_npot is a super-set of GL_NV_texture_npot_2D_mipmap. |
The following sections provide detailed workarounds for some of the extensions in the tables in this section.
NV_coverage_sample
The Tegra Parker and X1 processors do not support Tegra 3 style virtual coverage sample antialiasing. Use MSAA with 2, 4 or 8 samples per pixel instead. When requesting an EGL config, use EGL_SAMPLE_BUFFERS = 1, and EGL_SAMPLES = <2, 4 or 8> instead of EGL_COVERAGE_SAMPLES_NV and EGL_COVERAGE_BUFFERS_NV. Use the number of samples to trade image quality for performance and memory consumption. Using EGL_SAMPLES=2 will produce higher image quality than Tegra 3 style virtual coverage antialiasing.
When rendering using an FBO, you can no longer use the GL_COVERAGE_ATTACHMENT_NV attachment point, nor create a coverage buffer with GL_COVERAGE_COMPONENT_NV.
For higher quality FBO rendering, use the GL_NV_framebuffer_multisample extension functionality to render to a multisampled RBO, and then perform a copy that resolves (filters) the samples using the GL_NV_framebuffer_blit extension. (This functionality is also available in core OpenGL ES 3.0.) The GL_NV_read_buffer and GL_NV_draw_buffer can further allow reading from other attachment points, and drawing to multiple buffers.
The following is a simple example showing the intended usage pattern.
// Bind the RBOs and create the storage
glBindRenderbuffer(GL_RENDERBUFFER, <rboColorMSAAObject>);
glRenderbufferStorageMultisampleNV ( GL_RENDERBUFFER, <samples>, <format, e.g. GL_RGBA8>, <width>, <height>);
glBindRenderbuffer(GL_RENDERBUFFER, <rboDepthMSAAObject>);
glRenderbufferStorageMultisampleNV ( GL_RENDERBUFFER, <samples>, <format, e.g. GL_DEPTH_COMPONENT24>, <width>, <height>);
// Attach it
glFramebufferRenderbuffer(GL_RENDERBUFFER, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, <rboColorMSAAObject>);
glFramebufferRenderbuffer(GL_RENDERBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, <rboDepthMSAAObject>);
<Render to MSAA buffer>
< Then blit and resolve the MSAA buffer to another FBO, which may be the default FBO or another texture>
glBindFramebuffer(GL_READ_FRAMEBUFFER_NV, <MSAA FBO>
glReadbufferNV(GL_COLOR_ATTACHMENT0);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER_NV, <targetframebuffer>);
glDrawbuffersNV(1, <pointer to array specifying target>);
// Copy and resolve
glBlitFramebufferNV(<srcX0>, <srcY0>, <srcX1>, <srcY1>,
<dstX0>, <dstY0>, <dstX1>, <dstY1>,
<mask>, <filter>);
Note: | Alternatively, you can use the multisampled textures (See section 8.8 and 9.2.8 in the OpenGL ES 3.1 specification.) |
NV_depth_nonlinear
The Tegra Parker and Tegra X1 do not support the non-linear 16-bit depth buffer. Use depth buffers with 24 or more bits. When requesting an EGLConfig, do not use EGL_DEPTH_ENCODING_NV = EGL_DEPTH_ENCODING_NONLINEAR_NV. Instead, simply set EGL_DEPTH_SIZE to 24.
Supported Extensions
To obtain the latest list of currently supported extensions for Tegra Parker and Tegra X1 processors; query it from the driver using the GL_EXTENSION string. Some extensions are for OpenGL ES 2.0 and are included for compatibility.
Note: | The list of supported extensions is subject to change with each release. |
Many of these supported extensions are based on the full OpenGL extensions. Complete OpenGL ES extension specifications are not currently written.
Modified Implementation Details
The following OpenGL ES 2.0 hardware specific details have been modified between the Tegra Parker and X1 processors.
• The Tegra Parker and X1 processors supports multi-sampled rendering. Earlier Tegra processors does not support multi-sampled rendering. The maximum value of EGL_SAMPLE_BUFFERS is 1. The maximum supported value of EGL_SAMPLES is 8.
For more details, see section 3.4.1 of the OpenGL 1.4 Specification.
• Because the Tegra Parker and X1 processors have unified shader architecture, the same hardware unit is used for vertex and fragment shader execution. These processors use separate units for shader execution. This implies that load balancing is performed automatically. The same feature set is available for both types of shaders.
• The Tegra Parker and X1 processors performs blending using a specialized hardware unit. This means that there is no modification of shader instructions, depending on the blend state. There is no difference between using binary programs and source shaders in this case. The GL state should be set according to the OpenGL ES 3.2 specifications. This also means that changing the shader program depending on the blend mode is not needed.
• The Tegra Parker and X1 processors support texture samplers in vertex shaders. GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is no longer 0.
• The Tegra Parker and X1 processors do not distinguish between shader precision qualifiers. All floating point operations are 32-bit. Earlier Tegra processors used:
• 32-bit in the vertex processors
• 20-bit floating point
• 10-bit fixed point operation in the fragment processor
• The Tegra Parker and X1 processors supports dynamic branching in both the fragment and vertex shader. Earlier Tegra versions supports dynamic branching in the vertex shader.
• The Tegra Parker and X1 processors do not support a separate stencil buffer. Stencil buffers must always be paired with a depth buffer. The implication of this is that an RBO with only a stencil buffer (format STENCIL_INDEX8) cannot be used with a FBO. Instead, use an RBO with sized format (DEPTH24_STENCIL8) and attach that to both the stencil and depth attachment point of the FBO. This is supported by Open GL ES 3, and also the OpenGL ES 2 extension GL_OES_packed_depth_stencil.
The following example illustrates how you can create RBOs and attach them for the Tegra processors.
GLuint depthObjectToAttach;
GLuint stencilObjectToAttach;
if (<supports GLES 3 and/or the OES_packed_depth_stencil extension>) {
// This path will be executed on Tegra K1, as well as other implementation that supports
// GLES 3 and/or packed depth stencil formats.
glBindRenderbuffer( GL_RENDERBUFFER, <rboDepthObject>);
glRenderbufferStorage( GL_RENDERBUFFER, GL_DEPTH24_STENCIL8, <width>, <height>);
// We will use the same object at both attachment points below.
depthObjectToAttach = <rboDepthObject>;
stencilObjectToAttach = <rboDepthObject>;
}else {
// This path will be executed on Tegra 3. We therefor use a 16 bit depth buffer.
glBindRenderbuffer( GL_RENDERBUFFER, <rboDepthObject>);
glRenderbufferStorage( GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, <width>, <height>);
glBindRenderbuffer( GL_RENDERBUFFER, <rboStencilObject>);
glRenderbufferStorage( GL_RENDERBUFFER, GL_STENCIL_INDEX8, <width>, <height>);
// We will use separate objects at the attachment points below.
depthObjectToAttach = <rboDepthObject>;
stencilObjectToAttach = <rboStencilObject>;
}
glFramebufferRenderbuffer( GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, depthObjectToAttach);
glFramebufferRenderbuffer( GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT, GL_RENDERBUFFER, stencilObjectToAttach);
• In most circumstances, using a 24-bit depth buffer instead of a 16-bit buffer benefits performance, despite the extra memory allocation. When requesting a 16 bit depth config for EGL, a 24 bit config is actually returned. When creating a RBO, use GL_DEPTH_COMPONENT24, instead of instead of GL_DEPTH_COMPONENT16. If you also need a stencil buffer, use GL_DEPTH24_STENCIL8.
• Using stencil buffers is relatively expensive, especially when MSAA is used. If possible, avoid using stencil buffers, or replace the stencil buffers with depth buffers (test using a 24-bit depth buffer).
• The Tegra Parker and X1 processors do not support dithering while rendering. This has implications when rendering to a 16 bit (RGB) target, for instance. Gradients may look especially different compared to those produced with earlier Tegra processors in such cases.
• Make sure that unused vertex arrays are disabled. These were silently ignored on earlier Tegra processors.
• As with earlier Tegra processors, no assumption on the number of color buffers, nor the content within those buffers can be made, other than what is mentioned in the OpenGL ES 3.2 and EGL 1.4 specifications. Do not assume that there are two distinct color buffers.
• Due to hardware implementation changes, the supported EGLconfigs have also changed.
For more information, see Section 3.4.1 of the EGL 1.4 Specification that describes how an EGLConfig is chosen. Additionally, see Section 3.4.3 for information about querying a configuration attribute.
