kc3-lang/angle

2018-01-08T16:39:45

Set colorspace of D3D pbuffers according to DXGI format 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/866743 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>