On 12/08/2012 05:40 AM, Brian Paul wrote:
On 12/08/2012 01:10 AM, Kenneth Graunke wrote:
Starting KDE on i965 makes the X server die in a fire with the following
assertion:
X: intel_fbo.c:94: intel_delete_renderbuffer: Assertion `irb' failed.
Obviously, this is rather unpleasant. Bisecting revealed that:
006918c0db77e945ac56b15bc64eba502b86d56c is the first bad commit
commit 006918c0db77e945ac56b15bc64eba502b86d56c
Author: Brian Paul<bri...@vmware.com>
Date: Sat Dec 1 10:52:42 2012 -0700
mesa: remove warning message in _mesa_reference_renderbuffer_()
We were warning when there was no current context and we're about
to delete a renderbuffer, but that happens fairly often and isn't
really a problem.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=57754
Note: This is a candidate for the stable branches.
Tested-by: Ian Romanick<ian.d.roman...@intel.com>
This commit removed not only the "else emit warning" block, but the
whole NULL check as well. Apparently it's necessary, so put it back.
Hi Kenneth,
The assertion says the 'irb' is null, but you're checking if the context
is null. Off hand, I think a irb==null check is needed in
intel_delete_renderbuffer(). Maybe seeing a stack trace would shed more
light on where the null irb/ctx is coming from.
In any case, if you need to check for ctx==null, please do that in
intel_delete_renderbuffer().
The deal is that some (most?) drivers don't need a context handle in
order to free a renderbuffer. In the gallium state tracker we use the
context to free a piece of context state that's associated with a
renderbuffer, but the renderbuffer itself can be freed without a context.
Sorry for the headaches this one is causing.
-Brian
Sorry for the false alarm...this was my fault.
Apparently on my system X is loading an older i965_dri.so, but likely a
new libGL. The incompatibility between the one-argument
intel_delete_renderbuffer and two-argument gl_renderbuffer::Delete
caused something stupid to happen...maybe I got the renderbuffer passed
as the context, and NULL for the renderbuffer.
I put both halves back in sync and everything's fine now. Again, my
apologies for the trouble.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
