Bug 42152 - [bisected] Regression on 3D performance caused by mesa
Summary: [bisected] Regression on 3D performance caused by mesa
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: All Linux (All)
: high major
Assignee: Ian Romanick
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-24 02:04 UTC by libo
Modified: 2012-01-04 01:14 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description libo 2011-10-24 02:04:40 UTC
System Environment:
--------------------------
Libdrm:		(master)2.4.26-12-gb317c96361f88a0a4ccb2faeff09b0476d142c68
Mesa:		(master)6235846cb779bce470bc903f8cfc701bc0343d73
Xserver:	(master)xorg-server-1.11.0-193-  gfb84be47db7cdaff406792c08e34670e8e0cbda9
Xf86_video_intel:(master)2.16.0-156-gf1bb4ebfd8991f2f9eb9c38b9259792c11e7c86a
Cairo:		(master)26c9994393f590c43714ba8d799093b84dd94dc6
Libva:		(master)5c7b9abb93717a2d379e5338b595951fa0c2abbe
Kernel:	(drm-intel-next) 64a742fac3a22f57303d8f1b7e347350a1c48254


Bug detailed description:
-------------------------
There is a regression on 3D performance cases ,such as urbanterror , padman, openarena and so on, which caused by mesa .
I have already bisected the first bad mesa  commit:abaebcee787eeb8a89bf7a82ed4d1532fcde5e39.


Reproduce steps:
-------------------------
1.xinit&
2.gnome-session
3.run wop-engine.x86_64
Comment 1 Eugeni Dodonov 2011-10-24 05:20:59 UTC
This seems to be:

commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Sep 21 15:20:20 2011 -0700

    intel: Drop the immediate validation of the texture object in TFP.

but it does not makes much sense for me why it could cause regressions.

Li, what kind of regressions are you seeing?
Comment 2 libo 2011-10-24 18:05:03 UTC
the fps value of 3D performace cases have about 6.04% ~ 9.38% regressions on average.
(In reply to comment #1)
> This seems to be:
> 
> commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39
> Author: Eric Anholt <eric@anholt.net>
> Date:   Wed Sep 21 15:20:20 2011 -0700
> 
>     intel: Drop the immediate validation of the texture object in TFP.
> 
> but it does not makes much sense for me why it could cause regressions.
> 
> Li, what kind of regressions are you seeing?
Comment 3 libo 2011-10-24 18:20:47 UTC
openarena    -8.96 %  
urbanterror  -6.04 %
lightsmark   -6.25 %  
padman       -9.38 %   
Egypt        -7.72 %
PRO          -8.88 %    
(In reply to comment #1)
> This seems to be:
> 
> commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39
> Author: Eric Anholt <eric@anholt.net>
> Date:   Wed Sep 21 15:20:20 2011 -0700
> 
>     intel: Drop the immediate validation of the texture object in TFP.
> 
> but it does not makes much sense for me why it could cause regressions.
> 
> Li, what kind of regressions are you seeing?
Comment 4 Eric Anholt 2011-10-27 10:53:24 UTC
The bisect looks bad to me.  In my testing of openarena performance between abaebcee787eeb8a89bf7a82ed4d1532fcde5e39 and 4fc9a98a0e01195202cd5f3f5a78cf28c5e8843c, I see a 2.9% performance hit on Sandybridge at commit 7ec2b0d0d6b6a0f760e55ffdee0bdb385a3e900a (which was known, and a planned decision since it is neutral/helps on other chipsets), and a 1% hit at 3cc0a7be23ab603ed40d602595f673a44e079885.

Did you manually test before and after the commit you mentioned before you reported these results?
Comment 5 zhao jian 2011-10-27 18:28:04 UTC
(In reply to comment #4)
> The bisect looks bad to me.  In my testing of openarena performance between
> abaebcee787eeb8a89bf7a82ed4d1532fcde5e39 and
> 4fc9a98a0e01195202cd5f3f5a78cf28c5e8843c, I see a 2.9% performance hit on
> Sandybridge at commit 7ec2b0d0d6b6a0f760e55ffdee0bdb385a3e900a (which was
> known, and a planned decision since it is neutral/helps on other chipsets), and
> a 1% hit at 3cc0a7be23ab603ed40d602595f673a44e079885.
> Did you manually test before and after the commit you mentioned before you
> reported these results?

Hi Eric, 
 commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39 is the first bad commit, and now it still bad. So I think you should use the commit before it(like d430e81c3287eba4ee84ca1639a23f92bbe22c8e) as the good commit to compare with the newest commit. Can you have a try?
Comment 6 Eric Anholt 2011-10-28 16:19:05 UTC
That was just a typo, I meant to say abaebcee787eeb8a89bf7a82ed4d1532fcde5e39~1 and didn't type ~1.
Comment 7 Eric Anholt 2011-11-01 09:21:32 UTC
Oh, are you using a GL-based compositing manager (gnome-shell) there?  If so, that would explain this.
Comment 8 Eric Anholt 2011-11-02 13:04:20 UTC
commit 15b58d8c2233f0e67257cb907c7d90fa23c723a5
Author: Eric Anholt <eric@anholt.net>
Date:   Tue Nov 1 09:24:47 2011 -0700

    Revert "intel: Drop the immediate validation of the texture object in TFP."
    
    This reverts commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39.
    
    The assertion I made was that "the zero-copy code in validation" would
    zero copy.  Of course, I deleted that check back in January because
    the two sites that would trigger it (glTexImage() and this one) both
    immediately bound their mt to the object, making the other check
    pointless.
    
    Removes two extra blits in glx-tfp.  Also fixed the Android home
    screen, which wasn't rendering because the extra copy broke the
    relationship between the texture and the eglimage.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42152
    Tested-by: Chad Versace <chad@chad-versace.us>
    Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com>


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.