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

Re: [Public WebGL] Proposal for WEBGL_render_to_float

Clear() is faster than doing a rasterization pass, and is effectively free on many drivers. (basically all tilers) If Clear() weren't cheaper, the driver would implement it as a rendering pass.

In practice, I don't think we need a huge list of these extensions. I'm just trying to get us to a sane point regarding what people believe is implementable for rendering-to-float as historically implied by OES_texture_[half_]float.

Firefox is going to expose both color_buffer extensions on many drivers, but notably we cannot support these on D3D9.

On Wed, Feb 18, 2015 at 6:31 AM, Florian Bösch <pyalot@gmail.com> wrote:
On Wed, Feb 18, 2015 at 3:15 PM, Florian Bösch <pyalot@gmail.com> wrote:
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?

I'd like to elaborate a bit on that point.

So far we have no less than 7 extensions that deal with floating point textures:

- OES_texture_float
- OES_texture_half_float
- OES_texture_float_linear
- OES_texture_half_float_linear
- EXT_color_buffer_half_float
- WEBGL_color_buffer_float
- EXT_color_buffer_float (fair bit of overlap with the former two, except blending)

And now the suggestion is to add 2 more (bringing it to 9):

- WEBGL_render_to_half_float
- WEBGL_render_to_float

But because these don't cover clearing we're talking about adding 2 more (for a total of 11)

- WEBGL_clear_half_float
- WEBGL_clear_float

Of course these don't cover blending, which may further differentiate into blendFunc and blendColor, so we'd be adding 4 more (for a total of 15)

- WEBGL_blend_func_half_float
- WEBGL_blend_func_float
- WEBGL_blend_color_half_float
- WEBGL_blend_color_float

I suppose there could be further implementation differences requiring even more extensions.

I think this is a problem for several reasons:

1) It makes handling floating point textures messy for users because some of these extensions overlap in functionality, others, in some circumstances implicitely enable each other, etc.
2) It makes handling floating point textures messy for implementors because following the rules imposed by multiply-overlapping-implicitely-enabling extensions on the implementation behavior becomes quite the exercise.

I believe it would be better to have one extension, that covers everything related to floating point textures and offers its own interface to deal with them. It would offer:

- All the floating point enumerants
- Flags indicating a capability (such as extension.float32.blendable)
- If that's desired it could offer float-versions of functions such as clear, blendFunc, blendColor, readPixels, etc.