I own a VIA EPIA800ML motherboard, with an Unichrome adapter : chipset CLE266. My Ubuntu 7.04 has installed Mesa-6.5.2, but, as far as I have seen, the same bug exists in 6.5.3. When launching wine on any 3D soft, I got the famous main/renderbuffer.c:2041: _mesa_add_renderbuffer: assertion "bufferName == BUFFER_DEPTH || bufferName == BUFFER_STENCIL || fb->Attachment[bufferName].Renderbuffer == ((void *)0)" failed (translated from french) This is due to an attempt to allocate a second front render buffer into the current frame buffer. This happens when calling calculate_buffer_parameters from viaMakeCurrent in mesa-6.5.2/src/mesa/drivers/dri/unichrome/via_context.c. The problem is when it calls viaMakeCurrent two times with different contexts but with the same framebuffer, mesa tries to allocate a second renderbuffer. This bug is mentionned by the via developer, in via_context.c (look for the word "funny"). Very bad to have suggested no solution. So (after many attempts, without any explanations about the code), I propose to change a little the file : ..../mesa-6.5.?/src/mesa/main/renderbuffer.c: * remove the assert, line 2041 in 6.5.2 (or 2075 in 6.5.3) * insert these 6 lines after the second assert, line 2086 in 6.5.3 : /* do not allocate a new renderbuffer, use the current one */ if (bufferName != BUFFER_DEPTH && bufferName != BUFFER_STENCIL && fb->Attachment[bufferName].Renderbuffer) { /* no allocation OR delete previous renderbuffer */ return; OR _mesa_remove_renderbuffer(fb,bufferName); } Note : you have to choose between return or _mesa_remove... I tried both with apparently similar results. Now, there is no more "...:2041 assert failed" and my software seem to run much better. But I am totally unsure about the memory (safe or not to reuse/share such a buffer, safe or not for other drivers ?) I do not know which one, the return or the _mesa_remove is better... I must say this is not enough, there is still a big bug in the via unichrome driver, which I report in another post (wrong addresses (?) for 3D drawing). I thank you a lot for your attention and wish my bug report to be useful. Pierre username pierre.nerzic domain free.fr (replace domain by at)
please attach a diff with your changes.
Created attachment 9984 [details] [review] mesa-6.5.3/src/mesa/main/renderbuffer.c diffs to avoid assert failure this is a test for _mesa_add_renderbuffer() in the case there was a renderbuffer attached to a framebuffer, due to a bug in the via/unichrome driver.
Please attach a unified diff, made with 'diff -u' from the top dir of mesa.
Created attachment 9986 [details] [review] mesa-6.5.3/src/mesa/main/renderbuffer.c diffs to avoid assert failure
I'm going to veto that patch. The real bug is in the unichrome driver, not in core Mesa. If you can provide a stack trace when the problem occurs, I might be able to suggest something better. Also, what is the value of 'bufferName' at that time?
Created attachment 9992 [details] stack trace and variable dump
Dear Paul, Alex and Benno, Many apologies for my proposal, clearly this is not a good direction, but it was my only way to make it work. If I knew something about the Unichrome driver... I attached some explanations about the failure, having modified the sources src/mesa/drivers/dri/unichrome/via_context.c to print the calls to viaMakeCurrent and other. Best regards, Pierre
Created attachment 9995 [details] [review] patch to via_context.c Thanks for the extra info. I'm attaching a patch that should help. The same thing may be needed for the BACK and DEPTH renderbuffers. Note that thte unichrome driver really needs some work in this area so this is basically a bandage. See the comments in viaCreateBuffer().
(In reply to comment #8) > Created an attachment (id=9995) [details] > patch to via_context.c > > Thanks for the extra info. I'm attaching a patch that should help. The same > thing may be needed for the BACK and DEPTH renderbuffers. > > Note that thte unichrome driver really needs some work in this area so this is > basically a bandage. See the comments in viaCreateBuffer(). > For some reason your patch doesn't work with my unichrome card. However Pierre's hack seem to solve problem with wine and assert messages.
Hello there, I have exactly the same problem with a SiS630 integrated video adapter. I tried the workaround, mentioned here, but unfortunately, with no success. I get no more "assertion failed" messages, but DirectDraw and D3D appliactions still don't run with Wine... I'm using Ubuntu 7.04, with the built-in version of Mesa (6.5.2). I tried compiling Mesa from source (versions 6.5.2 and 6.5.3), but nothing has changed. When I start a ddraw or d3d app, my computer locks up completely, I have to do a hard reset. Any ideas?
Created attachment 13762 [details] error messages when running DirectX programs with Wine and Unichrome driver, in the latest version It seems with the latest version of Wine and Mesa, the error messages when running DirectX programs with Unichrome was changed. Currently it's like: main/renderbuffer.c：2150：_mesa_reference_renderbuffer: Assertion “oldRb->Magic == 0xaabbccdd” Failed. I've attached more error messages about this.
We are hitting this with our application, VisIt, using software rendering with OSMesa 7.8.2. yana3{brugger}33: bin/visit Running: gui -dv Running: viewer -host 127.0.0.1 -port 5600 -dv -geometry 1512x1148+408+0 -borders 21,8,4,4 -shift 4,21 -preshift 0,0 -defer Running: mdserver -host 127.0.0.1 -port 5601 -dv Running: engine_ser -host 127.0.0.1 -port 5600 -dv engine_ser: main/renderbuffer.c:1924: _mesa_add_renderbuffer: Assertion `bufferName == BUFFER_DEPTH || bufferName == BUFFER_STENCIL || fb->Attachment[bufferName].Renderbuffer == ((void *)0)' failed. Running: engine_ser -host 127.0.0.1 -port 5600 -dv engine_ser: main/renderbuffer.c:1924: _mesa_add_renderbuffer: Assertion `bufferName == BUFFER_DEPTH || bufferName == BUFFER_STENCIL || fb->Attachment[bufferName].Renderbuffer == ((void *)0)' failed. This is with our current trunk. Mesa is built using the autoconf build system: ./configure \ CC="${C_COMPILER}" \ CXX="${CXX_COMPILER}" \ CFLAGS="${CFLAGS} -DUSE_MGL_NAMESPACE" \ CXXFLAGS="${CXXFLAGS} -DUSE_MGL_NAMESPACE" \ --prefix=${PF} \ --without-demos \ --with-driver=osmesa \ --disable-gallium \ --with-max-width=16384 \ --with-max-height=16384 \ --disable-glw \ --disable-glu \ --disable-egl AFAIK, we don't actually use glRenderbuffer* in our application, so I guess there is an implicit buffer for the implicit display? More information as I know it...
Potentially the same bug: http://www.cmake.org/Bug/view.php?id=10900
Created attachment 36700 [details] [review] patch for OSMesa driver Tom, can you try this patch to the OSMesa driver?
Brian, yeah, that fixes the crash && rendering works as expected. Thanks for the quick response.
OK, osmesa patch pushed as commit 91c37599f621a0ec498c0f0add14f16470ca852b The SIS and Unichrome drivers probably need similar fixes, if anyone cares.
*** Bug 29824 has been marked as a duplicate of this bug. ***
It's no longer a Mesa Core issue, reassigning to Unichrome.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/openchrome/old-bug-database/issues/2.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.