Re: [css-shaders] GLSL implementation defined limits

From: Chris Marrin <cmarrin@apple.com<mailto:cmarrin@apple.com>>
Date: Mon, 14 Nov 2011 06:12:17 -0800
To: Gregg Tavares <gman@google.com<mailto:gman@google.com>>
Cc: Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>, "public-fx@w3.org<mailto:public-fx@w3.org>" <public-fx@w3.org<mailto:public-fx@w3.org>>
Subject: Re: [css-shaders] GLSL implementation defined limits


On Nov 13, 2011, at 10:55 PM, Gregg Tavares (wrk) wrote:



...>> If we agree that a shader failing to compile is the problem to address, I am not sure if we actually need something else. I think it is conceptually similar to an improperly encoded image: the user agent gets the resource and at the time of processing, is not able to use it for some reason. The resource is deemed invalid. So a compilation error would be the same, in my mind, as if the shader was pointing to, say, a video, an HTML or SVG file, for example, which are all invalid shader code. I think the fail-over is the same and, as proposed in the draft, the effect is as if no shader was specified. May be what we should add to the spec. is that in the case two shaders are specified, a failure in one of them causes both to be ignored, since as you pointed out in an earlier email, shaders work hand in hand, and it typically does not make sense to keep one of the other fails.


That case we are talking above is when the shader IS valid. It just fails on low-end hardware. That's the point we are trying to address. It's easy to write a valid shader the runs on high-end hardware but fails on low-end hardware. You have no way to know that except to try them.

I believe the only issue we can possibly handle is a failure of the shader PROGRAM to load. That can mean shaders failing to compile, vertex attribs or uniforms failing to assign or program failing to link. If it makes it through all those steps, the program is supposedly able to run on that hardware. One of those steps will fail on "low-end" hardware if the shaders are too big or some resource limit has been exceeded. The only thing that won't catch is the shader taking too long to run and causing a bus reset or the equivalent of a WebGL context lost. I see no way we could ever catch such a case because it's not even clear it would always fail on a given piece of hardware. It depends on so many factors such as GPU memory, texture size and even transformed vertex or texture coordinate size.

This case is unprecedented in HTML. Even with unsupported image formats, you know they're unsupported at load time. I don't see how we could ever handle this case.


So, If a developer makes a page that uses 3 valid shaders and on some hardware out there 1 of them fails because of that hardware's limitations, how is the developer supposed to deal with this? It's especially an issue if the effect the developer is trying to achieve requires that all effects 3 work together. The developer needs a way to either check that all 3 worked, or a way to say check if any one of them failed they should all fail so the page goes back to its non-shader fallback for all 3 effects.

I think the only thing we can do is to preload the shader programs and fallback, either with a @supports mechanism or with passing multiple programs as I've shown.

Yes, as we discussed earlier in this thread, we need a clear definition of what failure means, and the one you have above (failure to load) makes sense to me. Slow running shaders, do not fit in the failing category. They are in the same boat as slow filter effects (you can write a nasty filter graph that can run well on high end desktop and will be slow on lower end hw) and to some extent in the same boat as slow scripts or pages in general, where the behavior will vary depending on the target hw (granted shaders are a bit different in that they run on the GPU).

@chris: is your suggestion to tighten up the definition of 'failure' to load in section 3.2? (https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html, see the description of vertexShader and fragmentShader). The current text is:

" If the shader cannot be retrieved, or if the shader cannot be loaded or compiled because it contains erroneous code, the shader is a pass through."

What I would propose is something like this:

"If the shader cannot be retrieved and run, for any reason (e.g., failure to compile or link), then the custom() function becomes a pass through filter."

This makes it clearer that the failures can be anything that prevents the shader to run and also adds that a failure in one of the shaders invalidates the whole custom() effect.

Cheers,
Vincent