1072935 - 314% windows regression in gl terrain on inound (v.35) on Sept 25 from rev 8bba4620826b

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

in bug 1048108 a patch was landed that affects win 7 and win 8 talos GL Terrain test:
http://graphs.mozilla.org/graph.html#tests=%5B%5B325,131,31%5D,%5B325,131,25%5D%5D&sel=none&displayrange=30&datatype=running

Here is some information about the test:
https://wiki.mozilla.org/Buildbot/Talos/Tests#glterrain

As graph server has not generated all the alerts yet, I assume this is all the effects related to this change.  I did check the other platforms and they didn't regress on this test.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

Jeff, can you take a look at this?

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

the offending test appears to be:
1.WebGL-terrain-alpha-no-AA-yes

Comment 3

[Avi Halachmi (:avih)]

https://tbpl.mozilla.org/?tree=Try&rev=8bba4620826b is full of build errors, so I looked at some recent test logs, and I think the issue is with both 

1.WebGL-terrain-alpha-no-AA-yes
2.WebGL-terrain-alpha-no-AA-no

Where both of them show average frame interval of ~40ms, while the other two tests are at ~4-5 ms. It doesn't look like it's broken, just considerably slower.

Full run log: https://tbpl.mozilla.org/php/getParsedLog.php?id=48869284&tree=Mozilla-Central&full=1

ANGLE was updated recently, and vladv mentioned it renders stuff incorrectly - bug 1036068 comment 53.

This could be related.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

This looks suspicious. We should probably back it out and investigate.

Comment 5

[Avi Halachmi (:avih)]

Just a note that you can run the test in your browser by visiting http://hg.mozilla.org/build/talos/raw-file/tip/talos/page_load_test/webgl/benchmarks/terrain/perftest.html . It displays the results when the animations finish.

According to the numbers, the first two animation cycles are slower than the other two.

With default Firefox settings it will not iterate faster than 16.7 ms / frame, but you can set layout.frame_rate=0 for ASAP/vsync-off to override this limit.

Comment 6

[Avi Halachmi (:avih)]

I just tried the page from comment 5 with latest official nightly (Sep 25th) on Windows 8.1 and HD4400 and it seems fine (window at 1024x768, results were 2.4  4.5  2.9  4.1). I'm guessing tomorrow's official Nightly should show the issue.

Comment 7

[Kelsey Gilbert [:jgilbert]]

Yeah, we fell off the ANGLE fast-path for no-alpha canvases. I'm investigating.

Comment 8

[Jukka Jylänki]

Something I find odd with the slow path is that geckoprofiler.xpi profile shows that excessive time is being spent inside the ftol function, converting float values to int: https://dl.dropboxusercontent.com/u/40949268/emcc/bugs/ff_nightly_cleopatra.png

That raises an alarm bell. Slow path is slow path, but what data is there as floating point to start with? Is the backbuffer a floating point buffer in the slow path? and glReadPixels is converting each pixel from float to RGBA8? If so, then that is very excessive, I don't think we should be rendering to a floating point render target by default, that is very GPU-heavy especially for low end systems. Is that accurate?

Comment 9

[Kelsey Gilbert [:jgilbert]]

(In reply to Jukka Jylänki from comment #8)
> Something I find odd with the slow path is that geckoprofiler.xpi profile
> shows that excessive time is being spent inside the ftol function,
> converting float values to int:
> https://dl.dropboxusercontent.com/u/40949268/emcc/bugs/ff_nightly_cleopatra.
> png
> 
> That raises an alarm bell. Slow path is slow path, but what data is there as
> floating point to start with? Is the backbuffer a floating point buffer in
> the slow path? and glReadPixels is converting each pixel from float to
> RGBA8? If so, then that is very excessive, I don't think we should be
> rendering to a floating point render target by default, that is very
> GPU-heavy especially for low end systems. Is that accurate?

ANGLE doesn't prioritize the speed of readback. If the formats aren't directly compatible, it reverts to reading in a float[4] pixel, even if it's reading from a uint8_t[4] and will be writing it out as uint8_t[4].

Comment 10

[Jukka Jylänki]

Jeff, do you know what the mismatching types are in this case?

Comment 11

[Kelsey Gilbert [:jgilbert]]

(In reply to Jukka Jylänki from comment #10)
> Jeff, do you know what the mismatching types are in this case?

It depends on how we do readback. It's really not important until we're focusing on XP perf, and even then, we have different code for this which will be landing soon.

Comment 12

[Joel Maher ( :jmaher ) (UTC -8)]

this is well over 6 months with no activity- we have already shipped with this.