workaround to avoid the assert main/renderbuffer.c:2041: _mesa_add_renderbuffer:...
Submitted by Pierre Nerzic
Assigned to Default DRI bug account
Description
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)
Version: 6.5