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

RE: [Public WebGL] Proposal for WEBGL_render_to_float

I was not around when these extensions were proposed.  

However, it is true, at least on the Windows platform, that some hardware can support 16bit blendable render targets while others can only do non-blendable render targets.  The web page https://msdn.microsoft.com/en-us/library/windows/desktop/ff471324(v=vs.85).aspx (Hardware Support for Direct3D 10Level9 Formats) has tables that detail the restrictions.  Note that for 16bit floating textures, blendable render targets are only supported on FL9_3 and above, whereas non-blendable is supported on FL9_2 and above.  For 32bit floating point textures, only feature level 9_3 supports non-blendable render targets.  No blending is allowed on feature level 9_X.  Feature level 10+, of course, supports blendable 16 and 32 bit floating point textures.   

Floating point textures already have extensions that let you distinguish between "linear" and non-linear support with regard to shader sampling and mip maps.  Adding additional extension types for blended vs. non-blended render targets would increase the combinatorial gymnastics for developers.  Adding capability bits to existing or new extension types seems like the best way forward if we want to lift the blendability restriction.  


-----Original Message-----
From: owners-public_webgl@khronos.org [mailto:owners-public_webgl@khronos.org] On Behalf Of Kenneth Russell
Sent: Wednesday, February 18, 2015 3:38 PM
To: Florian Bösch
Cc: Jeff Gilbert; webgl, public
Subject: Re: [Public WebGL] Proposal for WEBGL_render_to_float

Jeff, thanks for putting together this extension proposal and uncovering more of the underlying issues.

It does seem to me that the number of extensions defining floating-point texture behavior in WebGL is getting out of hand, and that the limitations imposed by this proposal are too harsh. Let's discuss it in a higher-bandwidth format on the next working group conference call (tomorrow).

The discovery that
forbids blending when any of the color buffers are fp32 is correct, and surprising. Since https://www.khronos.org/registry/gles/extensions/EXT/EXT_color_buffer_half_float.txt
doesn't impose this restriction I would like to understand why that restriction is present, and whether it can be lifted.


On Wed, Feb 18, 2015 at 2:31 PM, 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.

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