When doing pretty much anything in blender (e.g. moving a toolpane), one must literally wait several seconds in between repaints. Meanwhile, one of my two cores is pegged in blender.bin. It seems like the problem is in the kernel judging from this: $ opreport -s sample CPU: Core 2, speed 800 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000 CPU_CLK_UNHALT...| samples| %| ------------------ 1096784 84.0824 no-vmlinux 38211 2.9294 oprofiled I would supply a call graph, but opreport -c and oparchive are annoyingly both broken due to bug #465996 (https://bugzilla.redhat.com/show_bug.cgi?id=465996). This is on i965 with new Fedora rawhide packages (GEM enabled) although I have been tracking it for a while. The kernel doesn't appear to be emitting any suspicious output.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you try to boot the computer with nomodeset paramter on your kernel command line, please? We will review this issue again once you've had a chance to attach this information. Thanks in advance.
This was simply meant as a tracker bug to make sure the appropriate fedora packagers knew of the issue. This has already been reported and diagnosed in the freedesktop bug (#17951). The problem is evidently the widespread use of the deprecated glBitmap() in blender for text rendering. This causes a slow fallback in the intel driver. Apparently Eric Anholt intends on trying to accelerate this case in the next few weeks, but really the solution is to make Blender use another drawing path other than glBitmap. A second issue is the fact that blender uses GL's immediate mode for all of its rendering.
So, then this is blender issue, isn't it? Reassigning.
Well, the intel driver should soon accelerate glBitmap which should help tremendously. The real fix if for blender to stop using glBitmap altogether but they apparently have no plans on doing that. Assigning to blender is fine though.
I have create a bug report on upstream: http://projects.blender.org/tracker/?func=detail&aid=17831&group_id=9&atid=264