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

Re: [Public WebGL] plugging floating point holes

On Fri, Aug 7, 2015 at 2:18 PM, Mark Callow <khronos@callow.im> wrote:
> On Aug 7, 2015, at 1:01 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>> We largely fixed this:
>> If OES_texture_float is enabled, you can make 32F textures, and sample from
>> them without filtering.
>> If OES_texture_float_linear is enabled, 32F textures may be filtered.
>> (sampled from with LINEAR)
>> if WEBGL_color_buffer_float is enabled, RGBA32F becomes a color-renderable
>> effective internal format for textures and renderbuffers. Also, RGBA/FLOAT
>> supplants RGBA/UNSIGNED_BYTE as the default supported format/type for
>> ReadPixel.
>> This same pattern works applies to half-floats as well.
>> Historically, it was pretty poorly specified, but we're in a better state
>> today. Implementations which do not match what I state above are not (I
>> believe) in compliance with the relevant extension specs.
> Agreed.

The specifications for these extensions are in good shape, but
unfortunately there aren't any conformance tests for them. The first
step toward widespread support for them would be for someone to
contribute WEBGL_color_buffer_float and EXT_color_buffer_half_float
tests that verify all of the assertions of the specs:

 - Fragment shaders' outputs are not clamped for FP color buffers
(this is already tested by WebGL's oes-texture-float.html conformance
 - clearColor's input is not clamped for FP color buffers
 -- corollary: if a value is passed to clearColor which is
out-of-range for fixed-point color buffers, it's clamped at draw time
for a fixed-point color buffer
 - Similarly, blendColor's values aren't clamped for FP color buffers
 - RGBA/FLOAT readback is supported for both FP16 and FP32 color buffers
 - RGBA/UNSIGNED_BYTE readback is disallowed for FP16 and FP32 color
buffers (note: this will break the existing oes-texture-float.html
test, so this behavior would probably have to be enabled only if
WEBGL_color_buffer_float/EXT_color_buffer_half_float are enabled)
 - etc.

It's great that Firefox has led the way in exposing these extensions.
The availability of thorough conformance tests would make it much
easier for the Chrome team to justify exposing them as well. My
opinion is that exposing the extensions -- implicitly stating their
guarantees -- but having those guarantees be potentially violated is
worse than the current situation where most of these behaviors are

> Specification-wise the only wrinkle is that WEBGL_color_buffer_float can’t
> be used to expose float32 rendering on OpenGL ES 3 devices supporting the
> native EXT_color_buffer_float, because the former requires that blending of
> float32 colors be supported and the latter requires they not be.  This is a
> problem because, when I asked within Khronos, only 2 vendors said they could
> support float32 blending on their OpenGL ES 3.x parts.
> I apologize for this wrinkle. When I wrote WEBGL_color_buffer_float my
> purpose was to provide a way for implementations to expose float32 rendering
> when running on desktop OpenGL. I, wrongly as it turns out, expected future
> OpenGL ES implementations to have the same float32 capabilities.
> I see  3 ways to fix this:
> Change WEBGL_color_buffer_float to remove support for float32 blending.
> Change WEBGL_color_buffer_float to add a flag that indicates if float32
> blending is supported
> Create a new extension, e.g, (horribly long name)
> WEBGL_color_buffer_float_no_blend
> Modify the WebGL version of EXT_color_buffer_float so that it can be applied
> to WebGL 1 implementations. I have not looked to see how much work this
> might be or what damage it might to the understandability of the extension.
> 1 and 2 are not acceptable by this groups processes as the spec. is already
> approved.
> There is a EXT_float_blend extension in proposals which can be used by WebGL
> 2 implementations to expose float32 blending and could also be used by WebGL
> 1 implementations if we choose #1 above. I’d like to propose moving that
> extension to Drafts so WebGL 2 implementations on desktop can start exposing
> it.

I strongly support moving the EXT_float_blend proposal to draft
status. I don't have an opinion about what to do about
WEBGL_color_buffer_float at this point. Again, having conformance
tests for it would be a strong motivator. If they were there I'd
probably vote for doing (1) -- removing support for FP32 blending --
and figure out what to do about the process side. If the working group
agrees to make the change then I don't see anything major blocking it
-- there's one implementation of this extension and it's untested.


> Regards
>     -Mark

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