[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 Wed, Apr 1, 2015 at 7:33 AM, Mark Callow <khronos@callow.im> wrote:
> 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}.

Mark, thank you for getting to the bottom of these issues. It must
have been a lot of work to figure out all of these corner cases.

> 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.

The WebGL conformance suite could (and should) add tests for these, at
least once EXT_color_buffer_float is supported in WebGL 2.0

> 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.

It would be great if you'd draft a WebGL wrapper for EXT_float_blend.
We need to nail down this behavior once and for all in the WebGL 2

> 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.

I think this has gone unnoticed. I checked Chromium's issue tracker
and there are no bugs filed about the clamping of arguments to
ClearColor, etc. Chromium's WebGL implementation does do some checks
before enabling the floating-point rendering extensions but doesn't
currently check to see that clear colors are unclamped. I'm not sure
how we would safely determine how many GPUs are affected by the
clamping issue. It seems more practical to restrict WebGL 2's
color_buffer_float extensions to only run on OpenGL implementations
that don't perform this clamping, but I'd be very concerned about
breaking high-profile WebGL 1 content that doesn't actually care
whether these values are clamped or not.


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl