summaryrefslogtreecommitdiffstats
path: root/bin
diff options
context:
space:
mode:
authorIan Romanick <[email protected]>2017-01-23 09:57:15 -0800
committerIan Romanick <[email protected]>2017-01-24 13:39:26 -0800
commitc4a0c1efff77ed90dfebf969348cd440195ae38a (patch)
tree4b96ab3b4cd80dd651ebe2b9fd14b661cb63f8cb /bin
parentb87eedd405f03f51dc99d5971cb106fdf215a2b8 (diff)
mesa: Don't advertise GL_OES_read_format in core profile
OpenGL ES implementations are not allowed to ship ARB extensions, and OpenGL implementations are not allowed to ship OES extensions. The functionality is also included in GL_ARB_ES2_compatibility. Ever OpenGL core-profile driver currently exposes both extensions. I don't know of any applications that explicitly check for GL_OES_read_format, so removing it seems very unlikely to cause problems. No functionality is removed. I have left this extension in place for compatibility profile. There are still OpenGL 1.x drivers in Mesa, and adding code to check for compatibility profile and not GL_ARB_ES2_compatibility for GL_IMPLEMENTATION_COLOR_READ_TYPE and GL_IMPLEMENTATION_COLOR_READ_FORMAT just feels dumb. Three other other alternatives considered: - Remove the string from compatibility profile drivers but leave the functionality in place. - Add a flag to expose the extension string, and set it in every OpenGL driver that does not expose GL_ARB_ES2_compatibility (and those drivers only). I tried this. You can't have two instances of an extension in the extension table (one dummy_true for ES1 and one with a flag for compatibility profile), so the implementation requires a bit of effort. - Only expose the extension in compatibility if the version is less than 2.0. I didn't see an easy way to do this. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: [email protected]
Diffstat (limited to 'bin')
0 files changed, 0 insertions, 0 deletions