webgl 1.0 sRGB extension is not set as preprocessor GLSL macro
Reported by
joel.sev...@gmail.com,
Dec 19 2016
|
|||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Steps to reproduce the problem:
Minimal reproducible (note that I have tried this in "real" code that actually works, except ifdef, aswell):
Fragment shader with the following code:
#ifndef GL_EXT_sRGB
crash_and_burn;
#endif
precision highp float;
void main(void) {
gl_FragColor = vec4(1.0);
}
Changing ifdef and ifndef shows that GL_EXT_sRGB is not defined. Neither is EXT_sRGB (which happens to be what the GL ES GLSL 1 spec says, see bottom of 3.4 Preprocessor: https://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf ). However, some other extensions seem to work. For example GL_EXT_draw_buffers is defined, while EXT_draw_buffers is not. I believe the GL_ prefix is used on desktop GL and that the behavior in this case also is slightly wrong, but I don't know for sure.
What is the expected behavior?
The #ifdef EXT_sRGB or at least the #ifdef GL_EXT_sRGB branch should be taken, as the sRGB extension is there (I can not only query it but it actually works, things on screen get darker with it turned on a texture).
What went wrong?
It does not recognize GL_EXT_sRGB, even though I can successfully query it with gl.getExtension("EXT_sRGB"). The mechanism works with other extensions.
Did this work before? N/A
Does this work in other browsers? N/A
Chrome version: 55.0.2883.87 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 24.0 r0
Also tested in Version 57.0.2955.0 canary (64-bit).
It should be noted that EXT_sRGB does not work in Firefox. Also, only texture format ext.SRGB_ALPHA_EXT works, ext.SRGB_EXT and ext.SRGB8_ALPHA8_EXT was not accepted - maybe indicating a dodgy driver?
Graphics card: GTX 1060
,
Dec 19 2016
,
Dec 28 2016
,
Nov 1 2017
,
Nov 3 2017
kai can you have a look?
,
Nov 3 2017
I'm going to tentatively add Internals>GPU>ANGLE as it sounds like a shader translator issue. I'll look into it further later. Reporter: I know it's been ages, but any chance you could give a standalone test HTML page that reproduces the issue?
,
Nov 3 2017
I'm not certain that GL_EXT_sRGB is expected to be visible inside the shader. The extensions https://www.khronos.org/registry/webgl/extensions/EXT_sRGB/ https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_sRGB.txt don't seem to mention it. But I'm not sure offhand whether the spec has to explicitly add the preprocessor macro or if it happens automatically for all extensions. They may be expecting applications to generate shaders based on extension support, which I suspect is what other engines are doing.
,
Nov 3 2017
Sorry this took so long to get onto our plate. Always feel free to point out recently filed bugs on the webgl-dev-list Google group if they haven't been triaged after a while. I think there's confusion between API-level extensions and shading language extensions. Those API-level extensions which actually do modify the behavior of the shading language explicitly document this. See "New Macro Definitions" for example in: https://www.khronos.org/registry/OpenGL/extensions/OES/OES_standard_derivatives.txt I think this should be closed as WontFix. It wouldn't be standard to expose all supported extensions as macros in the shading language.
,
Nov 3 2017
Okay, I agree. Reporter, please let us know if you disagree. The solution here is to snip shader strings together at runtime. You could basically just prepend "#define GL_EXT_sRGB" onto your shader programmatically to make the same approach work. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by joel.sev...@gmail.com
, Dec 19 2016