OpenGL ES 3.0 support

[pem....@gmail.com]

What is the ETA on OpenGL ES 3.0 support for Emscripten?

( http://bit.ly/1Qjunsp ) says Emscripten supports OpenGL ES 2.0.  However, I see no mention of OpenGL ES 3.0?

As for OpenGL ES 2.0 support, apparently this means the WebGL-friendly subset of OpenGL + the ability to use glDrawArrays() without a bound buffer.  Does "without a bound buffer" mean without calling glBindBuffer()?

Why would you want to call glDrawArrays() without first calling glBindBuffer()?  Wouldn't that mean to draw nothing?

[Floh]

If you mean this sentence from the docs:

"This allows you to use glDrawArrays etc. without a bound buffer,..."

This simply means that you can render directly from a 'client-side' memory chunk with vertex-data instead of having the vertex data stored in a GL buffer, in this case glVertexAttribPointer is called with an actual pointer to the data, instead of an offset into a buffer). It may simplify porting some desktop-GL code, but is not recommended, since the GL shim needs to create and update a GL buffer under the hood.

The other possible meaning of rendering without a buffer would be 'attribute-less-rendering', where you don't provide any input geometry to the vertex shader, but instead use the generated vertex-id and/or instance-id to lookup vertex positions in an uniform array. Not sure if this is possible in WebGL though (see here: http://renderingpipeline.com/2012/03/attribute-less-rendering/)

Cheers,
-Floh.

[Pepijn Van Eeckhoudt]

> On 18 Sep 2015, at 05:52, pem....@gmail.com wrote:
>
> What is the ETA on OpenGL ES 3.0 support for Emscripten?

OpenGL ES 3.0 would have to map to WebGL 2.0 which isn’t finalised yet AFAIK. Not sure how much sense it would make to provide support for a spec that’s still in flux.

Best regards,

Pepijn

[Jukka Jylänki]

GLES 3 support code is landing to Emscripten in https://github.com/kripken/emscripten/pull/3757 and https://github.com/kripken/emscripten/pull/3782 . After those are merged, Emscripten should be able to compile GLES3 based code correctly (-s FULL_ES3=1 linker flag is needed to emulate a few features), but at the moment, we don't yet have a browser that would fully support WebGL 2 that could run the generated GLES 3 code. Firefox Nightly can run some WebGL 2 content if one configures the following prefs in about:config:

webgl.bypass-shader-validation: true

webgl.disable-angle: true

webgl.enable-draft-extensions: true

webgl.enable-prototype-webgl2: true

webgl.force-enabled: true

After those two PRs land, if you do have GLES3 codebases that generate a compiler error when compiled with Emscripten, please let us know. Also, even though we do know that WebGL 2 support is not yet complete, feel free to post bugs/experiences of attempted runs of GLES3/WebGL2 code (with those prefs enabled) and how far you got. They will definitely be useful.

Note that the above prefs cause problems with running WebGL 1 code at the moment, so when finished testing with WebGL 2 code, remember to revert back to the previous settings.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pem....@gmail.com]

@Floh: Consider this example code:

GLfloat verts_Init[] = {

-1.0f, 0.0f, 0.0f,

0.0f, 1.0f, 0.0f,

0.0f, 0.0f, 0.0f };

std::copy(verts_Init, verts_Init + 9, m_verts);

glBindBuffer(GL_ARRAY_BUFFER, m_idVBO[0]);

glBufferData(GL_ARRAY_BUFFER, 9*sizeof(GLfloat), m_verts, GL_STATIC_DRAW);

glVertexAttribPointer((GLuint)0, 3, GL_FLOAT, GL_FALSE, 0, 0); // (x, y, z) for pos

glEnableVertexAttribArray(0);

I'm calling glVertexAttribPointer() "with an offset into a buffer" right?  What's an example of calling glVertexAttribPointer() "with an actual pointer to the data"?

