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

RE: [Public WebGL] Proposal for WEBGL_render_to_float



Removing the support for blending is an unfortunate regression. That means use cases that need blending need to switch to ping-ponging between two framebuffers, and that eats up a lot of performance. On an app I've developed a path that uses blending to floating-point framebuffers is 2x as fast as a path that uses switching framebuffers. Maybe blending to floating point framebuffers could be exposed as a separate extension, which could also be made available on WebGL 2?


I don't agree with that clear() should be disallowed. Driver bugs can and should be fixed, and needing a workaround on D3D9 which is slowly getting phased out doesn't seem like enough of a reason to make this basic operation hard to do in WebGL.


-Olli


From: owners-public_webgl@khronos.org <owners-public_webgl@khronos.org> on behalf of Jeff Gilbert <jgilbert@mozilla.com>
Sent: Wednesday, February 18, 2015 1:13 AM
To: webgl, public
Subject: [Public WebGL] Proposal for WEBGL_render_to_float
 
I have proposed a more restricted extension for supporting render-to-float functionality:
https://github.com/KhronosGroup/WebGL/pull/867

>From the pull request:
---
This might be a more portable way to allow render-to-float behavior in WebGL. It's more restricted than WEBGL_color_buffer_float or EXT_color_buffer_half_float. It's implementable everywhere that supports render-to-float, including D3D9.

BLEND with floating-point is disallowed because of lack of support. EXT_color_buffer_float does not allow blending with float32s, and D3D9 only supports normalized uint8 glBlendColor-equivalent.

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.

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)

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

This should be able to address the concerns about supporting render-to-float without meeting the requirements of the actual render-to-float extensions.