Bug 490839
Summary: | Slow performance in some situations with the Rawhide kernel 2.6.29-0.25 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Zdenek Kabelac <zkabelac> |
Component: | xorg-x11-drv-intel | Assignee: | Kristian Høgsberg <krh> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | ajax, awilliam, kevin, linuxhippy, mcepl, mishu, moneta.mace, rdieter, tbzatek, xgl-maint |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-04-17 15:42:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Zdenek Kabelac
2009-03-18 09:47:11 UTC
I was seeing something very like this here as well... in my case it was a tigervnc session to a bgr233 server. Without Composite enabled it was unusable and 100% cpu. Enable Composite and it's much much faster. ;( Could you please add here reference to your upstream bug for this? I think it's the Fedora's 'feature' - this problem doesn't appear with upstream vanilla Linux kernel - I guess it's the result of using drm-next branch - unfortunately there is non-trivial amount of patches included within rawhides' kernel - so it's really hard to guess which patch introduces this problem... I'm having kind of similar issue - vncviewer, lines test in gtkperf, image scrolling in EOG and GThumb are unbearably slow, like not accelerated. Reverting to vanilla 2.6.29 didn't help though. That was with Intel KMS, UXA, DRI2. So I'm back to UMS and EXA/DRI1, which works fine. > I'm having kind of similar issue - vncviewer, lines test in gtkperf, image > scrolling in EOG and GThumb are unbearably slow, like not accelerated. It has never been accalerated, however UXA has terrible fallback handling: https://bugs.freedesktop.org/show_bug.cgi?id=20698 That means if UXA is forced out of accaleration somehow (e.g. lines, core fonts, ...) performance is horrible. This also affects GTK+-1.2/Motif apps as well. I'll extend this bugreport with few more things: The problem is still present with 2.6.29.1-37.rc1.fc11.x86_64 With kernel option 'nomodesetting' it seems to be working much faster with my test case. So the problem is related with KMS (which I'm not using with vanilla kernel) If I'm running without modesetting - and I try to manipulate brightness of my laptop, the speed of OpenGL drastically drops down and never gets back. And brightness look pretty weird anyway. I'm getting curious how this is connected together..... This was mostly due to how software fallbacks were handled in UXA with KMS. We'd map the entire front-buffer cacheable, do some (very little) drawing, and then unmap it. To guarantee consistency we'd clflush the whole thing on unmap. 8M cache flushes are not especially fast. This should be resolved in newer kernels, as we use uncached GTT maps for software fallbacks now. x11perf -ftext gets reasonable-looking numbers with kernel-2.6.29.1-54.fc11 and xorg-x11-drv-intel-2.6.99.902-2.fc11 on my GM45. If anyone can still reproduce this kind of performance cliff with those versions or later, please reopen this bug. I can confirm that kernel 2.6.29.1-54.fc11 fixes this performance regression - very nice - thanks This kernel also seem to survive my glxgears reported problem: https://bugs.freedesktop.org/show_bug.cgi?id=21083 So very good work - I hope these kernel patches quickly reach the vanilla kernel. Well, the behavior here is different now, but still not ideal. ;) Anytime I open a virt-viewer, the entire machine freezes for about 20 seconds or so, then it all comes back and works ok. Dmesg has tons of: X:2959 freeing invalid memtype d8db9000-d8dba000 X:2959 freeing invalid memtype d8dbb000-d8dbc000 X:2959 freeing invalid memtype d8dbd000-d8dbe000 Nothing that looks out of the ordinary in Xorg.0.log. I do have COMPOSITE enabled via the xfwm4 window manager. Happy to provide more info or test. I'm thinking you should probably open a new report, Kevin, just to keep things clean - it doesn't sound like it was quite the same problem in the first place. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Yeah, I will continue over on bug 494753 Ajax: Could it be the change to the caching mode slows down trapezoid heavy applications? I already reported a bug upstream: https://bugs.freedesktop.org/show_bug.cgi?id=21376 I see awful lot of cycles spent in rasterizeEdges, and e.g. for the QGears2 benchmark I get about 1/10 of the framerate compared to Fedora8+EXA. |