I am trying to make use of some ES 3.1 features, and it's unclear if this is supported:
I notice that there is an OpenGL ES 3.1 header in the emscripten repository which defines some of the functions I'm looking for, and I can include them successfully in my project. However, they are not available when I try to link:
error: undefined symbol: glDispatchCompute (referenced by top-level compiled C/C++ code)
warning: _glDispatchCompute may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
The documentation says that OpenGL ES3 is supported if I specify -s FULL_ES3=1 (which I am doing).
Since there are headers for it, is this functionality available? If so, how do I enable support for it? (Does it require manually loading extensions or enabling experimental support in emscripten, for example?)
First thing to realize, is that decent Browsers currently implement only WebGL 1.0 (based on OpenGL ES 2.0) and WebGL 2.0 (based on OpenGL ES 3.0). So that Emscripten SDK may implement only features presented by WebGL 2.0 + extensions, and, unfortunately, Compute Shaders are not presented in any way in WebGL (and there are no more plans to add this functionality in future).
By the way, WebGL 2.0 support has been added to Safari 15 (iOS 15) only this (2021) year, so that even OpenGL ES 2.0 will not work on all devices.
I notice that there is an OpenGL ES 3.1 header in the emscripten
The extra <GLES3\gl3*.h> headers are there not because Emscripten implements all of them, but because this is a common way to distribute OpenGL ES 3.x headers that existing applications may rely on to conditionally load / use OpenGL ES 3.x functions at runtime, when they available.
The documentation says that OpenGL ES3 is supported if I specify -s FULL_ES3=1 (which I am doing).
I think that documentation is more or less clear about what FULL_ES3=1 adds:
To enable OpenGL ES 3.0 emulation, specify the emcc option -s FULL_ES3=1 when linking the final executable (.js/.html) of the project.
This adds emulation for mapping memory blocks to client side memory.
There is no word about OpenGL ES 3.1 here, nor a reason to expect a wonder from Emscripten, as I can barely imagine a reasonable hardware-accelerated way to emulate things like Compute Shaders on top of OpenGL ES 3.0. And software emulation would be certainly of no use for most applications.
WebGPU 1.0 that promised to appear mid '2022, is more capable than WebGL 2.0. So that WebGPU developers already see that at one time native WebGL 2.0 implementation in the Browsers could be replaced by a WebAssembly module implementing this legacy API on top of WebGPU - but in some very distant future. The same could also bring OpenGL ES 3.1/3.2 features to Emscripten SDK - at least theoretically, if somebody will be still interested to work on this.
Related
Previously I'm using OpenGL on Mac via glew 2.1.0 and JUCE5, but it can only access OpenGL 2.1 APIs. I can't believe that my Macbook Air (Intel Graphics) bought on 2018 can only provide this, and I'm tired to maintain two sets of API calls and shaders for 2.1 and 3.X separately. Then I tried to replace all #include <GL/glew.h> with #include <OpenGL/gl3.h>, then link with OpenGL framework directly. However, the program still failed to compile a #version 130 shader (it claims not supported).
Here I want to know that:
Does all recent Apple devices (after 2010) capable for OpenGL 3.0?
How to turn on OpenGL 3.0 support on MacOS?
Finally I found the way: I have to enable it on JUCE side. When JUCE's OpenGL context is created, I must explicitly set expected OpenGL version by setOpenGLVersionRequired( juce::OpenGLContext::openGL3_2 ) before using it.
IMPORTANT: this would still lead failure to a compile to #version 130 shader, as Apple would strictly deprecate all old features prior to specified API version. A simple workaround is to dynamically prepend a version declaration according to system type, as GLSL 1.3.0 features is mostly included by GLSL 1.5.0.
I'm trying to build OpenSceneGraph 3.2 for the Ubuntu armhf architecture, but I'm getting a compile error about a symbol not found. The symbol in question is glReadBuffer. I looked at GLES2/gl2.h header, and indeed, that symbol is not there. However, the symbol is present in GLES3/gl3.h, and documentation online suggests that the function was added in OpenGL ES 3.0. However, I did find a function named glReadBufferNV in GLES2/gl2ext.h (which is not #include'd in the source files.
I'm wondering if glReadBufferNV can be used instead of glReadBuffer, and what might be the possible side effects. I'm suspecting that the NV stands for Nvidia, and that it is a Nvidia-only implementation. Is this correct? If so, is there any way to get glReadBuffer in OpenGL ES 2.0 (I am under the impression that OpenSceneGraph can be built under OpenGL ES 2.0)?
Edit: As it turned out, the code that builds this portion of OpenSceneGraph was excluded when building with OpenGL ES or OpenGL 3.0. However, I'm still interested in what's special about glReadBufferNV.
As your research suggests, glReadBuffer was added to ES for 3.0; it is not defined in 2.0. Prior to that, as per the header file you found, an extension defined glReadBufferNV — specifically the NV_read_buffer extension.
So what's happened is that something wasn't in the spec, at least Nvidia thought it would be useful, so they've implemented an OpenGL extension, which has subsequently been discussed at Khronos, had all the edge cases or ambiguities dealt with and has eventually made its way into the core spec.
That's generally how GL development proceeds: extensions come along to provide functionality that's not yet in the main library, they're discussed and refined and adopted into the core spec if appropriate.
Comparing the official specification for glReadBuffer with the extension documentation, the extension has a few ties into other extensions that you wouldn't expect to make it into the core spec (e.g. COLOR_ATTACHMENTi_NV is supported as a source) but see resolved issue 7:
Version 6 of this specification isn't compatible with OpenGL ES 3.0.
For contexts without a back buffer, this extension makes FRONT the
default read buffer. ES 3.0 instead calls it BACK.
How can this be harmonized?
RESOLVED: Update the specification to match ES 3.0 behavior. This
introduces a backwards incompatibility, but few applications are
expected to be affected. In the EGL ecosystem where ES 2.0 is
prevalent, only pixmaps have no backbuffer and their usage remains
limited.
So the extension has retroactively been modified to bring it into line with what was agreed for the core spec.
I need to software render OpenGL in Windows and have already found about Mesa3D, which doesn't provide DLLs and I'm having some pain to build... Are there alternatives available?
That depends on what OpenGL version you wish to accelerate. Depending on your needs, there are some alternatives available. I've listed those I'm aware of below:
OpenGL 1.0 & 1.1
Windows (since Windows NT 3.5) actually includes an OpenGL software implementation to begin with. If you haven't installed any other software rasterizer, this ought to be your default implementation. The Microsoft software rasterizer supports either OpenGL 1.0 or 1.1, depending on your platform, but will not accelerate anything newer than that. If your desired OpenGL version is covered by 1.0 or 1.1 (however unlikely), the solution should be sufficient. I'm unsure as to what extent the default Windows OpenGL software implementation covers the OpenGL ES 1.x frameworks through its OpenGL 1.0 or 1.1 support.
OpenGL 1.4
Furthermore, in Windows Vista, Microsoft included an emulation layer which may translate OpenGL into Direct3D; thus supporting up-to OpenGL 1.4. Additionally, this should mean that Windows Vista (and up?) runtimes may accelerate most parts of OpenGL SC. I've never used this emulator myself, and was quite surprised to hear about it, but it may be of interest to someone having to run one of these old frameworks in a Windows environment.
Note that the standard Windows OpenGL software rasterizer (OpenGL 1.0 or 1.1) is also included in Windows Vista and above.
OpenGL ES 2.0
Additionally, there's the ANGLE project which accelerates WebGL and OpenGL ES 2.0 by translating OpenGL ES 2.0 invocations to DirectX 9 and 11. Their development notes also mention that an OpenGL ES 3.0 solution is in the works. Never having used ANGLE, I cannot offer a verdict.
OpenGL 3.1
In addition to those mentioned above, Mesa 3D (which supports up to OpenGL 3.1) feature three software implementations:
swrast
softpipe
llvmpipe
Since I know very little of swrast (the original Mesa project software rasterizer) and softpipe (a reference driver) I'll refrain from going into these. The third implementation, llvmpipe, and probably the one that may interest you the most, is a high-speed software implementation that uses multithreading and JIT compilation to speed up simulation with native- and SIMD instructions.
I have used Swiftshader from Transgaming for a production project before and I must say, it was brilliant. A tad costly, but brilliant.
As far as I've searched, the only other option is using WebGL software renderer, that as of today only Chrome supports. Direct3D has the reference driver (which is really unstable) and Swiftshader, which is good and expensive.
After some more headaches I managed to build Mesa3D for Windows, but only an old version which had still some support for it. At least, it has an awesome performance.
Recently I want to learn OpenGL ES. But I don't know which version should I learn.
I have tried OpenGL ES 2.0. You have to implement much functions that build-in OpenGL ES 1.0.
The Programmable Pipeline is trouble, despite it's powerful.
OpenGL ES 2.0 have been used in cocos2d 2.0.
Which version is widely in use?
Which one should I learn.
I'm a iOS developer.
As an iOS developer, you should probably allow yourself not to worry about devices on versions of the OS prior to iOS 5, meaning that you can really on Apple's GLKit to provide all the functionality that's in 1.1 but removed from 2.0. iOS device sales continue to grow exponentially and iOS 5 is available for devices from the 3GS onwards and so by the time you're up to speed you'll be losing very little in terms of potential audience.
GLKit supplies:
as many matrix stacks as you want (plus quaternions)
prepackaged shaders that match most of the ES 1.1 fixed functionality effects
standard bindings between OpenGL and UIKit (so you never need write your own UIView subclass for OpenGL again)
prebaked code for texture loading, synchronously and asynchronously
This is Apple's head documentation page for GLKit (and it's worth expanding the 'more'). iOS 5 and GLKit is quite new so external resources are still a little disorganised, but this one looks good enough.
Apple's intention is explicitly to allow someone who would otherwise stick with ES 1.1 because it does so much for you to get a working ES 2.0 implementation with very limited extra effort, with which they can then take advantage of the programmable pipeline in any way they see fit as they learn more about it. So I'd say that you should put your faith in Apple, take advantage of their code and learn ES 2.0 + GLKit right off the bat.
There're set of definition called "egl" in GLES 1.1: http://www.khronos.org/opengles/sdk/1.1/docs/man/
It's the "Native Platform Graphics Interface Layer":
http://www.khronos.org/opengles/
However, they're not in GLES 2.0: http://www.khronos.org/opengles/sdk/docs/man/
So I got some questions:
Is this a separated spec from GLES? Or a part of GLES1.1?
Where did they gone (in 2.0)? Or still exist (in 2.0)?
Where is the manual (guide)?
Should I manage eglContext in GLES 2.0 too?
EGL is a separate spec from OpenGL ES, it can manage contexts for OpenGL ES 1.0/1.1 and OpenGL ES 2.0 (and algo OpenVG), so it's not really gone.
The latest spec is here.
I think eonil was premature to accept the answer. Unless I am consistently missing things at the "latest spec" Valdenegro provided. For what I find there is that in order to choose the client API for the current context, one must use EGL_CONTEXT_CLIENT_VERSION, which is itself supported only in EGL 1.2, which is not on any Android phone I have seen: they are all EGL 1.1.
In EGL 1.0 or 1.1, you can only use the default client version, which is openGL ES.