Optimize WebGL function calls #16679

MortimerGoro · 2017-05-01T18:40:58Z

I measured the cost of calling some WebGL methods from JavaScript and they are slower compared to Firefox or Chrome. It seems that one of the bottlenecks is the ipc-channel. Current Servo WebGL implementation uses two ipc-channel layers: DOM<=>WebGLPaintThread and WebGLPaintThread<=>Webrender.

This PR replaces the first DOM<=>WebGLPaintThread ipc-channel with a faster mpsc:channel. This doesn't give untrusted content access to the GPU to DOM because the WebGLContexts are still owned by WebRender and the real render messages still sent through the second ipc-channel.

With this change the inmediate cost of simple WebGL method calls are closer to what we see in Firefox or Chrome. Example with measured times on a Desktop linux:

New version, 200 webgl.clearColor calls. Frame times in milliseconds.

0.07886199999938981
0.0779819999997926
0.04238999999961379
0.04007799999999406
0.08114899999964109
0.07670300000063435
0.08235400000012305
0.07708800000000338
0.08082799999920098
0.08204200000000128
0.08140400000047521
0.08121699999992416
0.0797919999995429

Old version, 200 webgl.clearColor calls. Frame times in milliseconds.

0.9031110000000808
0.8622270000000753
0.9009390000001076
0.8202759999999216
0.848363000000063
0.8556140000000596
0.8366560000004029
0.864226000000599
0.8818160000000717
0.8485639999998966
0.9495310000002064
0.8295939999998154
0.8321460000006482

./mach build -d does not report any errors
./mach test-tidy does not report any errors
These changes fix #__ (github issue number if applicable).

There are tests for these changes OR
These changes do not require tests because _____

This change is

highfive · 2017-05-01T18:41:03Z

Heads up! This PR modifies the following files:

@asajeffrey: components/constellation/lib.rs, components/constellation/Cargo.toml, components/constellation/constellation.rs
@KiChjang: components/script/dom/vrdisplay.rs, components/script/dom/webglframebuffer.rs, components/script/dom/htmlcanvaselement.rs, components/script_traits/lib.rs, components/script_traits/lib.rs and 15 more
@fitzgen: components/script/dom/vrdisplay.rs, components/script/dom/webglframebuffer.rs, components/script/dom/htmlcanvaselement.rs, components/script_traits/lib.rs, components/script_traits/lib.rs and 15 more
@emilio: components/layout/display_list_builder.rs, components/script/dom/webglframebuffer.rs, components/canvas/webgl_paint_thread.rs, components/script/dom/webglrenderbuffer.rs, components/script/dom/webglprogram.rs and 5 more

highfive · 2017-05-01T18:41:04Z

Warning

These commits modify unsafe code. Please review it carefully!
These commits modify layout and script code, but no tests are modified. Please consider adding a test!

jdm · 2017-05-01T18:51:38Z

@bors-servo: try

bors-servo · 2017-05-01T18:51:42Z

⌛ Trying commit 8b79360 with merge 2e644b3...


        Auto merge of #16679 - MortimerGoro:webgl_channel, r=<try>

Optimize WebGL function calls  I measured the cost of calling some WebGL methods from JavaScript and they are slower compared to Firefox or Chrome. It seems that one of the bottlenecks is the ipc-channel. Current Servo WebGL implementation uses two ipc-channel layers: DOM<=>WebGLPaintThread and WebGLPaintThread<=>Webrender. This PR replaces the first DOM<=>WebGLPaintThread ipc-channel with a faster mpsc:channel. This doesn't give untrusted content access to the GPU to DOM because the WebGLContexts are still owned by WebRender and the real render messages still sent through the second ipc-channel. With this change the inmediate cost of simple WebGL method calls are closer to what we see in Firefox or Chrome. Example with measured times on a Desktop linux: New version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.07886199999938981 0.0779819999997926 0.04238999999961379 0.04007799999999406 0.08114899999964109 0.07670300000063435 0.08235400000012305 0.07708800000000338 0.08082799999920098 0.08204200000000128 0.08140400000047521 0.08121699999992416 0.0797919999995429 ``` Old version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.9031110000000808 0.8622270000000753 0.9009390000001076 0.8202759999999216 0.848363000000063 0.8556140000000596 0.8366560000004029 0.864226000000599 0.8818160000000717 0.8485639999998966 0.9495310000002064 0.8295939999998154 0.8321460000006482 ``` ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [ ] These changes fix #__ (github issue number if applicable).  - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/16679)

bors-servo · 2017-05-01T21:17:28Z

@MortimerGoro: 🔑 Insufficient privileges: and not in try users

