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

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



This is a good point. Thanks for catching it. It looks like the RED format is the preferred way to get a single-channel texture going forward, but switching to that format requires updating shaders, or using texture swizzling -- and if the application's using texture swizzling, that would require significant bookkeeping behind the scenes.

Since there hasn't been any other feedback from WebGL implementers, I'll bring up this topic on the next working group conference call.

Out of curiosity is it not feasible to ask the developer of this application to update it to not use this deprecated texture format?

-Ken


On Wed, Oct 15, 2014 at 3:31 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
I just ran into another, maybe deeper problem with the removal of texImage3D: if my understanding of the spec is correct, it removes functionality.

I have an OpenGL ES 3 application that uses a 3D texture with ALPHA format. Is there any way to get that with texStorage3D? texStorage3D only accepts sized internalformats (indeed, it does not take a type parameter, so an unsized internalformat would remain ambiguous). But there is no sized internalformat value for any ALPHA format in the spec: ALPHA8, ALPHA16F and ALPHA32F are not listed among valid sized internalformats anywhere in the ES3 spec (e.g. Table 3.2). Moreover, at least ALPHA8 is explicitly described as a dummy effective internalformat not corresponding to any GLenum constant, in the ES3 spec (Table 3.2).

The same issue also with LUMINANCE_ALPHA.

I understand that ALPHA and LUMINANCE_ALPHA textures are deprecated, but does there exist any reasonably simple, automatic porting path for ES3 applications relying on them? Something that would be reasonable to implement in a place like Emscripten's OpenGL-to-WebGL layer?

Benoit


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?

Thanks,

-Ken



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.

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