When a EGL pbuffer is created based on a D3D SRGB texture using
EGL_ANGLE_d3d_texture_client_buffer, SRGB conversions are performed as
if it was an SRGB surface. The value of EGL_GL_COLORSPACE now
reflects that correctly. If the pbuffer is bound to a texture and used
as a framebuffer attachment, querying GL_FRAMEBUFFER_COLOR_ATTACHMENT
also reflects that correctly.
The behavior is the same on both the D3D backend, where there is no
native interop involved, and on the GL backend using
WGL_NV_DX_interop(2).
There are a few limitations on the GL backend that relies on native
interop:
1. SRGB conversion for textures created this way can't be disabled
using the GL_FRAMEBUFFER_SRGB_EXT toggle that's exposed in ANGLE
through EXT_sRGB_write_control. This is now documented in the
EGL_ANGLE_d3d_texture_client_buffer spec. On the D3D backend this is
not a problem since EXT_sRGB_write_control is not supported either
way.
2. Creating a pbuffer out of a D3D11 texture with the format
DXGI_FORMAT_B8G8R8A8_UNORM_SRGB does not work, even though it was
listed as one of the supported formats in the
EGL_ANGLE_d3d_texture_client_buffer spec. It's now mentioned that
support for this format is optional.
BUG=angleproject:2300
TEST=angle_white_box_tests
Change-Id: I70ee0646680805e4469291a5b2ce59e92fda009e
Reviewed-on: https://chromium-review.googlesource.com/866743Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
