At the moment I get a OOM error when sampling a GL_R32F texture using a sampler2D in a compute shader on a Samsung S6. (It works on Tegra K1). I get this error:
GLES-MALI OOM error: execution failed (gles_drawp_call_finish at hardware/samsung_slsi/MaliT760_r5p0_05dev2_Istor/drivers/product/gles/src/draw/mali_gles_draw_internal.c:143)
Is this a known problem? (Or is the format the root cause of this at all?)
Regards,
Tom
Hi Tom,
> In the case where I define GL_R32F with glTexStorage2D, texelFetch does not work and gives me a vec2(0.0,0.0,0.0,0.0).
Obtaining black is the standard response on Mali to an incomplete texture. The R32F format is not texture filterable in the OpenGL ES core specification (see the OpenGL ES 3.1 Spec, table 8.13), so only GL_NEAREST filtering is supported on Mali for this format type. Even though texelFetch is not filtered, there isn't really an exception from the completeness check for this case in the specification. In fact the completeness check is explicitly required; section 11.1.3.2 Texel Fetches in the 3.1 specification says:
The results of the texel fetch are undefined if any of the following conditions hold: <snip> the texture being accessed is not complete, as defined in section 8.16.
The results of the texel fetch are undefined if any of the following conditions hold:
Hopefully if you swap this out to GL_NEAREST it should then work.
Our best guess is that the Tegra platform is supporting the OES_texture_float_linear extension, which we do not support currently.
> texture() is even more erratic
Is it possible for you to share a cut-down reproducer, or at least the shader which is going wrong? It's hard to tell precisely what you are trying to do here from the description.
Pete
Hi Pete,
thanks for the good reference explaining the behaviour of texelFetch. What I referred to as erratic behaviour of sampling with texture() turned out to be related to texelFetches outside of an image's dimensions - so all is solved here! Thanks.
Great, glad you got it sorted.