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

Re: [Public WebGL] GLSL loops and constant expressions

On 12/07/2010 03:11 PM, Kenneth Russell wrote:
> On Tue, Dec 7, 2010 at 10:28 AM, Marco Di Benedetto
> <marco.dibenedetto@isti.cnr.it> wrote:
>> Not having the possibility to use "while" loops or "for" loops with
>> non-constant expressions is very, very sad.
> Could you provide a use case for this functionality? It doesn't seem
> like that big a restriction to me but I'm not a graphics algorithm
> expert.
We can "break;" out of a loop - right?

If so, then I can't think of a compelling need.

Skeletal mesh animation with different numbers of bones in different
objects...although you can work around it by setting the loop to the
maximum number of bones you can support - with an 'if' and a 'break' to
terminate early and save some time on machines that truly have dynamic
looping.   If you don't have even that (or if doing that is horribly
inefficient) you build dozens of shaders - each with a fixed loop length
- and pick which one to run depending on the number of bones you have.

In the fragment shader, displacement mapping and other "ray tracing"
algorithms benefit from variable length loops - but again, if you have
"if" and "break" - you can work around it by just setting a large loop
limit.  But efficiency is an issue here - on many GPU's, frag shader
loops work by unrolling the loop - and "if" statement consume an amount
of time equal to the time needed to execute both the "then" AND "else"
clauses...which in this case means that there is no point in breaking
out of the loop at all...so this is a severe efficiency hiccup for
displacement mapping and "ray tracing" shaders.   But when the hardware
just can't do it...you have to go with what you've got.
>> As with some other things, like multiple rendering targets and depth texture
>> formats, I knew the specs say that, but I hoped in some loose validation
>> whenever the underlying GL implementation allows them.
MRT's are something I'd kill for.  They let you do post-effect lighting
- which is a really good "fit" for a system where you need to avoid
running slow JavaScript and push more stuff into the CPU.   Depth
textures are also super-handy...but you can kinda work-around the lack
of them if you have MRT's.   But no MRT's *AND* no
render-to-depth-texture is crippling for algorithms that need access to
depth in post-effects - which includes SO many effects...depth of field,
layered fog, cheap bullet-hole decals, diffraction, sub-surface scatter,
3D clouds...dozens and dozens of them.

Without depth textures, you have to do an extra render pass to render
depth to an RGB buffer - then render again to do your beauty pass...then
you can use that first RGB buffer to get the depth values into your

MRT's allow you to write out an RGB depth during the beauty-pass in
addition to the regular image...so if you have MRT's, you can live
without render-to-depth textures.

But without either...it's nasty.
> While living within these restrictions may be painful, doing so will
> ensure that content runs identically on desktop and mobile devices,
Not really - we're still going to find limitations relating to having
less than 8 bit render targets, no support for vertex textures (ie
number-of-vertex-textures==0), differing numbers of textures per mesh,
differing maximum shader size.   Well-written applications still have to
adapt to the hardware if they are going to push the envelope.
> I think we should focus on that goal
> initially with the WebGL 1.0 spec, extensions, and content.
Yep.  I certainly agree with that.  Getting 1.0 done and out the door
certainly trumps most other concerns at this stage.

  -- Steve

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: