Closed
Bug 660322
Opened 13 years ago
Closed 5 years ago
Reduce the amount of time it takes to run the WebGL conformance suite on the tinderboxen
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: ehsan.akhgari, Unassigned)
References
Details
(Whiteboard: webgl-internal)
Attachments
(2 files)
2.36 KB,
patch
|
Details | Diff | Splinter Review | |
9.52 KB,
text/plain
|
Details |
Benoit told me that there are a bunch of things which we can do to reduce the time it takes to run webgl tests, like not running the fuzzing tests on every check-in, and timing each test to see which ones take the longest, and just fixing them.
Comment 1•13 years ago
|
||
This patch measures how much each webgl test page takes. It requests a GC run before each test, to prevent GC pauses from affecting the results (blaming a test page for stuff caused by another page).
Comment 2•13 years ago
|
||
Here are the results, sorted in ascending order, on my linux/NVIDIA system. The median time is 335 ms, and there are 139 test. That means that if we fix the long-running tests, we can hope to get down to roughly 139*0.335 = 45 seconds, which would be a nice improvement. The top ten offenders are: WebGL test page conformance/read-pixels-test.html took 1222 ms WebGL test page conformance/gl-teximage.html took 1297 ms WebGL test page conformance/array-unit-tests.html took 1337 ms WebGL test page conformance/buffer-preserve-test.html took 1341 ms WebGL test page conformance/gl-vertex-attrib.html took 1654 ms WebGL test page conformance/uninitialized-test.html took 1668 ms WebGL test page conformance/type-conversion-test.html took 2778 ms WebGL test page conformance/copy-tex-image-and-sub-image-2d.html took 3092 ms WebGL test page conformance/gl-vertexattribpointer.html took 4956 ms WebGL test page conformance/glsl-conformance.html took 5544 ms
Comment 3•13 years ago
|
||
Note --- that is in a debug build. Not sure which is most interesting to measure here. Currently, the sum of the times taken by all the test pages here is 75 seconds. So we can hope to get from 75 to 45 seconds by fixing the long-running tests. The main reason why WebGL mochitests can't be very fast is that just creating a OpenGL context is very long. On linux, it takes 120 ms with the NVIDIA driver, 50 ms with Mesa and open-source drivers, and 200 ms with the FGLRX driver. Here with the NVIDIA driver, the shortest-running test takes 172 ms.
Comment 4•13 years ago
|
||
Is there no way to reuse the same OpenGL/WebGL context for all the tests?
Comment 5•13 years ago
|
||
It's not impossible, but it would require resetting the OpenGL context to its default state, and there is no OpenGL function for doing that so that would have to be done manually, i.e. hundreds of OpenGL calls. Problems: - that would be a lot of code, potentially buggy, reducing the trust we have in our own tests - that could expose more driver bugs and would open the door to a bug triggered by one test impacting a subsequent test. So, I would avoid doing that if possible.
Comment 7•13 years ago
|
||
Jonathan Griffin gave these interesting timings in bug 673459: win32-debug, 174951 linux-opt, 21012 macosx64-debug, 168473 win32-opt, 24799 linux64-debug, 150304 linux64-opt, 20300 linux-debug, 170302
Comment 8•13 years ago
|
||
I didn't realize that debug test times were so much higher than opt times. That's an interesting new element. It's not clear to me if there's much I can do, since many things in webgl are inherently computation-intensive, but it's interesting at least because it outlines that the incompressible part, spent waiting for the OpenGL implementation, is not that high.
Updated•11 years ago
|
Whiteboard: webgl-internal
Updated•5 years ago
|
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•