[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] GLSL loops and constant expressions
- To: Marco Di Benedetto <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] GLSL loops and constant expressions
- From: Kenneth Russell <email@example.com>
- Date: Tue, 7 Dec 2010 13:11:20 -0800
- Cc: Vladimir Vukicevic <firstname.lastname@example.org>, public webgl <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291756282; bh=QbpsRNuf3gbeHplC+GgKCbegSGg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=doALUXHLZAmxCrXvx4F2Vm3DIUFGiC8+3FQCZUUIRKC6T9vTnKcyJC3QgzO0q8PNe a7pwPplii0+fl1iei+yiQ==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z3XgEX9gLqeeXC8d5t2sCCdDocsIvMIHMBQ/5yZ4l2I=; b=ygA3RhRJ11smLN3AcsvH9QIkHAxlNHcd92HOyAbYiIX+hWxysRD20zULAUZr2ZcHPV 9i4mJDIyBu5fdYDK9EKg==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rp5V+vnTsrPKT9u7+GSeA5/vc+feg4JWchK64Ay4ktTZSSRAZVWy15NuPZs4TFXP4k iYy4emJyQSPcgphAmNhQ==
- In-reply-to: <4CFE7CBE.firstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <1913432303.493203.1291669487612.JavaMail.email@example.com> <4CFE7CBE.firstname.lastname@example.org>
- Sender: email@example.com
On Tue, Dec 7, 2010 at 10:28 AM, Marco Di Benedetto
> 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
> 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.
> Maybe these features (and others) deserve their extensions?
> For example, the gl_FragData[i] is accepted only if i is zero, as the specs
> say that there is only a COLOR0_ATTACHMENT. But can we actually relax these
> limitations whenever the system is capable?
> Sure, they won't work on all GL|ES 2.0 systems, but, as usual, a developer
> can ask the capabilities before going on.
The problem with supporting non-constant expressions in for/while
loops as a WebGL extension is that there is no way to query an OpenGL
ES 2.0 system to find out whether its GLSL ES implementation supports
them. Multiple render targets is another piece of functionality that
doesn't exist on any OpenGL ES 2.0 system. OES_depth_texture is one
that the WebGL working group discussed recently which might be
supportable in some form on both desktop and mobile.
While living within these restrictions may be painful, doing so will
ensure that content runs identically on desktop and mobile devices,
which is a big step forward. I think we should focus on that goal
initially with the WebGL 1.0 spec, extensions, and content.
> On 06/12/2010 22:04, Vladimir Vukicevic wrote:
>> I've noticed a number of demos (even some recent ones) are failing the
>> shader validation/translation step due to using a non-constant expression in
>> a for loop. This is a limitation imposed by Appendix A of the GLSL ES spec,
>> which WebGL is following, and which ANGLE is now validating.
>> For loops, as decribed in section 4 of appendix A are allowed with the
>> following limitations:
>> - one loop index
>> - index has type int or float
>> - for statement must have the form:
>> for (type_specifier identifier = constant_expression ;
>> loop_index op constant_expression ;
>> loop_expression )
>> where op is> >=< <= == or !=, and loop_expression is of the form
>> loop_index++, loop_index--, loop_index += constant_expression,
>> loop_index -= constant_expression
>> As described in section 5.10 of the GLSL ES spec, a constant expression
>> - a literal value (e.g., 5 or true)
>> - a global or local variable qualified as const excluding function
>> - an expression formed by an operator on operands that are constant
>> expressions, including getting an element of a constant vector or a constant
>> matrix, or a field of a constant structure
>> - a constructor whose arguments are all constant expressions
>> - a built-in function call whose arguments are all constant expressions,
>> with the exception of the
>> texture lookup functions.
>> The following are not constant expressions:
>> - User-defined functions
>> - Uniforms, attributes and varyings.
>> In particular, a number of shaders are attempting to use a uniform value
>> as a loop expression. This won't work, and triggers validation failure (and
>> thus a compilation failure at compileShader time).
>> - Vlad
>> 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:
> 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:
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: