Resource sharing between GL contexts is a prerequisite for creating open worlds and other WebGL scenes where the assets are streamed in real-time. The WEBGL_shared_resources extension enables this by allowing Web Workers to asynchronously stream textures, stream vertex information, compile textures, and create procedural assets. WEBGL_shared_resources allow these assets created in the WebWorker to be later used in other contexts as a zero-copy operation. Without the ability to share contexts, the GPU drive must upload assets synchronously. Many assets will take more than a single frame to upload, resulting in unavoidable frame skipping. GPU drivers provide access to asynchronous DMA transfer pipelines that otherwise are inaccessible by WebGL content. In the case of WebVR content, we can not show a static loading screen to hide the jank that occurs while streaming content to the GPU, making this especially important for that use case.
Proposal is here: http://www.khronos.org/webgl/wiki/SharedResouces
The capability is somewhat critical for smooth WebVR experiences. Dropping frames is VERY bad in VR and can/does make people sick. Any textures bigger than 512x512 take too long to upload, and shader compilation takes forever as you have to wait for GPU/CPU sync to read back the attribute locations. Without a non-blocking way to upload assets, we can sometimes load up all the shaders, geometry and textures before entering VR to avoid skipping frames. But we can't always predict what we'll need, and very often it's necessary or at least beneficial to begin the VR experience before all resources have arrived from the network. This could be a huge advantage of WebVR over native game engines that usually require huge downloaded installations before beginning. This will become particularly critical as the WebVR spec evolves to allow linking directly to other web pages without coming out of VR. WebVR pages will need to begin rendering at 60, 75 or 90 fps immediately and consistently (even if it's just a loading screen).
You need to log in before you can comment on or make changes to this bug.