Bug 49148 - nv20_state_fb.c:50: get_rt_format: Assertion `0' failed.
Summary: nv20_state_fb.c:50: get_rt_format: Assertion `0' failed.
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 47796 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-25 09:40 UTC by JohnDoe_71Rus
Modified: 2013-10-08 16:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
proposed fix (1.33 KB, patch)
2012-04-25 12:51 UTC, Lucas Stach
no flags Details | Splinter Review

Description JohnDoe_71Rus 2012-04-25 09:40:51 UTC
Lubuntu 11.10

0.0 VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti 4400] (rev a3)
X.Org version: 1.11.2.902
  dimensions:    1024x768 pixels (270x203 millimeters)
  depth of root window:    24 planes
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
--
OpenGL vendor string: Nouveau
OpenGL renderer string: Mesa DRI nv25 x86/MMX/SSE2
OpenGL version string: 1.2 Mesa 8.0.2
Linux 3.1.3-030103-generic
xserver-xorg-video-nouveau 1:0.0.16+git20120328.ab7291d3-0ubuntu0sarvatt~oneiric

Start of some 3D applications. Example 

SweetHome3D-3.3$ ./SweetHome3D
JAVA 3D: OpenGL 1.2 detected; will run with reduced functionality
JAVA 3D: OpenGL 1.2 detected; will run with reduced functionality
java: nv20_state_fb.c:50: get_rt_format: Assertion `0' failed.
Comment 1 Lucas Stach 2012-04-25 12:51:55 UTC
Created attachment 60588 [details] [review]
proposed fix

Could you please try the attached patch? It's only compile tested, as I don't have any vieux hardware and you have to compile mesa from git, but it should be worth a try.
Comment 2 JohnDoe_71Rus 2012-04-30 10:54:01 UTC
patch fix problem. thanks.
Comment 3 Truckman Jones 2013-03-20 18:47:37 UTC
I'm getting the following error under wine 1.5.26 "nv10_state_fb.c:50: get_rt_format: Assertion `0' failed", trying to run "http://ufpr.dl.sourceforge.net/project/criticalmass/Critical%20Mass/1.0.0/CriticalMass-Windows-1.0.0.zip" and many other 3d apps. I'm running here nouveau 1.0.2 driver on Nvidia MX 4000 hardware (slackware linux 14.0, with required experimental libdrm) and I was able to run "http://web.media.mit.edu/~gordonw/OpenGL/simpleGLUT.zip" with hw acceleration and no problems at all, I have applied this proposed patch against mesa 9.0.3 and succeeded with some offset, but unfortunatelly did have no effect on my problem... I'm wondering if there is something missing on this patch, like enabling some more modes available on this hardware? I'm looking for a solution and willing to help testing any experimental patches... Thanks in advance to you folks at freedesktop.org! 
Ciao
João.http://ufpr.dl.sourceforge.net/project/criticalmass/Critical%20Mass/1.0.0/CriticalMass-Windows-1.0.0.zip
Comment 4 Ilia Mirkin 2013-08-21 05:22:50 UTC
OK, so I tried on a NV18 with Mesa 9.2-git (as of a couple of days ago). SweetHome3D, uh, "works", in that it doesn't crash. But the app is _really_ unhappy about the lack of cube map support, and the "3d" view is completely messed up as a result. [It does seem as though nv10+ cards have cubemap support, but the driver doesn't make use of that.]

That CriticalMass app also seems to work fine on wine 1.6.0 and mesa 9.2-git (and also mesa 9.1.6).

Now, as to my analysis of the code, that assert() just plain can't happen. It's inconceivable :) There aren't a lot of assignments to ->surface, and the only values they can take on are the ones that get_rt_format expects (it either assigns those values directly or copies them from other nouveau_surface objects). Perhaps in older Mesa's that was not the case, I didn't dig _too_ deeply, but a small amount of digging didn't reveal any obvious fixes in this area. Perhaps something was fixed in the surrounding mesa code.

So... please re-test with the latest mesa. If you still get the assert, run the app inside GDB and provide the full backtrace. Also try to provide instructions for how I could reproduce the issue, if it's more than just "start program X".
Comment 5 Ilia Mirkin 2013-08-21 05:53:15 UTC
*** Bug 47796 has been marked as a duplicate of this bug. ***
Comment 6 Ilia Mirkin 2013-09-02 07:07:09 UTC
Well, I've found an app that causes this to trigger -- supertuxkart.

The basic problem seem to be that when nouveau_render_texture is called, the teximage's surface does not seem to be populated (although its base values are fine). As a result, the renderbuffer's surface ends up with 0's for everything, and that's not a supported format.

I've yet to figure out how come the teximage's stuff isn't updated (nor do I see where it would ever be updated). I think the move is to add a AllocTextureImageBuffer implementation, but that is, as of yet, untested.
Comment 7 Ilia Mirkin 2013-10-08 16:52:42 UTC
These assertions should be fixed with http://cgit.freedesktop.org/mesa/mesa/commit/?id=7178d6ac590211cf123254688da1a540cce6c0a9 on mesa-git.


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.