"don't provide any input geometry to the vertex shader" - interesting.  I see ( http://bit.ly/1F7vk83 ) shows an example where the vertex position is specified inside the vertex shader GLSL code instead of being passed in from C++ code.

@jj: I'm glad to hear this is being worked on.  I wonder if this has any relation to the fact that ANGLE does not yet fully support GLES3 since ANGLE is used by Chrome?

Anyone know the ETA on when there will be a reasonably robust/stable GLES3 support in Emscripten and a reasonably robust/stable WebGL 2 browser for the Emscripten-generated javascript to run?

---

[Jukka Jylänki]

Google for "client-side vertex arrays" to find an example of the legacy rendering mode. E.g. http://gamedev.stackexchange.com/questions/11438/when-to-use-vertex-array-and-when-to-use-vbo

Yes, there is work under way in ANGLE that is a prerequisite for stable implementation to ship in browsers. Following/asking in public-webgl mailing list may give a closer sense of where things are at. "By the end of this year" has been mentioned there a lot, but it is difficult to precisely estimate how well it goes.

[Floh]

You can basically rewrite your example like this and it should work on desktop GL (not sure if it works in Core Profiles though):

GLfloat verts_Init[] = {

-1.0f, 0.0f, 0.0f,

 0.0f, 1.0f, 0.0f,

 0.0f, 0.0f, 0.0f };

glBindBuffer(GL_ARRAY_BUFFER, 0);

glVertexAttribPointer((GLuint)0, 3, GL_FLOAT, GL_FALSE, 0, verts_Init); // (x, y, z) for pos

glEnableVertexAttribArray(0);

This behaviour is a nice example why OpenGL has become so confusing, because the same functions changed their behaviour over time. Note that the function is called glVertexAttrib*Pointer*, and the last attribute is of type 'const GLvoid*', even though current OpenGL docs say this is actually an offset, not a pointer (https://www.opengl.org/sdk/docs/man/html/glVertexAttribPointer.xhtml). 

If you look at the documentation of older GL version, it talks about the last parameter being a pointer, not an offset: http://docs.gl/gl2/glVertexAttribPointer

The function basically has been retconned into having 2 different behaviours, the pointer arg is either an offset or a direct pointer, depending whether a buffer is bound or not.

Cheers,

-Floh.

[Robert Goulet]

Here's a few issues I've noticed so far with WebGL2 in Firefox Nightly, latest Emscripten :

- Creating a texture format GL_RED, GL_RED_INTEGER, GL_RG or GL_RG_INTEGER doesn't error out, but using them for rendering using framebuffers fails (invalid framebuffer operations).

- Using GL_TEXTURE_WRAP_R parameter name in glTexParameteri returns invalid enum.

[Floh]

Oh dang, nevermind, I didn't notice the *2* after WebGL :)

Am Dienstag, 29. September 2015 20:48:37 UTC+2 schrieb Floh:

In general, even though emscripten tries to make porting GL code easy by emulating some features and calls of desktop GL, you can only rely on the OpenGLES2 feature set, since this is what WebGL is based on (plus optional WebGL extensions defined here: https://www.khronos.org/registry/webgl/extensions/)

For instance GL_TEXTURE_WRAP_R is for 3D textures, which are not supported on WebGL, and for uncompressed texture formats, you can only use a very small subset of what desktop GL allows (see here: https://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml).

Cheers,
-Floh.

[Robert Goulet]

Yep ;) I'm working on WebGL2.

Actually, a question...

does anyone know if multiple-render-targets (MRT) works in WebGL2? I was able to use them on WebGL1 using the WEBGL_draw_buffers extension, but I'm wondering if it currently works in Firefox Nightly WebGL2 (since it's supposed to not be an extension anymore) ?

[Jukka Jylänki]

MRT should work correctly in WebGL 2. There are some very recent changes I did in structuring the access to those entry points with the webgl2 pull requests, so you could try the latest Emscripten incoming to see if it works there.

As for the other errors, if you can make small test cases, I can help push attention to Firefox bugzilla and make sure they get some eyes from the graphics team.

Cheers,

   Jukka

[Robert Goulet]

Indeed, MRT works well, before and after your changes. I wasn't sure because it wasn't working in our game engine until I found the mistake. I'll try to prepare a small test case for the other issues.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Hai Nguyen]

Hi jj,

I'm working on a project that uses ES3 and I'm trying to make it work with Emscripten. I got the code base building with 'incoming'. I'm getting this error when I i try to set the version in the a GLSL shader:

VERTEX: #version, if declared, must be `100`.

In my shader source I do have:

#version 300 es

If I remove this line, the error changes to: error C5060: out can't be used with non-varying Color

Color is my out var:

out lowp vec4  Color;

This GLSL ES3 has been tested and used on Android, Linux and iOS. I'm running on NVIDIA hardware. Wondering if I'm missing something from my setup that could be causing this? 

Thanks,

Hai

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[キャロウ マーク]

> On Nov 29, 2015, at 3:42 PM, Hai Nguyen <coding...@gmail.com> wrote:
>
> Hi jj,
>
> I'm working on a project that uses ES3 and I'm trying to make it work with Emscripten. I got the code base building with 'incoming'. I'm getting this error when I i try to set the version in the a GLSL shader:
>
> VERTEX: #version, if declared, must be `100`.
>
> In my shader source I do have:
> #version 300 es
>

It seems like the OpenGL ES context at the bottom of the stack is 2.0. No idea what could be going wrong in Emscripten or your execution environment that it could, think it successfully obtained a WebGL 2 context yet apparently it really WebGL 1.

Regards

-Mark

[Hai Nguyen]

Hi Mark,

Thanks for the explanation. Very helpful. I just recently tested this on Canary Chrome as well. Pretty much the same exact issue. Was curious about how GLSL ES3 gets translated into GLSL WebGL2? I didn't realize that varying was still used in GLSL WebGL2. Perhaps that could be apart of the issue?

Hai

[キャロウ マーク]

> On Dec 1, 2015, at 3:56 AM, Hai Nguyen <coding...@gmail.com> wrote:
>
> Hi Mark,
>
> Thanks for the explanation. Very helpful. I just recently tested this on Canary Chrome as well. Pretty much the same exact issue. Was curious about how GLSL ES3 gets translated into GLSL WebGL2? I didn't realize that varying was still used in GLSL WebGL2.

Sorry for my lack of clarity. The bare “2.0” I mentioned referred to OpenGL ES 2.0 where, of course, GLSL 1.00 uses only varying and #version must be 100.

The answer to your question is, it is and it isn’t. WebGL 2.0/OpenGL ES 3.0 support both GLSL 1.00 and GLSL 3.00. If you are using GLSL 1.00 then “varying" must obviously still be used. However if you use GLSL 3.00 “varying" is an error and “in” or “out” must be used.

Regards

-Mark

[Hai Nguyen]

Thanks for the clarification. That was totally it. Based on what you said I was able to track down the problem to my context created by GLFW. I was missing a build flag to enable WebGL2: -s USE_WEBGL2=1. ES3 is up and running on Emscripten for me!

Hai