bors-servo · 2017-05-01T21:17:48Z

@MortimerGoro: 🔑 Insufficient privileges: and not in try users

MortimerGoro · 2017-05-01T21:19:55Z

@jdm Could you run bors-servo try again? I pushed a minor change just after you ran it and the build stopped

emilio · 2017-05-01T22:09:34Z

@bors-servo try

bors-servo · 2017-05-01T22:09:38Z

⌛ Trying commit 7385420 with merge f4dd338...


        Auto merge of #16679 - MortimerGoro:webgl_channel, r=<try>

Optimize WebGL function calls  I measured the cost of calling some WebGL methods from JavaScript and they are slower compared to Firefox or Chrome. It seems that one of the bottlenecks is the ipc-channel. Current Servo WebGL implementation uses two ipc-channel layers: DOM<=>WebGLPaintThread and WebGLPaintThread<=>Webrender. This PR replaces the first DOM<=>WebGLPaintThread ipc-channel with a faster mpsc:channel. This doesn't give untrusted content access to the GPU to DOM because the WebGLContexts are still owned by WebRender and the real render messages still sent through the second ipc-channel. With this change the inmediate cost of simple WebGL method calls are closer to what we see in Firefox or Chrome. Example with measured times on a Desktop linux: New version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.07886199999938981 0.0779819999997926 0.04238999999961379 0.04007799999999406 0.08114899999964109 0.07670300000063435 0.08235400000012305 0.07708800000000338 0.08082799999920098 0.08204200000000128 0.08140400000047521 0.08121699999992416 0.0797919999995429 ``` Old version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.9031110000000808 0.8622270000000753 0.9009390000001076 0.8202759999999216 0.848363000000063 0.8556140000000596 0.8366560000004029 0.864226000000599 0.8818160000000717 0.8485639999998966 0.9495310000002064 0.8295939999998154 0.8321460000006482 ``` ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [ ] These changes fix #__ (github issue number if applicable).  - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/16679)

emilio · 2017-05-01T22:12:31Z

I believe, btw, that WebGLPaintThreads are supposed to live in the UI process. I'd need to double-check tomorrow, but seems to me that the layer of indirection we could theoretically remove is the WebGLPaintThread <=> WR.

But actually, the paint thread when WR is enabled is just a proxy, so we may be able to avoid creating a WebGLPaintThread entirely when using the WR back-end?

bors-servo · 2017-05-01T23:03:50Z

💔 Test failed - linux-rel-wpt

MortimerGoro · 2017-05-02T11:21:12Z

But actually, the paint thread when WR is enabled is just a proxy, so we may be able to avoid creating a WebGLPaintThread entirely when using the WR back-end?

I thought about removing the WebGLPaintThread too. It seems possible to entirely avoid creating it when WR is enabled. I didn't remove yet because I thought that the thread could help with the ipc-channel serialziation slowness (the slow serialization work is done in background instead of blocking JS).


        Optimize WebGL function calls

MortimerGoro · 2017-05-03T21:29:45Z

Ready for retry. Some tests failed because pixels were upside-down when a webglcanvas is used as source in texImage2D/texSubImage2D. Previously webgl-canvas textImage2D sources were not implemented and all pixels were 0,0,0,0

emilio · 2017-05-03T21:33:12Z

As I said, I think this is conceptually wrong, and the channel we should be avoiding is the WebGLPaintThread <=> WR. @pcwalton can confirm if that's right, since he did the initial multi-process stuff, though.

@bors-servo try

bors-servo · 2017-05-03T21:41:55Z

⌛ Trying commit 9633cae with merge b595f0f...


        Auto merge of #16679 - MortimerGoro:webgl_channel, r=<try>

Optimize WebGL function calls  I measured the cost of calling some WebGL methods from JavaScript and they are slower compared to Firefox or Chrome. It seems that one of the bottlenecks is the ipc-channel. Current Servo WebGL implementation uses two ipc-channel layers: DOM<=>WebGLPaintThread and WebGLPaintThread<=>Webrender. This PR replaces the first DOM<=>WebGLPaintThread ipc-channel with a faster mpsc:channel. This doesn't give untrusted content access to the GPU to DOM because the WebGLContexts are still owned by WebRender and the real render messages still sent through the second ipc-channel. With this change the inmediate cost of simple WebGL method calls are closer to what we see in Firefox or Chrome. Example with measured times on a Desktop linux: New version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.07886199999938981 0.0779819999997926 0.04238999999961379 0.04007799999999406 0.08114899999964109 0.07670300000063435 0.08235400000012305 0.07708800000000338 0.08082799999920098 0.08204200000000128 0.08140400000047521 0.08121699999992416 0.0797919999995429 ``` Old version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.9031110000000808 0.8622270000000753 0.9009390000001076 0.8202759999999216 0.848363000000063 0.8556140000000596 0.8366560000004029 0.864226000000599 0.8818160000000717 0.8485639999998966 0.9495310000002064 0.8295939999998154 0.8321460000006482 ``` ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [ ] These changes fix #__ (github issue number if applicable).  - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/16679)

