[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Public WebGL] async shader compiliation
The current state of affairs in regards to shader compilation is unacceptable for the following reasons:
- Shader compilation can take considerable time
- Shader compilation freezes the tab/js thread
- Shader compilation freezes scene rendering
The reasons for why shader compilation is slow can be:
- The D3D compiler takes up a lot of CPU time
- The GL driver takes up a lot of CPU time
In the first case of the D3D compiler, neither the js thread nor the rendering would need to be paused, because it is purely CPU bound and independent of the GPU command queue. The worst shader compile times are usually observed on the ANGLE backend anyway, and so addressing this satisfactory would improve things a lot.
In the second case of the GL driver taking up a lot of CPU time the situation is more complicated. It would not need to block the JS thread, but it would need to block rendering as the GL drivers compile operation is inside the GL command queue.
There are therefore two interpretations of asynchronous compilation:
- Compilation is independent of the command queue and shaders may become available independently of command queue completion. There is currently no API that can satisfy this situation.
- Compilation is coupled to the command queue and shaders block rendering (but not the js thread), for this case there is currently an API available to deal with that situation and that is wait/fence.
For the sake of solving all usecases, also the ones that can upgrade to better behavior over the GL-driver command queue coupled compilation, it would therefore be preferrable to come up with a completion primitive that can interact with WebGL independently of the command queue, but would not require managing micro-state completion (a callback for every shader), as shader compilation would still be in some sort of queue, just not one coupled to the command queue.
I'd propose we introduce a webgl specific wait/fence that follows the semantic of traditional wait/fence, but only applies to *async entry points that are not scheduled into the usual command queue. So to speak it would be a wait/fence for a second, independent, command queue for asynchronous commands the UA can complete (possibly independently) of the GL command queue. In the case that it can't, its behavior would be idempotent with the GL specific wait/fence, but in the case that it can, it wouldn't be identical and can complete before/after the GL specific wait/fence completes.