diff options
author | Ian Romanick <[email protected]> | 2017-01-23 09:57:15 -0800 |
---|---|---|
committer | Ian Romanick <[email protected]> | 2017-01-24 13:39:26 -0800 |
commit | c4a0c1efff77ed90dfebf969348cd440195ae38a (patch) | |
tree | 4b96ab3b4cd80dd651ebe2b9fd14b661cb63f8cb /appveyor.yml | |
parent | b87eedd405f03f51dc99d5971cb106fdf215a2b8 (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 'appveyor.yml')
0 files changed, 0 insertions, 0 deletions