I get splash screen corruption as well as general artifacts when running blender (any version, now running 2.41) with any linux kernel (started with 2.6.8, now with 2.6.15), several fglrx versions (now 2.23.7). The card is an ATI 9600 XT. I’ve tried about 5000 XF86Config combinations …
The corruption itself is weird as the spash screen comes up with a black background (as if the fill failed somehow) and the shading of the buttons in the interface is a bit off.
you accidentally stated the driver version as 2.23.7 - I think you meant 8.23.7? That might have caused teragone’s confusion.
But concerning your problem: First I want to point out that I use the same graphics card on various Linux distributions without any such problems. As far as ATI cards are concerned, I found that in many cases Blender performance is much better on Linux than on Windows machines. This makes me think that in your case it might be a configuration problem.
Did you activate antialiasing? I think I vaguely remember ATI cards being problematic about the combination of blender with AA.
Is the driver correctly installed? What output does fglrxinfo give?
Hi, you’re right, sorry about that, it is indeed 8.23.7. I’ve tried quite a few others (older ones).
The distribution is Debian Sarge (3.1). The drivers are installed correctly as far as I can tell (made debs from the ATI package scripts, installed them, compiled kernel module, installed blah blah). The module insmods properly with no syslog errors.
fgrlxinfo IIRC gives the expected output (correct OpenGL vendor etc), but I will post it as soon as I can get to it.
AA is definitely turned off (XF86Config and XFree86.0.log say so at least).
unfortunately Debian is one of the few major distributions I didn’t already try out myself - so I don’t know if I can be of any help.
I’m sorry bothering you with so many questions, just try to narrow the problem down for myself…
Do other OpenGL applications work correctly with fglrx?
Did you try running Blender with the default Mesa driver?
If it’s not a driver issue, the reason for your troubles must lie somewhere else…(Of course!)
I suppose Blender is installed correctly (including dependencies)? Where did you get it from - some Debian repository or Blender3D.org?
No problem with lots of questions - after all I want to solve this problem
Apart from glxgears and fgl_glxgears I have not tried other OpenGL apps. But these two run fine. As to the Blender builds, I tried the default Debian one (2.37), and all the ones after that I built myself from Blender sources (2.40, 2.41). They all exhibit the same problem…
I did try Mesa and Blender runs fine with it, just very very slowly.
So if it runs flawlessly with Mesa, it is definitely a fglrx problem.
Just for the sake of completeness you could try one of the precompiled 2.41 packages from Blender3D.org - or do they refuse to run on Debian? (Oops, that was another question. It seems I am much better at asking than at offering answers… %| ).
A precompiled one will probably run on Debian, although the binaries I compiled myself were with default build options. So unless my libraries are corrupt (but then why does it work with Mesa) or my compiler is bad (same argument) then it has to be the driver as you said…
Interestingly it is an intermittent problem in that it shows up like 75% of the time accross reboots (that is, if I boot the PC and running blender works, then it will keep working, and conversely, if it does not work the first time it will keep not working. huh?)
Hmmm… wild guessing mode on Perhaps problems with the boot procedure? Maybe in 75 % of boot sequences the driver gets not loaded correctly…
Funnily a problem I once had with Ubuntu Hoary (which is, as I understand, a Debian based system, too) comes to my mind, where the simple fact if my notebook was plugged to the power outlet or not changed the numbering of my network devices - leaving them unfunctional in one case or the other. Maybe there is a problem with the sequence in which the drivers are loaded in your case, too.
As already said I have absolutely no experience with Debian, but do you get any error messages at boot time concerning the graphic card driver whenever the problem occurs?
O day and night, but this is wondrous strange!?
Just for curiousity: Why did you bother to compile Blender from source before trying the precompiled packages? From my experience compiling Blender can be a pain in the … aah,… neck. On Fedora Core 4 I didn’t even get it to compile!
Apart from that you will find two precompiled packages on Blender3D.org, one ‘static’ for systems without OpenGL support and one ‘dynamic’ for systems with OpenGL support. Maybe one of them might solve your problem. And don’t be afraid: You don’t have to install these packages. You simply unpack them to a directory of your liking and start them from there - so there is no uninstalling and messing around with different versions…
To Ikari: I have managed to reproduce this with ppracer (for of tuxracer), an opengl game for linux - the highlights look solarized So that means it has to be fglrx at fault. As to differences of the system between normal and buggy boots, I’ll have a look (though at first glance things look the same).
To teragone: the log file, as far as I can see is clean. I can post it if you want (I haven’t yet cause it’s huge). I’ve tested it now with and without: mtrr off, VideoOverlay on, OpenGLOverlay off, UseInternalAGPGART no, FSAAEnable no, PseudoColorVisuals off, all to no avail. Also tried several BIOS AGP options again without effect.
Another interesting point is that, meanwhile, I’ve upgraded my motherboard to a totally different one (in terms of drivers+AGP) and the problem persists, even more frequently.
I’m about to buy an NVIDIA one and ditch this crap of a graphics card…
such are the ways of ATI (sigh) - if I want ATI to function properly on my system I have to roll the driver waay back.
Right now im running 8.18.8 and thats as close I can get to a stable functioning system - so that’s my advise to you: roll back untill you find one that works.
@claws
I seriously can not confirm any kind of trouble concerning my ATI card and the latest drivers for Linux. I’m using Fedora Core 4 and never encountered serious problems. So in my opinion rolling the drivers back to ancient versions is not an option.
@nikosg
Switching to Nvidia? I have a feeling that the only effect of this will be to open a Pandora’s box of different problems…
But, alas… I’m a little bit confused right now. Teragone asked for the Xorg logfile and you said you could provide it… I always thought Debian Sarge shipped with Xfree86 instead of Xorg. Does that mean you have cross-updated your Debian distribution with Xorg files from Ubuntu? Might that be the problem? Or do we just talk at cross-purposes because of an uncorrect terminology?
I still have a strong feeling that this might be a boot-time problem. If the driver runs flawlessly once (as seldom as it might occur), the driver file itself (and the kernel modules, etc.) must be in order, right? I can only assume that the driver is not loaded correctly in the most time of boot sequences for one reason or the other. Is there a difference in the fglrxinfo output between normal and buggy boots? Really no error messages during buggy boot sequences?
(If the same card performs well under Windows it can also not be a hardware problem…)
Weird.
“Highlights look solarized”… What color depth do you use? Gamma correction? CRT or LCD?
to claws: ok, I might try rolling back, though that will be a pain as my motherboard will not work with anything less than 2.6.15 and I know for a fact that fgrlx < 8.23.x will need patching before it works with 2.6.15 <sigh>
to ikari: I use XFree86, not Xorg. I cut, pasted and diff-ed kern.log and XFree86.0.log between good and bad boots. kern.logs are identical minus minor differences in bogomips calculations, so no hints there. There is only one line of difference in XFree86.0.log:
(II) fglrx(0): [drm] mapped SAREA 0xf8caf000 to 0xb7b34000
The last word is different on every boot, good or bad, and the values look random, with no alignment differences. So no joy there either.
As to whether I have a CRT or LCD, that’s unrelated - the corruption is in the video ram. The background of the splash screen in blender comes out black, think about it. There is somewhere a pixel-fill/texture function that instead of white outputs black. I think that’s as clear as I can put it. Now the gamma correction could be the reason, but settings are identical across boots; how can I have gamma correction on one boot and not on the other?
I see, but unfortunately the argument “How can this or that be on one boot and not on another?” is valid for ANY possible reason for your problems.
If it worked at least once, one would say that - although it seemed so at first glance - it simply can not be the fglrx driver files / kernel modules causing trouble, as the driver and according setup files do not change from one boot to another.
If the fglrxinfo output really is the same after every boot and the boot sequence gives no error messages, then fglrx is up and running every time. Does glxgears performance differ between buggy and correct boots? If not, I really don’t see how it could be fglrx’s fault.
So I simply chose to take a more widespread approach to your problem and take the monitor into account. Didn’t think of the black splash screen thingy, though.
Remember, I am just brainstorming here as I really have no idea what could be wrong on your machine.
Apart from that I am still confused about obviously any non OpenGL app running perfectly. Since fglrx does control your graphics card in 2d mode, too…
Xine ok? Gimp ok?
If you render with YafRay (xml-option in Blender’s render options disabled), does the YafRay render window show the upcoming render?
I know there are Debian backports for Xorg available. Perhaps switching from XFree86 to Xorg does the trick, as I think XFree86 is a little outdated. That’s why many major distributions now ship with Xorg.
