[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Issues with sharing resources across contexts
All of them ;)
Almost every use case of WebGL on workers needs mutable resources.
The primary ones I've used in the past (and would love to use in WebGL with workers) is modifying buffer data in various worker threads. You always want to pool the buffers and double (or triple) buffer them when rendering. They may be populated on one worker and drawn on another (or the main thread). Same with textures in the case of either a render-to-texture done on a worker or a plain old upload, or the reverse of reading back the framebuffer on another worker for JS processing.
These cases would be possible with ownership transfer, and transferable arrays has shown that it's an easy concept to wrap ones head around and works well.
One thing that would suffer, though, is the case of multiple readers. I may want to do some readback of a texture for GPGPU data, and could imagine sending that texture to multiple workers - each worker would then readPixels a separate region of the texture.
The other thing that suffers with single ownership is reusing shared resources (shaders/buffers/textures) - I can imagine (and want) many cases where I'd have multiple workers rendering the same scene in different ways - whether it's a visualization tool or a game that does things like GPGPU occlusion culling in one worker and real rendering in another. Or megatexture processing using the same geometry buffers in one worker, readback of the framebuffer for processing in another, texture uploads in yet another, and final scene rendering on the main thread. If I had to duplicate all of my level geometry, rerun my CPU skinning, process my particle systems, and consume Nx as much GPU memory for each worker I'd be disappointed - especially on embedded devices.
Hmm... I feel like an acquisition model probably makes the most sense for these cases, although it's a bit more complex...
- pass webgl resources to other workers like transferrable arrays (as additional args to postMessage)
- a resource is not usable once received until acquired
- some WebGLRenderingContext (or extension methods) to work with the objects:
- acquireResource(obj, mode [READ_ONLY, READ_WRITE]) --> returns whether acquired
- if you try to read or write an unacquired object, fail at API level
- if you try to write to a read only object, fail at API level
- multiple readers are allowed, only one writer
This allows multiple workers to render the same objects (all acquire as read only), removes the required implicit flush, and substitutes an explicit flush (an acquire for reading of a dirty object could flush, if that was tracked). Performance-wise most apps would likely acquire as read only once and never have to worry about it again (no synchronization across workers required), It's also not magic - meaning that it may require a few more calls, but it's very clear what's happening and why, and it's not possible to fall into some undiscoverable (or unavoidable) performance trap with implicit flushes.