Bug 466005 - Blender is unbelievably painfully slow on 965
Blender is unbelievably painfully slow on 965
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: blender (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jochen Schmitt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-07 13:37 EDT by Ben Gamari
Modified: 2018-04-11 03:02 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-13 11:56:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 17951 None None None Never

  None (edit)
Description Ben Gamari 2008-10-07 13:37:17 EDT
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.
Comment 1 Matěj Cepl 2008-10-26 18:14:39 EDT
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.
Comment 2 Ben Gamari 2008-10-26 18:21:42 EDT
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.
Comment 3 Matěj Cepl 2008-10-27 06:52:22 EDT
So, then this is blender issue, isn't it? Reassigning.
Comment 4 Ben Gamari 2008-10-27 09:29:55 EDT
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.
Comment 5 Jochen Schmitt 2008-11-13 11:56:06 EST
I have create a bug report on upstream:

http://projects.blender.org/tracker/?func=detail&aid=17831&group_id=9&atid=264

Note You need to log in before you can comment on or make changes to this bug.