MortimerGoro · 2017-05-03T21:57:53Z

As I said, I think this is conceptually wrong, and the channel we should be avoiding is the WebGLPaintThread <=> WR. @pcwalton can confirm if that's right, since he did the initial multi-process stuff, though.

I'd love to get rid of WebGLPaintThread. As I said with this PR the WebGLPaintThread is really only used as a "helper" thread to avoid blocking JS thread with serialization work. I measured the JS raf time in some Three.js demo and it has some impact. If there is a way to improve this I don't mind rewriting the code to remove WebGLPaintThread, for example:

I saw that bincode-based IPC landed in webrender, can this help?
Batching WebGL calls and serialize/send some of them at once may help

bors-servo · 2017-05-04T08:29:18Z

💥 Test timed out

jdm · 2017-05-04T13:27:43Z

@bors-servo: try

wafflespeanut · 2017-05-11T07:23:20Z

@bors-servo try

jdm · 2017-05-11T12:52:02Z

@bors-servo: retry

bors-servo · 2017-05-11T12:52:07Z

⌛ Trying commit 9633cae with merge bc79baa...


        Auto merge of #16679 - MortimerGoro:webgl_channel, r=<try>

Optimize WebGL function calls  I measured the cost of calling some WebGL methods from JavaScript and they are slower compared to Firefox or Chrome. It seems that one of the bottlenecks is the ipc-channel. Current Servo WebGL implementation uses two ipc-channel layers: DOM<=>WebGLPaintThread and WebGLPaintThread<=>Webrender. This PR replaces the first DOM<=>WebGLPaintThread ipc-channel with a faster mpsc:channel. This doesn't give untrusted content access to the GPU to DOM because the WebGLContexts are still owned by WebRender and the real render messages still sent through the second ipc-channel. With this change the inmediate cost of simple WebGL method calls are closer to what we see in Firefox or Chrome. Example with measured times on a Desktop linux: New version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.07886199999938981 0.0779819999997926 0.04238999999961379 0.04007799999999406 0.08114899999964109 0.07670300000063435 0.08235400000012305 0.07708800000000338 0.08082799999920098 0.08204200000000128 0.08140400000047521 0.08121699999992416 0.0797919999995429 ``` Old version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.9031110000000808 0.8622270000000753 0.9009390000001076 0.8202759999999216 0.848363000000063 0.8556140000000596 0.8366560000004029 0.864226000000599 0.8818160000000717 0.8485639999998966 0.9495310000002064 0.8295939999998154 0.8321460000006482 ``` ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [ ] These changes fix #__ (github issue number if applicable).  - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/16679)

bors-servo · 2017-05-11T12:57:25Z

💔 Test failed - linux-dev

MortimerGoro · 2017-05-12T21:45:42Z

Compiling parking_lot_core v0.2.1
LLVM ERROR: Invalid data was encountered while parsing the file
error: Could not compile `parking_lot_core`.
Build failed, waiting for other jobs to finish...
error: build failed

jdm · 2017-05-12T23:21:21Z

@bors-servo: retry

bors-servo · 2017-05-12T23:21:25Z

⌛ Trying commit 9633cae with merge 55ba4af...


        Auto merge of #16679 - MortimerGoro:webgl_channel, r=<try>

Optimize WebGL function calls  I measured the cost of calling some WebGL methods from JavaScript and they are slower compared to Firefox or Chrome. It seems that one of the bottlenecks is the ipc-channel. Current Servo WebGL implementation uses two ipc-channel layers: DOM<=>WebGLPaintThread and WebGLPaintThread<=>Webrender. This PR replaces the first DOM<=>WebGLPaintThread ipc-channel with a faster mpsc:channel. This doesn't give untrusted content access to the GPU to DOM because the WebGLContexts are still owned by WebRender and the real render messages still sent through the second ipc-channel. With this change the inmediate cost of simple WebGL method calls are closer to what we see in Firefox or Chrome. Example with measured times on a Desktop linux: New version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.07886199999938981 0.0779819999997926 0.04238999999961379 0.04007799999999406 0.08114899999964109 0.07670300000063435 0.08235400000012305 0.07708800000000338 0.08082799999920098 0.08204200000000128 0.08140400000047521 0.08121699999992416 0.0797919999995429 ``` Old version, 200 webgl.clearColor calls. Frame times in milliseconds. ``` 0.9031110000000808 0.8622270000000753 0.9009390000001076 0.8202759999999216 0.848363000000063 0.8556140000000596 0.8366560000004029 0.864226000000599 0.8818160000000717 0.8485639999998966 0.9495310000002064 0.8295939999998154 0.8321460000006482 ``` ---  - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [ ] These changes fix #__ (github issue number if applicable).  - [x] There are tests for these changes OR - [ ] These changes do not require tests because _____    --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/16679)

