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

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

This is excellent, thank you!

2014-10-19 1:30 GMT+03:00 John Davis <jdavis@pcprogramming.com>:

On Saturday, October 18, 2014, Kenneth Russell <kbr@google.com> wrote:
After discussion in the working group this week texImage3D has been added back to the spec: https://www.khronos.org/registry/webgl/specs/latest/2.0/ .


On Wed, Oct 15, 2014 at 4:29 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
It sounds like if we want to track GLES3, we should more closely do so, even if we disagree with components of it. Yes, it would be better if no one ever used texImage3d, but if we count soon-to-be-ported apps as 'existing code', then we unfortunately have a pretty good reason not to remove texImage3d.

----- Original Message -----
From: "Kenneth Russell" <kbr@google.com>
To: "Benoit Jacob" <bjacob@mozilla.com>
Cc: "Jukka Jylänki" <jujjyl@gmail.com>, "public webgl" <public_webgl@khronos.org>
Sent: Wednesday, October 15, 2014 4:02:16 PM
Subject: 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?


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