Blender (both 2.23-r1 and 2.26) crashes when attempting to render an image or frame in an animation with: blender: r200_vtxfmt.c:1087: r200VtxfmtUnbindContext: Assertion `vb.context == ctx' failed. While this is not a gentoo bug per se (see bug #25 at bugs.xfree.org), there does exist a patch which purports to fix this problem (setting the environment variable RADEON_NO_VTXFMT as suggested does not fix this). However, the patch doesn't apply cleanly to the Gentoo ebuild (which is unfortunate, because the gentoo ebuild fixes a lot of other stuff, including allowing my 8500le to run at 1920x1200 resolution ... kudos to the gentoo xfree maintainers for that!), so I am posting this bug to 1) let you know of the problem 2) let you know about a patch designed to fix the problem, and 3) hope you might have a chance to modify the patch so it applies properly against the Gentoo modified xfree sources, if possible.
What about setting R200_NO_VTXFMT, the RADEON_xxx one is for the 7500 et al. The flush vertices patch is already applied iirc (and from the xfree bug report doesn't look like it fixes it anyway) The latter "big patch" (id=25 on that bug) looks like it'll fix it (if nothing else it removes the assert line ;) but it has quite a bit that's different from what's in xfree4.3, it looks like a patch against dri-cvs.
[quote]What about setting R200_NO_VTXFMT?[/quote] This indeed worked perfectly, and my Blender renderings are blindingly fast on my dual athlon. Very nice! That, coupled with the other radeon patches that allow the most excellent 1920x1200 resolution, have made my Gentoo system the perfect platform for using this combination of hardware exactly as I intended. Many thanks! It would be nice to see a patch that fixes this more generally (so others aren't confronted with this problem, but the workaround you provided is more than adequate for me.
Jean: What did you set the variable $R200_NO_VTXFMT to exactly, just "1"?
Yes. (within a bash shell) export R200_NO_VTXFMT=1 did the trick.
I think I am seeing similar problems. I saw this with both blender 2.26 and 2.27. However I am using xfree 4.3.0 , with a radeon 9000. using the xfree-drm drivers. When i didn't use the radeon driver, and just let X load (not sure what 'driver' that is), i saw none of these errors. The big one is strange visual artifacts. I'm attaching a PNG (rather large). If you look at it, the background around the buttons is transparent to the root window. It also crashes like crazy whenever i try to render, or do pretty much anything else. I tried setting the variables mentioned here (in my ~/.bashrc), to no avail. What can I do to help?
Created attachment 12398 [details] Screenshot of Blender 2.27. NOTE: large, ~770KB png Look at the bottom, the background around buttons is completely transparent. Among other nasty problems.
the patch you mentioned is applied in -r3 (and in recent -r2 as well). any progress on this, guys?
I have not had a chance to try blender 2.27. Does anyone have an ebuild available for it? I have an 8500 all in wonder and an 8500Le I can test on at home, as well as 7500s and 9100s at work (all systems run Gentoo). I would be happy to test any patches or fixes being offered.
The ebuild is in portage. It might be in ~x86 profile. Try: ACCEPT_KEYWORDS="~x86" emerge -p blender
if -r3 supposedly fixes radeon 9000 problems, I can try -r3 here. Fast system, won't take long to build. Yes, no?
shouldn't take long to build, no.
Okay, Seemant. I have installed 4.3.0-r3 , however I still have the exact same problems with blender 2.27. I don't think I'm barking up the right tree but I am going to rebuild blender.
Rebuilt blender, same problems. In fact, i upgraded to xfree-drm-r5 (r4 complained about VIDEO_CARDS regardless if I set it or not), ran blender, closed it, and shortly thereafter my system hung. What else can I do to help find the problem?
I run into an issue where, after having run blender once or twice and done something else of a 3d nature (let the opengl screen saver run, what have you), that blender will no longer display. The window frame comes up, and the program appears to be running, but no buttons are display, no workspace, etc. I've yet to have it crash my machine, but it does require a reboot before blender will run again properly. This is with xfree-drm 4.3.0-r4 and earlier ... I'll try -r5 out and see if there is any change.
I think for me it was xfree-drm-4.3.0-r5 causing my lockups. I tried -r4 but it complains about setting VIDEO_CARDS, even when I do. So I went back to what I had before, 4.3.0 (-rnothing). I haven't had any problems since.
-r5 is not unmasked on my system, so I am not going to try it until it is unmasked. xfree-drm-r4 is easy to install. Instead of using USE="radeon", do an VIDEO_CARDS="radeon" emerge xfree-drm instead or, if that fails: export VIDEO_CARDS="radeon" emerge xfree-drm That will allow you to install and test xfree-drm-r4. I believe the old USE="radeon" has been depricated in favor of a VIDEO_CARDS environment variable as described above instead. good luck!
I'm sorry it has taken me so long to get back to you, I appreicate your work. I am still having the same problems, unfortunately.
Can anyone involved please check if this problem is still present?
Please reopen and change the summary if this is still a problem with >=xorg-x11-6.8.0.
I can no longer assist as I don't have a Radeon any longer.
