Bug 49148

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.

patch fix problem. thanks.

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

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".

*** Bug 47796 has been marked as a duplicate of this bug. ***

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.

These assertions should be fixed with http://cgit.freedesktop.org/mesa/mesa/commit/?id=7178d6ac590211cf123254688da1a540cce6c0a9 on mesa-git.