Open Bug 606794 Opened 15 years ago Updated 3 years ago

ASSERTION: Error setting up framebuffer.: 'mGLContext->fCheckFramebufferStatus(LOCAL_GL_FRAMEBUFFER) == LOCAL_GL_FRAMEBUFFER_COMPLETE'

Categories

(Core :: Graphics, defect)

ARM
Maemo
defect

Tracking

()

People

(Reporter: romaxa, Unassigned)

References

Details

Attachments

(2 files, 3 obsolete files)

I'm using latest trunk (mc:a2f52283e534) + cjones mcmq[400:f9db15e5e074] + patch from https://bugzilla.mozilla.org/attachment.cgi?id=482017&action=edit (EGL image fallback) and have this error: Extensions: EGL_KHR_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_vg_parent_image EGL_NOKIA_texture_from_pixmap 0x45 Extensions length: 158 Initializing context 0x487912c0 surface (nil) on display 0x2 GL extensions: GL_OES_rgb8_rgba8 GL_OES_depth24 GL_OES_vertex_half_float GL_OES_texture_float GL_OES_texture_half_float GL_OES_element_index_uint GL_OES_mapbuffer GL_OES_fragment_precision_high GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image GL_EXT_multi_draw_arrays GL_IMG_shader_binary GL_IMG_texture_compression_pvrtc GL_IMG_texture_stream2 GL_IMG_texture_npot Found extension GL_OES_depth24 OpenGL vendor recognized as: <other> ........................ ###!!! ASSERTION: does it make sense to Resize() a disabled or hidden widget?: 'mEnabled && mVisible', file widget/src/xpwidgets/PuppetWidget.cpp, line 182 ###!!! ASSERTION: does it make sense to Resize() a disabled or hidden widget?: 'mEnabled && mVisible', file widget/src/xpwidgets/PuppetWidget.cpp, line 182 GL ERROR: 0x0501 at gfx/layers/opengl/LayerManagerOGL.cpp:559 ###!!! ASSERTION: Error setting up framebuffer.: 'mGLContext->fCheckFramebufferStatus(LOCAL_GL_FRAMEBUFFER) == LOCAL_GL_FRAMEBUFFER_COMPLETE', file gfx/layers/opengl/LayerManagerOGL.cpp, line 905 GL ERROR: 0x0501 at gfx/layers/opengl/LayerManagerOGL.cpp:910 GL ERROR: 0x0506 at gfx/layers/opengl/ThebesLayerOGL.cpp:711 GL ERROR: 0x0506 at gfx/layers/opengl/ThebesLayerOGL.cpp:110 ###!!! ASSERTION: Error setting up framebuffer.: 'mGLContext->fCheckFramebufferStatus(LOCAL_GL_FRAMEBUFFER) == LOCAL_GL_FRAMEBUFFER_COMPLETE', file gfx/layers/opengl/LayerManagerOGL.cpp, line 905 GL ERROR: 0x0501 at gfx/layers/opengl/LayerManagerOGL.cpp:910 GL ERROR: 0x0506 at gfx/layers/opengl/ThebesLayerOGL.cpp:711 GL ERROR: 0x0506 at gfx/layers/opengl/ThebesLayerOGL.cpp:110 ................................................ Any ideas why it happen?
aah, I'm using Qt build on Maemo5. and opening MOZ_ACCELERATED=1 ./fennec -url file:///usr/share after this run device in ~95% cases need reboot, because driver dead after launching mozilla
OS: Linux → Maemo
Hardware: x86 → ARM
UI rendered, content not rendered. about:license page rendered somehow, but device dead almost immediately after that... Also with about:license page (local page) those GL errors not reproducible anymore
Tested on latest GTK maemo5 with MOZ_ACCELERATED=1 enabled ************************************* 5 0x40a94adc in mozilla::gl::GLContext::fCheckFramebufferStatus (this=0x48e1dc00, target=36160) at ../../../dist/include/GLContext.h:1822 #6 0x4177a554 in mozilla::gl::GLContext::SetBlitFramebufferForDestTexture (this=0x48e1dc00, aTexture=2450035) at gfx/thebes/GLContext.cpp:1684 #7 0x4177a838 in mozilla::gl::GLContext::BlitTextureImage (this=0x48e1dc00, aSrc=0x4a239520, aSrcRect=..., aDst=0x48e4f040, aDstRect=...) at gfx/thebes/GLContext.cpp:1190 #8 0x417b1028 in mozilla::layers::BasicBufferOGL::BeginPaint (this=0x4d894d30, aContentType=145) at gfx/layers/opengl/ThebesLayerOGL.cpp:432 #9 0x417b1824 in mozilla::layers::ThebesLayerOGL::RenderLayer (this=0x46fb7f80, aPreviousFrameBuffer=0, aOffset=...) at gfx/layers/opengl/ThebesLayerOGL.cpp:548 #10 0x417a59f4 in mozilla::layers::ContainerLayerOGL::RenderLayer (this=0x46362aa0, aPreviousFrameBuffer=0, aOffset=...) at gfx/layers/opengl/ContainerLayerOGL.cpp:253 #11 0x417ab7c8 in mozilla::layers::LayerManagerOGL::Render (this=0x48b8bb40) at gfx/layers/opengl/LayerManagerOGL.cpp:605 #12 0x417ac1d0 in mozilla::layers::LayerManagerOGL::EndTransaction (this=0x48b8bb40, aCallback=0x407068fc <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*)>, aCallbackData=0xbefde1f8) at gfx/layers/opengl/LayerManagerOGL.cpp:421 #13 0x407431c8 in nsDisplayList::PaintForFrame (this=<value optimized out>, aBuilder=0xbefde1f8, aCtx=<value optimized out>, aForFrame=<value optimized out>, aFlags=3204309440) at layout/base/nsDisplayList.cpp:495 #14 0x407434f4 in nsDisplayList::PaintRoot (this=<value optimized out>, aBuilder=0x0, aCtx=<value optimized out>, aFlags=<value optimized out>) at layout/base/nsDisplayList.cpp:402 #15 0x40763e24 in nsLayoutUtils::PaintFrame (aRenderingContext=0x4, aFrame=0x479306d8, aDirtyRegion=..., aBackstop=1153673248, aFlags=0) at layout/base/nsLayoutUtils.cpp:146 *************************************
Ok problems here is because of Texture Resize seems does not do exactly what blit functionality expecting... *********************************** // a) Create texture ID GLuint texture; glGenTextures(1, &texture); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, texture); // b) Bind to X-Pixmap Pixmap pixmap = createNew16BppX-Pixmap; khrimage = eglCreateImageKHR(dpy, EGL_NO_CONTEXT, EGL_NATIVE_PIXMAP_KHR, pixmap, NULL); glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, khrimage); // c) Bind framebuffer to texture glGenFramebuffers(1, &mBlitFramebuffer); glBindFramebuffer(GL_FRAMEBUFFER, mBlitFramebuffer); glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0); if (glCheckFramebufferStatus(LOCAL_GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE) { printf("EERRRORRR\n"); } *********************************** with this code we always have error printed... If I call between a) and b) glTexImage2D (...., size), still have EERRRORR If I call between b) and c) glTexImage2D (...., size), I don't have error, but texture seems disconnected from pixmap, and lock/unlock does not work anymore... If I replace b) with glTexImage2D (...., size), and do work with glTexImage2D only , then everything works fine.. (same as no backingSurface code)
Blocks: 625939
Answer from Nokia Graphics drivers developers: ************************************ I think the error you are getting is being triggered here. The problem is that the driver does not support making a connection through EGLImage => texture => framebuffer object. Instead, you should skip the texture completely and bind the EGLImage to a renderbuffer instead: glGenRenderbuffers(1, &renderbuffer); glBindRenderbuffer(GL_RENDERBUFFER, renderbuffer); glEGLImageTargetRenderbufferStorageOES(GL_RENDERBUFFER, image); glGenFramebuffers(1, &mBlitFramebuffer); glBindFramebuffer(GL_FRAMEBUFFER, mBlitFramebuffer); glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, renderbuffer); ************************************
adding myself
Attached patch use rbo to blit (obsolete) — Splinter Review
Here's a first somewhat working version. I delete the texture before attaching a renderbuffer to the image, maybe this isn't really necessary. Also, sometimes I get black regions.
this doesn't show the black bars and at least buffers the eglImage between rbo creation and destruction
Attachment #504701 - Attachment is obsolete: true
Nokia driver guys tell me you can have *both* a Texture and a Renderbuffer attached. This gives this simplified patch. I can sometimes trigger a segfault maybe a race condition to be solved with a EGL fence. Program received signal SIGSEGV, Segmentation fault. gfxContext::gfxContext (this=0x438d0a90, surface=0x0) at /home/fhae/upstream/mozilla-central/gfx/thebes/gfxContext.cpp:64 64 /home/fhae/upstream/mozilla-central/gfx/thebes/gfxContext.cpp: No such file or directory. in /home/fhae/upstream/mozilla-central/gfx/thebes/gfxContext.cpp (gdb) bt #0 gfxContext::gfxContext (this=0x438d0a90, surface=0x0) at /home/fhae/upstream/mozilla-central/gfx/thebes/gfxContext.cpp:64 #1 0x3bdaaf48 in mozilla::gl::TextureImageEGL::BeginUpdate (this=0x451e9d00, aRegion=...) at /home/fhae/upstream/mozilla-central/gfx/thebes/GLContextProviderEGL.cpp:1099 #2 0x3bdcc3e8 in mozilla::layers::BasicBufferOGL::BeginPaint (this=<value optimized out>, aContentType=<value optimized out>) at /home/fhae/upstream/mozilla-central/gfx/layers/opengl/ThebesLayerOGL.cpp:463
Attached patch delete rboSplinter Review
This fixes crashes for me - apparently you run out of memory after some time because we create and destroy eglImages constantly during scrolling and I didn't delete the renderbuffer object.
Attachment #504735 - Attachment is obsolete: true
Attachment #505036 - Attachment is obsolete: true
Attachment #505794 - Flags: feedback?(jmuizelaar)
I've tested it on Maemo5 and it does not work, because HasKHRImageTexture2D and HasKHRImagePixmap - false there... I think we should do something in Else condition
I put this into BlitTextureImage and it seems to look okay: nsRefPtr<gfxASurface> s = aSrc->GetBackingSurface(); nsIntRegion dReg(aDstRect); //might be modified by beginupdate nsRefPtr<gfxASurface> d = aDst->BeginUpdate(dReg); d->DumpAsDataURL(); nsIntRect dRect=dReg.GetBounds(); nsRefPtr<gfxContext> ctx = new gfxContext(d); gfxUtils::ClipToRegion(ctx, nsIntRegion(dRect)); nsIntPoint o=aDstRect.TopLeft() - aSrcRect.TopLeft(); ctx->SetSource(s, gfxPoint(o.x,o.y)); ctx->SetOperator(gfxContext::OPERATOR_SOURCE); ctx->Paint(); aDst->EndUpdate(); return; fennec looks weird on my n900 even without the patch, I get stray white or black pixels almost everywhere. Also it is quite slow, no Idea whats up with that. What do you think? This is basically a software blit, right?
Attached patch rebasedSplinter Review
This is just the same patch, rebased against current mozilla-central
I am getting the same error on a Nexus S, so there is a non-Nokia-specific problem around here. See bug 628566 comment 20.
Just realized that the patch is has some Maemo/X11-specific code... trying to port it to Android at the moment.
Comment on attachment 505794 [details] [diff] [review] delete rbo Setting feedback- because this patch actually *creates* this bug on Android. In other words: | Maemo | Android | --------------+-------+---------+ Without patch | Bad | Good | --------------+-------+---------+ With patch | Good | Bad | --------------+-------+---------+ The reason for this bug on Android seems that it *might* be that when BindToFramebuffer binds the texture as color attachment of a framebuffer, it results in the framebuffer having only a color attachment and no depth buffer attachment. If that is the case, then the fix would be to attach a renderbuffer as depth attachment.
Attachment #505794 - Flags: feedback?(jmuizelaar) → feedback-
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: