[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Unused varyings.
On 12/10/2010 12:42 PM, Kenneth Waters wrote:
> vec3 NeverCalled ()
> return NeverUsed ;
> I believe this is considered reading the variable, even though this
> code is unreachable. You're asking the compiler to solve the halting
No! Far from it!! I assume that it can easily do 'dead code'
elimination. It just has to remove completely unreferenced variables
and functions when their names are not mentioned anywhere - and to
iterate on doing that until no more dead code/variables can be removed.
Hence, it can see that NeverCalled is not mentioned anywhere else and
delete that function. Then it can see that NeverUsed is no longer
mentioned anywhere and eliminate the variable. This is a completely
static analysis...nothing like on the scale of the halting problem!
My initial problem was actually worse than that. I had a 'varying' that
was declared and used in functions that are never called in BOTH the
vertex AND the fragment shaders.
The compiler optimized away the variable from the vertex shader - but
left it there in the fragment shader...and then complained that I'd
screwed up. That's NASTY because there is no easy way for the
programmer to handle that without removing all unused stuff himself -
and that's a major pain when you need "library" code shared between a
bunch of shaders at runtime.
This is inconsistant behavior - either it must 100% consistantly
eliminate dead code in BOTH shaders - or 100% consistantly never
eliminate a declared varying in ANY shader (please - not that!) - or it
must not complain when there is a varying mismatch due to something it
> The spec isn't 100% clear, but I think you're asking to much given
> the following snippet.
> "Likewise a varying in a fragment shader may be either a) not
> declared, b) declared but not read, c) declared and read in some paths
> or d) declared and read in all paths."
> "The compiler should not attempt to discover if a varying is read or
> written in all possible paths. This is considered too complex for ES."
> -- The OpenGL ES Shading Language section 10.12.
> For better or worse drivers tend to accept a superset of what the spec
> -- Kenneth Waters
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: