1245631 - WebGL: rendering to float texture fails in recent Nightly 47 on OSX

Status: RESOLVED DUPLICATE of bug 1233046

(Firefox :: Untriaged, defect)

Description

[Andre Weissflog]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160203030249

Steps to reproduce:

Rendering to RGBA32F textures stopped working in one of the recent Nightlies with framebuffer completion check failed on OSX, it still works fine on Windows.

To reproduce:

- on OSX (I have 10.11.4, mid-2014 13" MBP), with FF Nightly 47.0a1 (2016-02-03), navigate to http://floooh.github.io/oryol/GPUParticles.html, and http://floooh.github.io/oryol/TextureFloat.html, notice how the screen is largely black, and the text console beneath the GL canvas shows a warning that the frame buffer completeness check fails

- repeat the same in current public Firefox or any other browser, or on Windows and notice that the demos work fine (the first one should show a particle fountain, the second an animated, colored noise texture

Both demos create an offscreen frame buffer in RGBA32F format, render to it, and later sample from it either in the fragment, or vertex shader. But it is already the creation that fails with a frame buffer completion check.

The demos are emscripten-compiled, and the same GL/GELS2 code works fine on OSX, Linux, Windows, iOS and Android.

Comment 1

[Andre Weissflog]

PS: the GPU fractal rendering demo also stopped working, also has floating point offscreen framebuffers:

http://floooh.github.io/oryol/Fractal.html

Comment 2

[u480271]

Jeff,

Can you assign to best person to take a lot into this?

Comment 3

[Andre Weissflog]

I see that Nightly doesn't have the OES_texture_float extension anymore, only OES_texture_float_linear, but that shouldn't be the reason why the demos fail (first, they *do* check for _texture_float, but with a string-contains check, so that works by accident, and rendering to float frame-buffers should be implemented by WEBGL_color_buffer_float, right? But I remember some discussion/confusion around OES_texture_float and the later introduction of WEBGL_color_buffer_float which basically ended with that rendering to float framebuffers is implicitely handled by OES_texture_float because of some oversight early on (the oversight was that some mobile GPUs could sample from float textures, but not render to float framebuffers).

Comment 4

[Andre Weissflog]

PS: Reading the extension spec for those new texture_float_linear extensions (https://www.khronos.org/registry/gles/extensions/OES/OES_texture_float_linear.txt) I think dropping OES_texture_float and OES_texture_half_float seems to be a bug? The _linear extensions build on these and only add linear-filter capabilities as far as I understand the spec.

Comment 5

[Kelsey Gilbert [:jgilbert]]

As you've found, we regressed support for OES_texture_float on OSX. (bug 1233046)
It should work again as soon as that fix hits Nightly and other branches.

Checking the web console shows:
Error: WebGL: texImage2D: Invalid unpack format/type: 0x1908/0x1406
[...]
Error: WebGL: drawElements: Incomplete framebuffer: Status 0x8cd6: COLOR_ATTACHMENT0's image is not defined. (x31)
Error: WebGL: No further warnings will be reported for this WebGL context. (already reported 32 warnings)


(In reply to Andre Weissflog from comment #3)
> I see that Nightly doesn't have the OES_texture_float extension anymore,
> only OES_texture_float_linear, but that shouldn't be the reason why the
> demos fail (first, they *do* check for _texture_float, but with a
> string-contains check, so that works by accident, and rendering to float
> frame-buffers should be implemented by WEBGL_color_buffer_float, right?
WEBGL_color_buffer_float guarantees that you can use floating-point renderbuffers, and only that floating-point textures (if already available) become renderable.

> I remember some discussion/confusion around OES_texture_float and the later
> introduction of WEBGL_color_buffer_float which basically ended with that
> rendering to float framebuffers is implicitely handled by OES_texture_float
> because of some oversight early on (the oversight was that some mobile GPUs
> could sample from float textures, but not render to float framebuffers).

When enabling OES_texture_float, implementations may implicitly enable WEBGL_color_buffer_float if they support it.


(In reply to Andre Weissflog from comment #4)
> PS: Reading the extension spec for those new texture_float_linear extensions
> (https://www.khronos.org/registry/gles/extensions/OES/
> OES_texture_float_linear.txt) I think dropping OES_texture_float and
> OES_texture_half_float seems to be a bug? The _linear extensions build on
> these and only add linear-filter capabilities as far as I understand the
> spec.

I did notice this quirk (texture_float_linear supported without texture_float) when working on the texture_float regression. Functionally, this is fine, since it makes float-textures (if available) 'filterable'. Technically the _linear extension(s) 'require' the base extension(s). We can fix this explicitly, but it should never happen in practice. (it only happens right now because of a regression)

Comment 7

[Kelsey Gilbert [:jgilbert]]

Thanks for reporting this though!