CPU profiles and timeline view both reporting bogus data for WebGL conformance tests |
|||
Issue descriptionWe're trying to profile the new WebGL 2.0 conformance suite as we've found some significant performance problems in it. Both the CPU profiles and the Timeline view are displaying data that makes no sense. To reproduce: 1. Apply the attached patch to src/third_party/webgl/src/ . 2. Run Chrome with --enable-unsafe-es3-apis --allow-file-access-from-files. 3. Browse to .../src/third_party/webgl/src/sdk/tests/deqp/functional/gles3/texturefiltering10.html?webglVersion=2&quiet=0 . The attached patch reduces this page to run only one test of half-float (FP16) textures. The main source file is sdk/tests/deqp/functional/gles3/es3fTextureFilteringTests.js . If you gather a CPU profile with ToT Chromium, you will see that tcuTexture.floatToChannel in sdk/tests/deqp/framework/common/tcuTexture.js is taking considerable time, but the only function that it calls, tcuFloat.numberToHalfFloat from tcuFloat.js in the same directory, takes much less time. This is the first unexplainable result. Second, if you attempt to capture a timeline for this test, it appears that only the test's setup is captured (up to roughly create3DContextWithWrapperThatThrowsOnGLError in sdk/tests/js/webgl-test-utils.js), but not the actual execution of the test. While the test is running, the timeline reports only repeated GCs and not actual CPU execution. Any help diagnosing what's going wrong with the tools would be appreciated. Thanks.
,
Mar 19 2016
Regarding the missing profile in timeline recording. Could you please check if you have "Timeline tracing based JS profiler" experiment turned off.
,
Mar 21 2016
Seems to be caused by heavy inlining. It has 17 functions inlined into channelToFloat: Inlined functions (count = 17) 0x2874c9f4abd1 <SharedFunctionInfo tcuFloat.halfFloatToNumber> 0x2874c9f49491 <SharedFunctionInfo tcuFloat.newDeFloatFromParameters> 0x2874c9f49011 <SharedFunctionInfo tcuFloat.deFloat> 0x2874c9f493d1 <SharedFunctionInfo tcuFloat.deFloat.deFloatParameters> 0x2874c9f3d831 <SharedFunctionInfo deMath.numberToArray> 0x29e2bdf66659 <SharedFunctionInfo get length> 0x2874c9f4a211 <SharedFunctionInfo tcuFloat.deFloat.getValue> 0x2874c9f49a91 <SharedFunctionInfo tcuFloat.deFloat.mantissa> 0x2874c9f49cd1 <SharedFunctionInfo tcuFloat.deFloat.isZero> 0x2874c9f49791 <SharedFunctionInfo tcuFloat.deFloat.exponentBits> 0x2874c9f49851 <SharedFunctionInfo tcuFloat.deFloat.mantissaBits> 0x2874c9f49d91 <SharedFunctionInfo tcuFloat.deFloat.isDenorm> 0x2874c9f49551 <SharedFunctionInfo tcuFloat.deFloat.getBitRange> 0x2874c9f3dbf1 <SharedFunctionInfo deMath.binaryOp> 0x2874c9f3bbb1 <SharedFunctionInfo deMath.deInRange32> 0x2874c9f3d9b1 <SharedFunctionInfo deMath.split32> 0x2874c9f3db31 <SharedFunctionInfo deMath.doNativeBinaryOp> So besides tcuFloat.halfFloatToNumber there is a number of functions execution get attributed to channelToFloat.
,
Mar 21 2016
Where is "Timeline tracing based JS profiler"? I don't see it in about:flags
,
Mar 21 2016
"Timeline tracing based JS profiler" is in DevTools experiments, but if you ask you probably didn't enable it. ;-)
,
Mar 23 2016
When I pass in "--js-flags=--no-use-inlining", that affects the perf, does it? Is there a non-intrusive way to gather the data?
,
Mar 23 2016
Yes, it does. I just suggested it as a workaround. I thought it's better to have this as a rough estimation, rather than nothing. At the moment I don't see another way to collect the data.
,
Mar 23 2016
Got it. Thanks for looking into this. I think with rough estimation we can already pin point the inefficiencies and optimize them.
,
Oct 5 2017
Bulk DevTools triage, closing low priority issues with no action plan. |
|||
►
Sign in to add a comment |
|||
Comment 1 by zmo@chromium.org
, Mar 18 2016Status: Assigned (was: Untriaged)