error when creating a webgl context with RGB format

[Lidwine Genevet (lgenevet)]

Hi,

 

I am trying to run a webgl application on content_shell on a new set top box platform. I encounter an issue on some webgl pages.

The error is :

[gles2_cmd_decoder.cc(3652)] GLES2DecoderImpl::ResizeOffscreenFrameBuffer failed because offscreen FBO was incomplete.

 

I observed that the issue appears when a webgl context is created without alpha property.

It happens on javascript call of type :  " l = O.getContext("webgl", Attributes) ."

 

On BackFramebuffer::AttachRenderTexture , glFramebufferTexture2DEXT seems to make the error to be raised.

It looks like the association of an offscreen buffer created in RGB can not be binded to my native platform via glFramebufferTexture2DEXT, whereas there is no problem with a buffer created with RGBA.

 

- The issue happens for example with http://threejs.org/examples/webgl_buffergeometry.html : a black page is displayed.

- If I modify the page source to give "alpha=1" in the "Wc" context (l = O.getContext("webgl", Wc) ;), there is no issue.

- The GPU is an embedded GPU in a SetupBox and is a MALI 400 from ARM.

- Content_shell is launched with --ignore-gpu-blacklist option.

- Behaviour observed on versions based on 37,38 and 39.

Is this behaviour is known on some platforms ? I tried to check gpu_driver_bug_list, but was not able to find something related.

Is there any kind of fix/workaround ? Or any clue to help the investigation?

Thanks,

Lidwine

[Antoine Labour]

WebGL doesn't use the "default framebuffer" created by GLES2DecoderImpl::ResizeOffscreenFrameBuffer - and hasn't for a long time.

I suspect we're still creating one (e.g. 1x1), and possibly passing flags from the context creation attributes, from the time when we did... It should be possible to avoid doing, or at the very least to default to a good known state.

That said, I think this is a driver bug. Attaching RGB textures should be fine.

Antoine

[Olli Etuaho]

Actually, not supporting RGB textures as framebuffer attachments is allowed by GLES2.0 spec. GLES2.0 implementations are allowed to choose just one texture attachment format that they support (section 4.4.5). If a driver only supports RGBA, it's not a driver bug as such. To investigate this, you could make a simple native OpenGL app that creates an RGB FBO and see if that succeeds. I don't think that Chromium currently has code to handle the case where RGB is not natively supported, so if RGB FBO attachments are not supported WebGL will fail like this. You could file a Chromium bug about this.

-Olli

[Lidwine Genevet (lgenevet)]

Hi,

 

Thanks for your answers, and reference to the specs chapter.

 

I did some unit tests which seem to confirm that the driver does not support “RGB” as frame buffer attachment. I will run more tests to confirm. Do you know if there may be a way from the drivers to know if the format is supported?

 

Thanks,

Lidwine

 

De : Olli Etuaho [mailto:oet...@nvidia.com]
Envoyé : vendredi 9 janvier 2015 14:06
À : graphi...@chromium.org
Cc : Lidwine Genevet (lgenevet); chromi...@chromium.org; k...@chromium.org; z...@chromium.org
Objet : Re: error when creating a webgl context with RGB format