Bug 10966 - workaround to avoid the assert main/renderbuffer.c:2041: _mesa_add_renderbuffer:...
Summary: workaround to avoid the assert main/renderbuffer.c:2041: _mesa_add_renderbuff...
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/Unichrome (show other bugs)
Version: 6.5
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 29824 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-05-16 05:28 UTC by Pierre Nerzic
Modified: 2019-09-18 20:34 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
mesa-6.5.3/src/mesa/main/renderbuffer.c diffs to avoid assert failure (713 bytes, patch)
2007-05-16 07:13 UTC, Pierre Nerzic
Details | Splinter Review
mesa-6.5.3/src/mesa/main/renderbuffer.c diffs to avoid assert failure (1.40 KB, patch)
2007-05-16 09:07 UTC, Pierre Nerzic
Details | Splinter Review
stack trace and variable dump (8.69 KB, text/plain)
2007-05-16 23:38 UTC, Pierre Nerzic
Details
patch to via_context.c (806 bytes, patch)
2007-05-17 07:52 UTC, Brian Paul
Details | Splinter Review
error messages when running DirectX programs with Wine and Unichrome driver, in the latest version (17.23 KB, text/plain)
2008-01-17 02:59 UTC, Whistler
Details
patch for OSMesa driver (567 bytes, patch)
2010-07-02 15:05 UTC, Brian Paul
Details | Splinter Review

Description Pierre Nerzic 2007-05-16 05:28:38 UTC
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)
Comment 1 Alex Deucher 2007-05-16 06:04:41 UTC
please attach a diff with your changes.
Comment 2 Pierre Nerzic 2007-05-16 07:13:46 UTC
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.
Comment 3 Benno Schulenberg 2007-05-16 07:55:42 UTC
Please attach a unified diff, made with 'diff -u' from the top dir of mesa.
Comment 4 Pierre Nerzic 2007-05-16 09:07:05 UTC
Created attachment 9986 [details] [review]
mesa-6.5.3/src/mesa/main/renderbuffer.c diffs to avoid assert failure
Comment 5 Brian Paul 2007-05-16 10:12:17 UTC
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?

Comment 6 Pierre Nerzic 2007-05-16 23:38:06 UTC
Created attachment 9992 [details]
stack trace and variable dump
Comment 7 Pierre Nerzic 2007-05-16 23:45:22 UTC
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


Comment 8 Brian Paul 2007-05-17 07:52:48 UTC
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().
Comment 9 Andrey Melentyev 2007-05-24 13:16:22 UTC
(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.
Comment 10 Gergely Kiss 2007-08-24 17:10:22 UTC
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?
Comment 11 Whistler 2008-01-17 02:59:21 UTC
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.
Comment 12 Tom Fogal 2010-07-02 13:49:51 UTC
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...
Comment 13 Tom Fogal 2010-07-02 14:38:55 UTC
Potentially the same bug:

  http://www.cmake.org/Bug/view.php?id=10900
Comment 14 Brian Paul 2010-07-02 15:05:21 UTC
Created attachment 36700 [details] [review]
patch for OSMesa driver

Tom, can you try this patch to the OSMesa driver?
Comment 15 Tom Fogal 2010-07-02 17:12:11 UTC
Brian, yeah, that fixes the crash && rendering works as expected.  Thanks for the quick response.
Comment 16 Brian Paul 2010-07-02 17:25:39 UTC
OK, osmesa patch pushed as commit 91c37599f621a0ec498c0f0add14f16470ca852b

The SIS and Unichrome drivers probably need similar fixes, if anyone cares.
Comment 17 Tom Fogal 2010-08-26 14:27:49 UTC
*** Bug 29824 has been marked as a duplicate of this bug. ***
Comment 18 Marek Olšák 2011-03-01 13:46:39 UTC
It's no longer a Mesa Core issue, reassigning to Unichrome.
Comment 19 GitLab Migration User 2019-09-18 20:34:43 UTC
-- 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.