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

Re: [Public WebGL] OES_texture_float_linear and OES_texture_half_float_linear extension proposals



On Thu, Mar 7, 2013 at 12:02 PM, Mark Callow <callow.mark@artspark.co.jp> wrote:

On 2013/03/07 19:43, Florian Bösch wrote:
On Thu, Mar 7, 2013 at 11:27 AM, Mark Callow <callow.mark@artspark.co.jp> wrote:
- For WebGL there can't be an implementation yet because those extensions are not in draft.
They are in draft and have been for many months.
They are not in draft. http://www.khronos.org/registry/webgl/extensions/ they are in "proposal". Proposal means: "Proposed extensions are intended for discussion on the public WebGL mailing list, in order to move to draft status; they should not be implemented"

They are in draft. I am talking about the {WEBGL,OES}_color_buffer_{half_,}float extensions. Those are intended to fix another issue with the texture_{half_,}float extensions where desktop implementations permit rendering in those formats leaving applications to try to guess whether it will work. No implementation has yet been changed to fix that problem despite the existence of draft specifications.

The color buffer extensions have no bearing on the texture filtering. Those are two unrelated sets of extensions. Color buffer concerns attaching single/half floating point textures to FBOs. single/half linear concerns texture filtering on texture2D lookups with those textures as samplers.

The threads question was for objections to move half_float_linear and float_linear to draft, not about the usefulness or state of color_buffer extensions.
 

Why will it be different this time?

Those are two sets of extensions that cover different functionality and different failure modes. The color buffer extensions are not relevant to the discussion on linear filtering. The best practice of assembling FBOs is to check for FBO validity, which will fail if the FBO does not support the single/half floating point color attachment. Being able to check for support without constructing an FBO and attaching a dummy texture is nice, but it is not an impeding issue.

Relying on linear filtering that may not be present *is* an impeding issue.

Regardless, the question does not matter. If you wish to discuss shortcomings of the color buffer extensions I suggest you fork it into its own thread.
 
At present I am simply trying to understand why this will work when the color_buffer fix has, so far, gained no traction.
I do not think that there is any merit to trying to infer the relevance of one set of extensions by the status of another set of extensions covering different functionality with different failure modes. Nevertheless, I will explain again why the half_float_linear and float_linear are important.

The problem is that we are relying currently on linear interpolation on floating point textures for a number of usecases which will break if it is not available. So the current status is that:
  • It will work on desktops
  • It breaks on mobiles
Clearly that is not desirable. So what options do we have to solve it and what are their respective drawbacks?

Option #1: Forbid linear filtering on floating point textures altogether
  • Pro: It solves the reliance problem
  • Contra: It breaks every single use of floating point textures that rely on linear filtering,
  • Contra: It offers no simple fix
  • Contra: It degrades everybodies performance by requiring manual linear filtering re-implementation
  • Contra: The fix (manual linear interpolation) is difficult
Option #2: Leave everything as it is
  • Pro: Things work on desktops
  • Contra: does not solve the reliance problem
  • Contra: mobiles are broken
Option #3: Support half_float_linear but do not deprecate linear interpolation on single precision floating point textures.
  • Pro: solves the reliance problem for half_float
  • Contra: does not solve the reliance problem for float
  • Contra: mobiles are broken
Option #4: Support half_float_linear and deprecate linear interpolation on single precision floating point textures
  • Pro: solves the reliance problem
  • Contra: It breaks every single use of floating point textures that rely on linear filtering
  • Contra: It offers no simple fix for single precision floating point textures
  • Contra: It degrades the performance of usecases that need single precision floating point linear interpolation
  • Contra: The fix (manual linear interpolation) is difficult
  • Contra: offers no fallback for hardware supported linear interpolation for desktop drivers incapable of half-float support
Option #5:  Support half_float_linear and float_linear and deprecate implied linear interpolation on all floating point textures
  • Pro: solves the reliance problem
  • Pro: offers a simple fix for everybody
  • Pro: does not degrade performance if hardware supported filtering is available
  • Pro: offers a seamless fallback from single precision floating point to half precision floating point
  • Contra: breaks every single use of floating point textures that rely on linear filtering
Clearly I prefer the solution with the least drawbacks, that offers the most viable way to fix an issue we have, that offers people simple fixes to address it as well as options to fall back on on mobiles. You clearly seem to prefer things just being broken. Make your pick.