[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Removal of glTexImage3D entry point?

I agree that there are a lot of bad things in OpenGL that should not have been present in the first place. Still, I think it's premature if WebGL 2 working group starts calling these out before Khronos deprecates the functions on GLES3/Desktop GL land, which it has not done. For WebGL 2, parity and compatibility with GLES3 is critical, since there is a large number of native codebases that are looking at _javascript_+WebGL2 as a deployment platform. The proper procedure here should be first to get TexImage3D deprecated in desktop GL and GLES before these kind of decisions are made to WebGL.

2014-10-14 21:02 GMT+03:00 Kenneth Russell <kbr@google.com>:
You make good points about not arbitrarily subsetting OpenGL ES 3. The thought in the WebGL working group at the time was something along the lines of: it would have been far better if mutable texture allocation functions had not been present in the first place (far simpler texture validation logic, etc.); and since 3D textures were being newly introduced, there was an opportunity to avoid widespread usage of an undesirable entry point. (We considered dropping TexImage2D in WebGL 2, but that would have broken basically all applications.)

You're correct that it isn't simple to emulate TexImage3D on top of TexStorage3D and TexSubImage3D. However, one point is that it should not be difficult to change existing OpenGL ES 3.0 code to use TexStorage3D instead of TexImage3D. For the long term, it still might be a good idea to push developers in the direction of using the immutable allocation functions, and not providing TexImage3D in Emscripten's emulation layer.

More opinions please?



On Tue, Oct 14, 2014 at 5:19 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
I concur about the difficulty / impossibility of implementing texImage3D in full generality on top of just texStorage3D and texSubImage3D.

If the first texture image specification call on a texture is a texImage3D call with level=1 and width=3, then we can't know whether the level 0 image will have width 6 or width 7, which we need to know immediately in order to call texStorage3D.

In the short term, I'm hoping that the only application code that we have to worry about in the short term will always upload the level 0 image first. Then, we still have to assume that a mipmap will be wanted, but that's not a big deal because 1) the mipmap memory usage overhead for a cubic 3D texture is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the size of the level 0 image, and 2) when using texImage3D, a similar memory allocation problem is handed over to the OpenGL implementation anyway.

So I'm confident that for Emscripten we can do something that will support the majority of reasonable applications in the short term, but in the long term, it's unfortunate to have to give up implementing all of ES3. Think emscriptening test suites, etc. So while this isn't a short-term emergency, I think that if we stick to the removal of texImage3D, it's going to haunt us.



in the current form, WebGL 2 spec is planning to remove a GLES3 entry point it finds to be of "bad form" and use in modern code should be avoided. See https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and https://github.com/KhronosGroup/WebGL/issues/542

While one can agree that calling glTexStorage3D is of more modern form than calling glTexImage3D, I don't agree that it is correct that WebGL 2 should start deprecating/erasing API functionality on its own. Especially when reading the comments in the issue tracker, the rationale seems to not be technical, but only for cleaning and peace of mind purposes. However, these kind of changes would break existing GLES3 code that is compiled over to the web via Emscripten. Therefore I would recommend that WebGL 2 did not arbitrate API cleanups like this, unless the emulation path is a trivial one that can be documented in the spec itself. What do you think?