On Fri, Mar 3, 2017 at 12:36 PM, <kgilb...@mozilla.com> wrote: > Hi Ehsan! > > I believe all IPC messages can be changed to async except GetSensorState > and SubmitFrame. We cache the results from GetSensorState and re-use it > until the next frame. >
Hmm, not sure if I understand correctly. Did you actually mean "except" there? If we can't guarantee to be able to return the result of GetSensorState in the same frame as when it was requested in (which is the case on Nightly right now), caching it for the rest of the frame duration should be the least of our worries... > I would like to do some changes to how IPC in WebVR works... > > First, I'd like to move the parent side of PVRManager to its own thread or > possibly a dedicated process. WebVR can be impacted by busy message > queues. PVRManager is already a top-level protocol and the methods on the > parent side are self contained in preparation for this. > You probably want PBackground for this purpose, although if you're planning to communicate with the background parent actor synchronously that may not end up being good enough either. A separate process sounds overkill, and probably opens the door to solving more problems that you can probably avoid solving (such as dealing with the additional memory usage of a helper process.) > Secondly, we may benefit from using another IPC mechanism for sharing > per-frame state, which is updating at 90hz and broadcasting the same > information to multiple children. A fundamental difference with WebVR is > that children are interested in getting the latest state rather than state > in a serial fashion. A carefully fenced or double buffered structure (like > Chromium's gamepad IPC) may provide the low latency, nom-blocking IPC here. > Is this something we can use shared memory for? Or would the cost of locking access to the shared memory undo the benefits? > For the near-term, I would like to make sure all messages that occur > outside of WebVR presentation Sorry, I'm not familiar with all of the terminology here. Which messages are those, and what parts of WebVR would still use synchronous IPC communication with your suggestion? > (ie GetDisplays) are async first, then work on a different IPC mechanism > and move WebVR's messages into another parent thread / queue.. Would this > make sense? > My first suggestion is to gather some profiles of some WebVR test runs to get a better sense of what the current situation looks like. Still it seems to me that we shouldn't have any sync IPC on the path of the DOM APIs that are exposed to the page. Cheers, Ehsan > Thanks for the feedback! > > Cheers, > - Kip > > > On Mar 3, 2017, at 6:47 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > > > > Hi Kearwood, > > > > I and a few other engineers have been studying the performance of > > Firefox for several weeks now as part of the Quantum Flow project and > > one of the serious performance issues that we have been finding in > > various parts of the browser have been synchronous IPC messages sent > > from the content process to the parent process. We are tracking the > > overall issue in bug 1331674, and I had seen WebVR sync IPC messages > > come up in our measurements as being particularly bad but unfortunately > > I hadn't gotten a chance to file a bug yet because I didn't realize > > WebVR is close to being shipped, so sorry for the last minute alarm, but > > what is our performance story for WebVR? We have some telemetry probe > > that suggest that some of the DOM APIs that we expose can potentially > > blow away your entire frame budget. For example, > > PVRManager::Msg_GetSensorState (which, as far as I can tell is how we > > implement VRDisplay.getFrameData() and VRDisplay.getPose()) is one of > > the slowest ones. On Nightly, more than 50% of the calls to this > > synchronous IPC take between 8 to 20ms. This means calling one WebVR > > API currently can run the risk of blowing away your entire frame budget. > > I have filed bug 1344216 for this. > > > > I don't have any VR hardware myself so I have done no profiling myself, > > but what is our performance story here? I think the current > > implementation strategy of sending synchronous messages to the parent > > process isn't going to be viable long term, and honestly it seems to me > > that for WebVR specifically it may not even be good enough for a first > > implementation. Do you have some Gecko Profiler profiles to share, > > ideally from lower end hardware that can run VR demos so that we can get > > a sense of what the performance of Gecko on a VR workload looks like? > > Has there been though of other implementation strategies? > > > > (FWIW it has recently became quite clear that sync IPC messages can be > > *much* worse than sync IO even, we have seen many profiles where sync > > IPC messages can easily take *seconds*, so even if they show up as super > > fast on a fast machine when the machine isn't under load, they can > > essentially take an arbitrary long amount of time in less ideal cases... > > I myself have certainly been guilty of adding a fair number of sync IPC > > messages before measuring how bad they are in practice.) > > > > Thanks, > > Ehsan > > > >> On 2017-03-01 3:50 PM, kgilb...@mozilla.com wrote: > >> As of March 1, 2017 I intend to turn WebVR on by default on Windows. > It has been developed behind the dom.vr.enabled preference and has been > enabled by default on Firefox Nightly and Dev Edition since November 2015. > Other UAs shipping this include Samsung Internet Browser (Gear VR) and > Oculus Carmel. Microsoft Edge and Google Chrome are also intending to > ship. Google Chrome has enabled WebVR on Android with an Origin Trial. > >> > >> This feature was previously discussed in this "intent to ship" thread, > for non-release builds: > >> > >> https://groups.google.com/d/topic/mozilla.dev.platform/ > BeVaHGEgZNA/discussion > >> > >> Bug to turn on by default: > >> > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1343368 > >> > >> We will support Oculus and HTC Vive by default. Oculus is already > enabled; HTC Vive support with OpenVR has been developed behind the > “dom.vr.openvr.enabled” preference and will be turned on with this bug: > >> > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1343374 > >> > >> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/ > >> > >> Since the initial implementation, a W3C working group was formed > including members from Mozilla, Google, Microsoft, Samsung, and Oculus. > The API has stabilized and is frozen at "WebVR 1.1" while its successor > "WebVR 2.0" is being conceived. > >> > >> Windows only support for WebVR would be enabled by default in Firefox > 54. OSX is not yet supported by current VR headsets. Beta Linux support > for HTC Vive has very recently landed, and will be supported by Firefox > after the Firefox 54 uplift. > >> > >> Cheers, > >> Kearwood “Kip” Gilbert > >> :kip > >> > >> _______________________________________________ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-platform > >> > > > -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
