[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] ESSL -> HLSL -> cso, do we really need to do this?

On Mon, Feb 4, 2013 at 10:38 AM, Florian Bösch <pyalot@gmail.com> wrote:
On Mon, Feb 4, 2013 at 7:31 PM, Kenneth Russell <kbr@google.com> wrote:
Florian, would it be OK with you if I post the shader here?
Jep that's OK. Go ahead. 
Florian's shader has been added to the top of tree WebGL conformance
suite as https://www.khronos.org/registry/webgl/sdk/tests/conformance/glsl/misc/large-loop-compile.html
. Its eventual inclusion will have to be debated among members of the
working group, but it seems to me that even if compilation of the
shader has to fail, that failure should occur in a reasonable period
of time, and the WebGL context shouldn't be lost.
I'm in support of Kens opinion that failure should happen in a reasonable period of time.

Where I probably differ is that I'm of the opinion that a shader that compiles and runs fine trough OpenGL 2.0 on the same machine, shouldn't fail to compile or run on Direct3D 9.0 and it shouldn't take 10x as long to compile.

I'm not convinced the best solution is to lose the context for shaders that take a long time to compile. The browser doesn't kill _javascript_ that takes a long time to run. Instead it just asks the used (this _javascript_ is taking a long time to complete. [continue] [stop])

Maybe there are other solutions.

1) Once we get WebGL in workers you can compile in a worker and not block the main thread

2) The Browser can possibly compile shaders on a separate thread and not block the rest of the GPU pipeline.