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

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



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.

Benoit


Hi,

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?

   Jukka