Thanks for the explanation Ben and sorry for not being clear - what I meant was that WebGL_shared_resources, without access to WebGL on web workers, is not very useful to us on its own. We're not looking to move our main rendering onto a web worker, just the resource uploads/shader compiles which slow us down in the main thread. From the sounds of what you've written below, what we really need is both of them completed before we'll see any real opportunities for performance improvements in this area.
(If an asynchronous shader compilation extension were a simpler, quick win, on this front - I can't emphasise enough how detrimental synchronous shader compilation is to RuneScape currently - is that something that could be considered as an interim solution?)
Chris: did you mean to say that shared resources would be *more interesting* than WebGL on workers? The things you listed are all benefits of shared resources *and* WebGL on workers, *not* WebGL on workers alone. Without share groups even if running in a worker you'd still have your rendering blocked on shader compilation/linking, long uploads would still steal time from your rendering frames, and since the number of workers you can practically create is limited (resource constraints are very real - workers are very expensive) you wouldn't be able to create many more for doing your texture work. You'd see very little benefit for the engineering overhead of building a transferable command buffer and would add a bunch of negatives like additional latency, data duplication, non-trivial additional memory consumption, etc.
Having designed several rendering engines that used GL share groups in the past, I can say that WebGL in a worker alone is not what most people want (though they don't know that, yet). The additional latency of moving input events to the background thread (we all aren't just spinning cubes, you know) and the inability to properly synchronize DOM elements makes primary rendering in a worker a non-starter in most cases, and in others just makes it significantly more difficult to write code. In real apps it will be required to support both the non-worker case for months/years after this feature starts shipping, and even then maybe for much longer depending on devices (on a 2 core machine running WebGL in a worker would likely not be a gain and may even end up hurting overall system performance) --- keeping those two radically different code paths going is not an interesting prospect for those writing non-trivial code.
So: shared resources doesn't make sense without being able to run WebGL on workers (as who would you share it with?), but WebGL on workers on its own without shared resources is largely useless for large apps targeting low-latency, high performance, resource-intensive applications. I clearly see the implementation dependence between the two features, but I'm fighting against the idea that shared resources isn't useful.
As for implementation of resource sharing, we don't really care so long as it's efficient (accepts batches of objects, etc). Limiting things to just textures/buffers is probably fine as the program compile/link stuff can be done by the browser under the covers, maybe with an additional API for that to enable deterministic completion checking. It's important that objects are not transferred during the sharing, as otherwise there would be a ton of data duplication when trying to fan out rendering with shared buffers or textures and in most cases apps trying to do this stuff are already GPU memory constrained.
On Mon, Jun 24, 2013 at 1:19 AM, Chris Endicott <email@example.com> wrote:
Whilst I think that WEBGL_shared_resources is an interesting feature, as far as our project (RuneScape) goes, availability of WebGL on web workers would be significantly more useful in terms of helping us solve some of our performance issues. In particular:
· Being able to compile and link shaders on web workers would be the single biggest performance gain we could achieve
· Being able to upload resources from web workers direct to WebGL, without serialising them back to the main thread would also be a significant win for us as we construct most of our geometry on web workers
· We would also be able to consider re-architecting other parts of our graphics engine (for example, texture atlasing, sprite management) onto workers to further improve performance
I don't know that the implementation status of either of these features is in Chrome/FireFox right now, but if there were a choice, I would vote strongly in favour of web workers over shared resources in terms of development priority.
Chris (Long time lurker on this mailing list)
On 13-06-21 01:53 PM, Gregg Tavares wrote:
That got me thinking what would it take to make WebGL enforce the sharing rules in the OpenGL spec.
The spec says you must call glFinish (or use a sync object) in the context modifying a resource and then bind or attach that resource in the context you want to see the modification to be guaranteed to be able to see the change.
The problem is many drivers require far less. Some work with glFlush/glBind, Some work with just glFlush, no bind, others require the spec compliant glFInish/glBind. If we could figure out a way to enforce that you must use glFinish(or sync) and glBind in WebGL maybe it would be okay to expose that stuff as is rather than through an extension. For WebGL 1 we'd probably need a SYNC extension for sync objects otherwise so you have an alternative to the slow glFinish.
Thinking about how to implement enforcing the rules.
This seems like it would work? The problems off the top of my head are
1) you can observe behavior in a worker since you can spin call BindXXX or attach until you get success as well as call GetSyncParameter
It seems like it used to be a rule that you shouldn't be able to observe the behavior of a worker but it doesn't seem like people care about that anymore?
2) You can assume your timing works?
One of the things WEBGL_shared_resources was trying to prevent was a situation where you're running at 60fps (or 30fps) and that some resource you modified in one thread will be ready in another by the next frame so you assume it's okay to bind. I don't think this proposal has that problem though. If you called glFinish you can assume bind will work in the other context. If you called FenceSync in one context, bind in another context will not work unless you call WaitSync or ClientWaitSync
I suppose this proposal is not "exactly like OpenGL" but it's spec compliant OpenGL. Native apps that get errors when ported to this code were just getting lucky on the platforms they were running on.