[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL-next
It'll be easier to comment once the spec is actually made public, but broadly agree that it's going to be a challenge to realize a sane and useful web API that follows in the footsteps of any of the next generation of graphics libs. A few thoughts on your specific comments:
Regarding intermediate bytecode for shaders, I don't view this as a problem and actually view it as a positive for the web in general. Aside from being more efficient to process and easier to distribute, by having an bytecode users can develop shaders in whatever language has a compiler available but the web only has to understand one format. That puts us in roughly the same position as we're in with GLSL today, but with a more performance-friendly format. It may prove to be a concern for Shadertoy-like sites that want to compile their shaders on the fly, but with the advent of emscripten we can be reasonably certain that any native compilers that get built can have a JS interface. Also, for the sake of clarity: the compile process shouldn't require a GPU. The bytecode will be standardized and not rely on any GPU specific instructions, so it should be perfectly feasible to run the compilers on any device with a CPU.
Multi-threading: Yeah, this one is going to suck to figure out. There may be a reasonable way to build command buffers in a worker and submit them from the main thread, but I'm not sure. Really we just need to wait till the spec is public to collectively dig into it and see.
API redesign: The bits I find most objectionable about WebGL as it stands today are primarily historical artifacts that have carried through the various API revisions. Things like leftover function arguments (Texture borders!) and the general state-machine design. Khronos is well aware that everyone, from game devs to driver devs, has issues with the current state of things. They also have an awful lot of very intelligent, very experienced people contributing, so have a bit of faith that they won't make a total mess of things. :)
On Sat Jan 17 2015 at 9:25:16 AM Florian Bösch <email@example.com
This is a bit of idle speculation, but some things stood out to me from the Khronos OpenGL-next roadmap:
- Intermediary bytecode shader format
- Multi-threaded render command submission
- complete API redesign
- statelessness and direct access?
I think some of these will be challenges for the web.
Intermediary bytecode shader format
The main problem here is probably that most simple solutions aren't going to work with it (so source fallback needs to exist). Also, most web developers don't use a precompilation step for their sources. The second problem I see here would be a complete lack of tooling to compile shaders on machines that do not have GPUs (as in webservers). I think Khronos needs to do a huge step forward there and produce a compiler that does not rely on a GPU, is available on all platforms, can easily be installed (a minimum of dependencies) and if at all possible, is open source.
Multi-threaded render command submission
Here the web has a problem. We don't have threads. There's WebWorkers, which is great, but they're not threads. Is it worth considering something like WebThreads so that WebGL-next users could make use of this feature?
Complete API redesign
WebGL does its best to dress up the C-origin API of OpenGL and make it nice to use in JS. But even the best falls somewhat flat because it does need to adhere to the specification and it is still a C API.
I think there's a chance that a new standard could offer for a polyglot environment to provide greater leeway in the concrete interpretation of the API language, so as to make it more idiomatic for any given target.