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

Re: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float




On Mar 19, 2015, at 5:10 PM, Florian Bösch <pyalot@gmail.com> wrote:

On Tue, Feb 10, 2015 at 4:10 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Tue, Feb 10, 2015 at 4:05 PM, Kenneth Russell <kbr@google.com> wrote:
If it turns out that because of Mozilla's work it's trivial to expose
these extensions in other WebGL implementations, we'll consider doing
so in Chrome.
That's excellent news. I will withdraw both proposals (for moving back to draft or rejection) if this turns out to be the case. 
Any update on the progress of this?

Through archaeology in the Khronos records and consultations with members we have verified the situation with regards to support of various float-related features in native OpenGL {,ES}.

That EXT_color_buffer_float does not support blending with float32 color buffers is a deliberate decision traceable back to the final agreed list of features for OpenGL ES 3.x. Note that linear filtering of float32 textures is also unsupported in 3.x. Two mobile-GPU vendors have said they have parts or IP that supports float32 blending so Khronos has now created an EXT_float_blend extension to expose this feature.  Those two vendors have said they will support it. The existing OES_texture_float_linear extension had already been updated with interactions with OpenGL ES 3.x and is the way linear filtering is exposed.

That some OpenGL implementations are reportedly clamping the parameters passed to BlendColor, ClearColor and ClearDepth likely results from the spec using the clampf type for these parameters. This is a spec bug and is not the intended behavior. The bug was introduced when ARB_color_buffer_float was folded into the core spec. It was finally fixed in an updated OpenGL 4.2 specification released April 27th, 2012. As far as I can see there is no conformance test for this.

Note too that floating-point textures cannot be created in ES 3.x with unsized internal formats (i.e. format == internalformat && (type =  FLOAT || type == HALF_FLOAT)). This is because unsized internal formats are deprecated. Those included in ES 3.x are only there for compatibility with ES 2 and since FP textures were ES2 extensions, it was felt compatibility was not needed. This means the WebGL 1 extensions can’t be applied to WebGL 2.

For WebGL 2 FP color buffer functionality can be exposed with EXT_color_buffer_float and EXT_float_blend. There is no WebGL wrapper yet for the latter. I’ll be happy to draft one, if we are in agreement. Linear filtering of float32 textures can be exposed with OES_texture_float_linear.

The clamping problem affects both WebGL 1 and WebGL 2 implementations running on certain OpenGL implemenations. The simplest answer is to say that the FP color buffer extensions are not exposed in this case. So the vital question is what percentage of users are affected.

It is important to realize that this clamping problem affects those implementations currently implicitly enabling FP rendering via OES_texture_{,half_}float so it is not by itself a reason to reject the subject extensions. One of four things must be happening: (1) the WebGL implementation is raising FRAMEBUFFER_INCOMPLETE when on an affected OpenGL implementation; (2) nobody is noticing the clamping; (3) affected implementations have bugs filed against them about this problem; or (4) people notice but don’t find it important enough to file a bug.

Are any implementations doing 1? Do any implementations have open bugs about the clamping? The answers should help us decide if not exposing any FP rendering in the presence of the clamping is a viable choice.

Regards

    -Mark


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail