Open topic with navigation
EGL’s method of sorting configurations returned from queries is often counter-intuitive. Applications using
eglChooseConfig must not simply select the first returned configuration, nor should they request only one configuration. An example of a common and confusing case is requesting a 565 RGB configuration. Owing to section 3.4 of the EGL spec,
eglChooseConfig must return the deepest color buffer first, even if it is deeper than the requested format, and even if the requested format could have been matched exactly. In other words, an implementation that supports 565 and 8888 must return 8888 earlier in the list than 565, even if 565 is requested. The EGL spec notes the following in a footnote to 3.4:
“This rule places configs with deeper color buffers first in the list returned by eglChooseConfig. Applications may find this counterintuitive, and need to perform additional processing on the list of configs to find one best matching their requirements. For example, specifying RGBA depths of 5651 could return a list whose first config has a depth of 8888.”
Applications should always request an array of multiple configurations, and should query important attributes such as red, green and blue depths of each, performing their own manual sorting and filtering of the resulting array. EGL’s behavior is defined by the spec; Tegra’s driver cannot deviate from the proscribed order.
Tegra does not support rendering to 24-bit “888” buffers. Applications wishing to use such formats should request a RGBA8888 format to ensure that the OS does not return a SW-emulated configuration. Requesting 24-bit RGB888 with OpenGL ES1.x on Android can lead to a SW-rendered configuration and decreased performance and available features
NVIDIA® GameWorks™ Documentation Rev. 1.0.200608 ©2014-2020. NVIDIA Corporation. All Rights Reserved.