Re: [css-shaders] GLSL implementation defined limits

From: Chris Marrin <cmarrin@apple.com<mailto:cmarrin@apple.com>>
Date: Fri, 11 Nov 2011 10:17:11 -0800
To: Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>
Cc: "Gregg Tavares (wrk)" <gman@google.com<mailto:gman@google.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 10, 2011, at 6:35 PM, Vincent Hardy wrote:

Hi Gregg,
On Nov 10, 2011, at 4:20 PM, Gregg Tavares (wrk) wrote:
Up until this point, AFAIK, CSS you either have a feature (like 3D css) or you don't but if you do have the feature then for the most part there aren't too many situations where you'll run into serious limits.
In other words, while you have to worry that whether or not gradients exist, if they do exist you can generally count on them working for all reasonable inputs.
But that's not true with CSS shaders.  It will be very easy to create CSS shaders that work on some hardware but not on others either by making them too long or by exceeding other limits of the user's GPU.
WebGL leaves this up to the dev to deal with but it's a programatic API. You can check that it failed at runtime.
CSS is generally declare and forget.
Should it be that if any CSS shader on a page does not compile that all CSS shaders on the page should be ignored? That would at least mean that you don't have some elements displaced and others not. You either get everything you intended or you get your fallback, no CSSshader layout.
Of course that's problematic since CSS shaders can be changed and/or applied on the fly
Maybe specifying some maximum limits or min spec hardware or something...?
I think you bring up several issues.
- Incorrect shaders. I think this should be handled like incorrect CSS. If the shader does not compile, it behaves as if no shader is specified. WIth the WebGL restrictions on shaders, there is a base interoperability so I think the definition is tight enough that shaders would be compatible on all implementations. The proposal actually has some wording about incorrect shaders, see https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#feCustom.
- Hw limitations. There may be wide enough variations between hw that makes a shaders perform ok on one platform and not fast enough on another. I think this is tricky, and if the content author wanted to do something different based on that knowledge, we would need to have a kind of 'hw capabilties' media query. I understand the concern and need, I am not clear on how we would go about classifying hardware capabilities. Do you have a suggestion?

I don't think there is any way to announce hardware capabilities. Even if we gave the author the ability to discover details such as number of texture units, uniforms, and GPU program memory, there will be hardware that seems to have all the needed capabilities but that still can't run the shader because of some combination of the features being used. I think the best we can do is to have a minimum set of functionality that authors can try to stay within to have the best chance of interoperability. Then we should figure out some way of having fallback style for when a shader does fail.

I'm not actually sure of how CSS handles fallback. Maybe we could do this:

.filtered: {
filter: shader(<my complicated shader>);
filter: shader(<my less complicated shader>);
filter: blur(3);
}

So if the complicated shader fails, it will try the less complicated one. If that fails, it will use a simple blur. Would that work?

Hi Chris,

Having a fallback mechanism would be good, but I am not sure about two things. First, I think that we would need to clarify what 'fails' mean. Are you thinking the complicated shader would fail because it is slow, because it is not compiling or are you thinking of another definition for failure?

CSS handles fall back for things like background-image like so:

.bkg {
background-image: url(...); /* baseline, should be supported by all implementations */
background-image: linear-gradient(...); /* will override the simple background-image specification if linear-gradient is supported */
}

Thanks,
Vincent