bors-servo · 2017-05-12T23:52:09Z

💔 Test failed - linux-rel-wpt

bors-servo · 2017-05-19T07:16:46Z

☔ The latest upstream changes (presumably #16893) made this pull request unmergeable. Please resolve the merge conflicts.

jdm · 2017-08-15T21:27:02Z

@MortimerGoro Is this separate from #17891, or is this work replaced by that PR?

MortimerGoro · 2017-08-15T21:29:44Z

@jdm yes, totally replaced. This can be closed.

highfive assigned wafflespeanut May 1, 2017

highfive added the S-awaiting-review label May 1, 2017

MortimerGoro force-pushed the MortimerGoro:webgl_channel branch from 8b79360 to 7385420 May 1, 2017

highfive added the S-tests-failed label May 1, 2017

Optimize WebGL function calls

Loading status checks…

9633cae

MortimerGoro force-pushed the MortimerGoro:webgl_channel branch from 7385420 to 9633cae May 3, 2017

highfive removed the S-tests-failed label May 3, 2017

highfive added the S-tests-failed label May 11, 2017

highfive added the S-tests-failed label May 12, 2017

highfive added the S-needs-rebase label May 19, 2017

jdm assigned jdm and unassigned wafflespeanut Aug 1, 2017

MortimerGoro closed this Aug 15, 2017

servo / servo

Optimize WebGL function calls #16679

Optimize WebGL function calls #16679

MortimerGoro commented May 1, 2017 •

edited by larsbergstrom

highfive commented May 1, 2017

highfive commented May 1, 2017

jdm commented May 1, 2017

bors-servo commented May 1, 2017

bors-servo commented May 1, 2017

bors-servo commented May 1, 2017

MortimerGoro commented May 1, 2017

emilio commented May 1, 2017

bors-servo commented May 1, 2017

emilio commented May 1, 2017

bors-servo commented May 1, 2017

MortimerGoro commented May 2, 2017

MortimerGoro commented May 3, 2017 •

edited

emilio commented May 3, 2017

bors-servo commented May 3, 2017

MortimerGoro commented May 3, 2017

bors-servo commented May 4, 2017

jdm commented May 4, 2017

wafflespeanut commented May 11, 2017

jdm commented May 11, 2017

bors-servo commented May 11, 2017

bors-servo commented May 11, 2017

MortimerGoro commented May 12, 2017

jdm commented May 12, 2017

bors-servo commented May 12, 2017

bors-servo commented May 12, 2017

bors-servo commented May 19, 2017

jdm commented Aug 15, 2017

MortimerGoro commented Aug 15, 2017

servo / servo

Join GitHub today

Optimize WebGL function calls #16679

Optimize WebGL function calls #16679

Conversation

MortimerGoro commented May 1, 2017 • edited by larsbergstrom

highfive commented May 1, 2017

highfive commented May 1, 2017

jdm commented May 1, 2017

bors-servo commented May 1, 2017

bors-servo commented May 1, 2017

bors-servo commented May 1, 2017

MortimerGoro commented May 1, 2017

emilio commented May 1, 2017

bors-servo commented May 1, 2017

emilio commented May 1, 2017

bors-servo commented May 1, 2017

MortimerGoro commented May 2, 2017

MortimerGoro commented May 3, 2017 • edited

emilio commented May 3, 2017

bors-servo commented May 3, 2017

MortimerGoro commented May 3, 2017

bors-servo commented May 4, 2017

jdm commented May 4, 2017

wafflespeanut commented May 11, 2017

jdm commented May 11, 2017

bors-servo commented May 11, 2017

bors-servo commented May 11, 2017

MortimerGoro commented May 12, 2017

jdm commented May 12, 2017

bors-servo commented May 12, 2017

bors-servo commented May 12, 2017

bors-servo commented May 19, 2017

jdm commented Aug 15, 2017

MortimerGoro commented Aug 15, 2017

MortimerGoro commented May 1, 2017 •

edited by larsbergstrom

MortimerGoro commented May 3, 2017 •

edited