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

Re: [Public WebGL] async shader compiliation



This was abandoned in favor of a set of smaller shaders, chosen and loaded according to the fixed-function state in use.

This is pretty much what we do, and many other nowadays uber shader systems do: they make shader code based on provided arguments.
For example if only diffuseMap is used, then shader will be very simple. If diffuseMap + PBR used, it will get a bit more complicated, and so on. Some of things are driven by uniforms where possible, for example intensity for colour or opacity. But some will lead to shader re-generation, like availability of certain texture on material. So shaders include only what is used by material and specific mesh being rendered with that material.

Ubershader - is pretty much the only way to go decent with Forward Renderer.

We do need async shader compilation, but more we need is faster shader compilation in first place.

Cheers,
Max

On 1 March 2017 at 10:04, Mark Callow <khronos@callow.im> wrote:

On Feb 28, 2017, at 1:21, Maksims Mihejevs <max@playcanvas.com> wrote:

 (if they are ubershaders)

Throughout the time I’ve been working with OpenGL ES 2+, ubershaders have generally been regarded as something to avoid. At the dawn of OpenGL ES 2 the concern was whether such shaders could be compiled and would fit in the available memory of the devices of those days. There was also concern about introducing lots of extra tests and branches for every vertex or fragment. The first example of an “ubershader” was a shader to mimic the OpenGL ES 1 fixed-function pipeline. This was abandoned in favor of a set of smaller shaders, chosen and loaded according to the fixed-function state in use. As far as I know this was the model adopted by all IHV’s who provided OpenGL ES 1 support on their OpenGL ES 2 parts.

To avoid doubt, let me state that I am not trying to downplay the importance of async shader compilation.

Regards

    -Mark