http://bugs.freedesktop.org/show_bug.cgi?id=10966
Summary: workaround to avoid the assert main/renderbuffer.c:2041:
_mesa_add_renderbuffer:...
Product: Mesa
Version: 6.5
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Mesa core
AssignedTo: mesa3d-dev@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
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)
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
