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

Re: [Public WebGL] Proposal for WEBGL_render_to_float



On Wed, Feb 18, 2015 at 12:13 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
I have proposed a more restricted extension for supporting render-to-float functionality:
https://github.com/KhronosGroup/WebGL/pull/867

Regardless of content I think it's getting kinda messy with the myriad of floating point extensions.

BLEND with floating-point is disallowed because of lack of support. EXT_color_buffer_float does not allow blending with float32s
That's quite a limitation because that is often the impetus to use floating point in the first place.
 
and D3D9 only supports normalized uint8 glBlendColor-equivalent.
You do not need glBlendColor to make effective use of say, additive blending to a floating point texture to accumulate a calculation.
 
clear() is disallowed because many implementations clamp clearColor, (driver bugs) and/or limit clearColor to normalized uint8 values. (D3D9. Notably, 0.5f is not representable in normalized uint8) WebGL implementations can work around this by doing a full-screen blit, but this is much more expensive, and current best-practice is to no longer hide performance caveats.
I believe that setting the viewport, setting a vertex attrib pointer, using a shader and calling draw is actually cheaper than calling glClear in pretty much all circumstances. And I was under the impression that gl.clear was shimmed to that anyway.
 
For textures, the initial contents can be set at upload-time. If there is strong support for floating-point clears on drivers that can't support the full WEBGL_color_buffer_float/EXT_color_buffer_half_float extensions, we can add an extension just for floating-point clears. (similar in nature to OES_texture_float_linear)
It's getting even more crowded with those extensions...
 
We could split this into WEBGL_render_to_float and WEBGL_render_to_half_float, but we should only do so if there are platforms or configurations which require this differentiation. (That is, FLOAT and HALF_FLOAT_OES textures are supported, but only one of the two is renderable)
Mobiles typically do not support rendering to float32 at all, but may support rendering to float16.


I'd like to add that I strongly disapprove of the mess this is getting, and I'd like to suggest that adding more and more extensions to cover float this-or-that seems like a bad thing to do. How about an extension to end all float extensions, that contains an interface that lets one query every imaginable aspect related to floating point textures?