-
Notifications
You must be signed in to change notification settings - Fork 0
Tech. EScompat
OpenGL ES 2.0 is designed to be mostly compatible with normal OpenGL. At this page we list the incompatibilities. We should try to "fix" these incompatibilities so that the user can use vispy.oogl as if it was real ES 2.0.
There are cases where the incompatibility cannot really be fixed or hidden. These cases should be clearly documented.
Note that quite a few of the incompatibilities are related to shaders and there is a chance that even a real ES 2.0 system will still allow the feature. Especially WebGL, which uses proper hardware when used on a PC anyway (but this needs testing).
In ES one can use the #version pragma using #version 100, since the GLSL spec is called "OpenGL ES shading language v1.00". However, this version corresponds best with version 1.20 of normal GLSL. So when we run on normal GL we want to use #version 120. We found that most browsers do not support the version pragma at all.
Resolution: We insert a version pragma on desktop GL, unless one is already specified
The gold book (p. 79) says that the GLSL ES is more strict on types, and one cannot even do 1 + 1.0.
Resolution: Take this into account when writing shading code.
There are some restrictions on for-loops in GLSL ES, because implementations must be able to unroll them. Most restrictions are ok (e.g. the counter can only be updated in the loop spec). See p. 154,
However, the number of iterations must be known at compile time. So the N in for (i=0; i<N; i++) should be a constant or literal; it cannot be a uniform or a computed value. It is not clear to me whether it is an error to use a uniform value, or that it simply might not be supported (I'm guessing the latter).
Resolution: Document this (or just refer people to GLSL ES documentation). If people write code for normal GL they can just use any for-loop. And there is a big chance that it will be possible on WebGL as well.
In the fragment shader uniform arrays cannot be indexed with a computed index. Well, it may be possible, but it is not guaranteed to be possible. (p. 212) Not that big a problem, I guess.
Resolution: avoid doing this. If really necessary the code may simply not work on real ES.
(p. 97 and 212)
ES 2.0 provides precision qualifiers so the implementation can reduce power and memory. Some OpenGL implementations support this too (as a compatibility feature), but we cannot rely on that.
The default precision of a vertex shader is highp so no problem here. For the fragment shader, however, there is no default precision for floats, so it should be specified explicitly. With e.g. precision highp float. Note that we need to check whether highp is supported for fragments and use mediump if they are not (mediump is guaranteed to be supported).
Resolution: Vispy can prepend the fragment shader code with the precision qualifier, or remove the qualifier in desktop GL.
In ES you need to specify if an extension is used. Is this the case for normal GL as well?
Resolution: We can probably prepend these automatically (e.g. #extension GL_OES_texture_3D : enable).
(p.99) of the gold book.
Resolution: need checking. Document if necessary
Memory and the packing mechanisms. I suppose that this is similar in GL, but we should check. (p. 94).
Resolution: It sorts of means code that uses too many uniforms or attributes will not compile. But my guess is that in WebGL running on a desktop/laptop the number of uniforms and attributes would be similar to normal GL.
The gold book mentions all the builtin functions. We should check how that matches up with version 1.20 of normal GLSL.
Resolution: Document all builtin functions.
With ES, a texture can only be non-power of two if the clamping is GL_TEXTURE_CLAMP_TO_EDGE, and mipmapping cannot be used (p. 277). That is, unless the GL_OES_texture_npot extension is available (p. 214).
Resolution: On all PC-implementations (e.g. WebGL) this extension will probably be available, so I do not think we have to worry about this one.
That is said on p. 17. Although p. 238 says its not. Needs testing I guess.
Resolutions: We can disable it on startup or something.
(p. 63 in the gold book, also in the online docs of glAttachShader.)
Resolutions: We support an API that supports one of each shader.
So no integers or other special types.
Resolution: Does not seem like such a big problem; you can still upload the data in different formats. It's just that in GLSL only float types are allowed. Perhaps we can check for that and warn if necessary.
In particular, GL_FLOAT is available as an extension. ES has GL_HALF_FLOAT, but PyOpenGL does not know what to do with that. There are no types to explicitly state that a texture should be stored with float32 precision.
Resolution: For most use-cases this should not be a problem, but there may be specific cases where it is. If we find this necessary, we can perhaps support GL_RGBA_32F and others on non-ES systems.
GL_POINT_SPRITE and GL_VERTEX_PROGRAM_POINT_SIZE.
Resolution: Enable point sprites on initialization for desktop GL.
ES 2.0 (and WebGL) do not support Texture3D, which can be a significant limitation in scientific visualization (in particular for volume rendering).
ES 2.0 (or webgl?) has a limit on the size of the index buffer, which can be problematic when visualizing large meshes.
WebGL does not allow sharing objects between contexts. This makes things simpler, but can be limiting for certain applications.