[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL-next
To expand a bit on the topic of shader combinatorics. I've previously wielded this argumentation to encourage vendors to make compilation of shaders faster (and it improved a lot, sadly it's still slower than just about any compiler I know of). I'm now wielding the same club to encourage thought about making sure to preserve old advantages, while helping to build new ones (bytecode).
I'm sure OpenGL-next will introduce a lot of handy functionality to avoid having to combine shaders at source level. At the same time, not everything that needs to be configured can always be abstracted into a set of function symbols. There's always going to be cases where combinatoric changes to the shader are required. The first and foremost way to make these changes, is to recombine pieces of shader source on the client.
Bytecode is very welcome for other usecases, and it needs to be supported extremely well. And if the bytecode compiler/tool wants to offer features making combinatorics easier, all the better. But source delivery has to work, always.