System Environment: ---------------------------------------------------------------------- Platform: HSW (OS:Ubuntu) Libdrm: (master)libdrm-2.4.49 Mesa:(master)90d185544c897ca0b4c3c677fed4290330bb0706 Xf86_video_intel:(master)2.99.906-28-g12e9 Cairo: (master)31eff5c6eb57ad379689748fd8c60a5ffe0ba481 Kernel: (drm-intel-nightly) 164a4cb4c1431a0689f85507868356fae24da638 Bug detailed description: cairo-trace/firefox-planet-gnome.trace performance reduce ~35% on HSW Ubuntu. Especially, it works well on HSW Fedora. The problem also doesn’t exist on IVB(Fedora & Ubuntu). It’s kernel –dinq regression. By bisected, show that the first bad commit: commit cbaef0f173c7c8bb14976f3928e5876efec444e2 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Nov 6 23:02:24 2013 +0200 drm/i915: Set has_fbc=true for all SNB+, except VLV Performance -------------------------------------------- drm-intel-fixes : 1.75 drm-intel-next-queued:2.849 drm-next:1.756 nightlytop:2.847 Reproduce steps: -------------------------------------------------------------------- 1. xinit& 2. vblank_mode=0 CAIRO_TEST_TARGET=xlib perf/cairo-perf-trace -i 6 /home/cairo-traces/benchmark/firefox-planet-gnome.trace
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.