| Summary: | [HSW fbc] cairo performance reduced over 60% by enabling FBC | ||
|---|---|---|---|
| Product: | DRI | Reporter: | zhoujian <jianx.zhou> |
| Component: | DRM/Intel | Assignee: | Paulo Zanoni <przanoni> |
| Status: | CLOSED INVALID | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | major | ||
| Priority: | medium | CC: | chris, christophe.prigent, eero.t.tamminen, intel-gfx-bugs, lilix.cheng, przanoni, ville.syrjala, wendy.wang |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | HSW | i915 features: | display/FBC |
| Bug Depends on: | |||
| Bug Blocks: | 87704 | ||
|
Description
zhoujian
2013-11-26 09:33:21 UTC
To confirm, can you boot with i915.i915_enable_fbc=0 and see if the performance recovers? (In reply to comment #1) > To confirm, can you boot with i915.i915_enable_fbc=0 and see if the > performance recovers? The problem was fixed with i915.i915_enable_fbc=0. Ville, I have the funny feeling that your FBC tracking fixes are required. Of course, it still means we will have a similar impact on frontbuffer rendering, but that is par for the course. (In reply to comment #3) > Ville, I have the funny feeling that your FBC tracking fixes are required. > Of course, it still means we will have a similar impact on frontbuffer > rendering, but that is par for the course. I wonder if we should follow the same model as the other drivers and only allow this kind of feature when runtime PM is enabled and/or when we're on battery... (In reply to comment #4) > (In reply to comment #3) > > Ville, I have the funny feeling that your FBC tracking fixes are required. > > Of course, it still means we will have a similar impact on frontbuffer > > rendering, but that is par for the course. > > I wonder if we should follow the same model as the other drivers and only > allow this kind of feature when runtime PM is enabled and/or when we're on > battery... Imo that's just chickening out of hard problems. PM features should be enabled by default, and if they're causing issues due to overhead somewhere else we need to look at that and fix it up. I'm curious why Fedora is not impacted? I've pushed a big pile of FBC patches here: git://gitorious.org/vsyrjala/linux.git fbc_stolen_fixes Would be nice to know if the tracking improvements help with the performance. (In reply to comment #7) > I've pushed a big pile of FBC patches here: > git://gitorious.org/vsyrjala/linux.git fbc_stolen_fixes > > Would be nice to know if the tracking improvements help with the performance. Much! With fbc_stolen_fixes the impact of FBC on both blit/render frontbuffer performance is ~10%, not orders of magnitude. Curious question: How much of those 10% can be explained with the additional memory traffic, presuming that the compressed fb is half the size of the real one in a back-of-the-envelope estimate (and that we invalidate it every frame)? Oh and the obvious one ofc: Impact on offscreen rendering is now 0? (In reply to comment #7) > I've pushed a big pile of FBC patches here: > git://gitorious.org/vsyrjala/linux.git fbc_stolen_fixes Hi, the kernel that from the tree ,doesn't support HSW. IVB can start with the kernel, but i915 module can't be loaded. (In reply to comment #7) > I've pushed a big pile of FBC patches here: > git://gitorious.org/vsyrjala/linux.git fbc_stolen_fixes > > Would be nice to know if the tracking improvements help with the performance. Hi, can you give us a patch based on kernel -nightly branch? fbc now disabled again by default. Verified it. Well, even though it is disabled by default, FBC is still reducing cairo performance by over 60%, isn't it? I'm not sure if closing the bug is the right approach, since the feature is still there. Can't we test Ville's FBC tree and see if it improves the performance? (In reply to comment #15) > Can't we test Ville's FBC tree and see if it improves the performance? We can. Could you please us give the git repo? (In reply to comment #15) > Well, even though it is disabled by default, FBC is still reducing cairo > performance by over 60%, isn't it? I'm not sure if closing the bug is the > right approach, since the feature is still there. I agree with Paulo. Let's keep this open to track it. Since it's not default feature, I'm decreasing priority and not considering it as regression. I think Paulo is working to re-enable FBC by default using the new front buffer tracking stuff; maybe that will help. Really old bug, FBC is disabled by default, and enabling taints the kernel. Closing. I'm assuming new bugs will be filed if the same perf regression comes back if/when we start enabling FBC again. The purpose of keeping this bug open was to have a definite testcase that the new FBC code has to pass before being enabled. (In reply to Chris Wilson from comment #20) > The purpose of keeping this bug open was to have a definite testcase that > the new FBC code has to pass before being enabled. I've now documented this in the relevant JIRA tasks. (In reply to Jani Nikula from comment #21) > (In reply to Chris Wilson from comment #20) > > The purpose of keeping this bug open was to have a definite testcase that > > the new FBC code has to pass before being enabled. > > I've now documented this in the relevant JIRA tasks. Apparently no one reads JIRA as FBC was re-enabled without fixing the regressions. Jumping to conclusions, a secondary effect causing an annoying slowdown when fbc is enabled. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.