On 22 March 2017 at 17:12, Florian Bösch <firstname.lastname@example.org> wrote:Having looked supporting different formats for rendering to and sampling from, I'd like to share my observations.Extensions are claimed that are not supportedOn iOS the implementation claims to support OES_texture_float_linear but this does not actually work and it defaults (silently) to nearest.Could you please submit a conformance test verifying this behavior?
Float16Array still does not existIt's still a major pain to deal with generating data to upload to Half-Float textures because despite repeated prodding on the ECMA-ML as well as here, we still don't have a Float16Array.Can't help with this. Sorry.
Some implementations do not accept Uint16Array upload to half-float texturesSafari and iOS refuse to accept an array for texImage2D to upload to half-float textures. Even though it's now in the specification that this is permissible. We talked about this. It was agreed we would allow that.I confirm that Safari on macOS is failing https://www.khronos.or
g/registry/webgl/sdk/tests/con. Please confirm that it's failing on iOS and file a bug on bugs.webkit.org. formance/extensions/oes-textur e-half-float.html
Setting linear blending mode on textures that don't support it generates no errorThe UA complains about an unrenderable texture when you draw sampling from it, so it knows that the blending mode isn't supported. But you can't get an error from it either at texParameter or draw*. This is extremely awkward, because apparently (see above) the linear extensions have no meaning whatsoever, so you have to actually draw to figure out if blending works and then readback the results. If you (the UA) already knows that linear doesn't work, please don't make developers integrate a unit test to figure it out?Please file an issue about this on https://github.com/KhronosG
roup/WebGL. The browser vendors can discuss making this change.
The color_buffer extensions have no meaningPlatforms (such as Chrome) that support drawing to floating point textures do not expose these extensions, leaving you no choice but to getExtension it and then promptly ignore anything you got and test if you can actually construct an FBO that is indicated as valid and draw to it and then read the drawn texture (trough another FBO because see blow).This behavior is much clarified and simpler in WebGL 2.0. There's only one extension: EXT_color_buffer_float, and it provides a strong guarantee about renderability without adding a lot of feature detection code to the WebGL implementation itself and impacting startup time of all WebGL apps. Please try WebGL 2.0. If you see issues in this area in that version then please file bugs.
readPixels of floats may or may not workSome platforms do not implement readPixels from a floating point texture. Some do. Because of that, you can't directly test some of the more interesting properties of floating point textures (such as blending, filtering, clamping, etc.) but you have to do it trough a proxy unsigned byte FBO because you can't rely on readPixels.This should again be much clarified in WebGL 2.0 and there should be strong guarantees about readPixels' behavior there.
Some devices do not expose floating point textures even though they support themFor reasons that completely boggle me, the fairly new Samsung S7 (just a year old) which has perfectly fine and working support for a variety of floating point textures/operations do not expose that to WebGL (by some combination of unlucky ES config and whatnot). That's a fairly big problem. Because samsung devices are fairly popular, it means floating point support on mobiles is actually retrograde, mean reverting slowly back to somewhere anno 2012 or so.We just tested Chrome Dev on a Samsung Galaxy S7 Edge and it passes the render-to-RGBA-texture portion of https://www.khronos.org/reg
istry/webgl/sdk/tests/conforma. (RGB textures are not renderable.) It also seems to support EXT_color_buffer_float for WebGL 2.0. If you have a scenario on a newer device like this where render-to-FP-texture is not working at all then please file a bug. nce/extensions/oes-texture- float.htmlIf you're trying to save memory, then rendering to R32F and RG32F textures is available as of WebGL 2.0.
The only qualifier I can find for the situation is miserable and utterly broken. It's hurting WebGL. It should be addressed. It should have been addressed long ago, and most of these things came up in the past years at one point or another. I don't understand why they are not addressed.WebGL 2.0 should solve many longstanding issues with rendering to floating-point textures. It's supported in Firefox on Android now and will be in Chrome 58 on Android. Please help us make sure that these issues are addressed in the most recent version, and we can work on backporting some of the fixes to WebGL 1.0 + extensions.