[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] some samples and a question about looping
- To: firstname.lastname@example.org
- Subject: Re: [Public WebGL] some samples and a question about looping
- From: Sami Mäkelä <email@example.com>
- Date: Thu, 6 Jan 2011 03:24:53 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=791QLmRtG7Gu3WXOu3ebcp59BZUk2dTbJOisLu1nVAs=; b=pCLDIsNKsDNoPbshGMKVnRxcUe2xtDhAH5zQNbUN7ZvCuELdtuKU3K+z7MkmxTW/dP o9tjdKlUhR2u3ACyDyOYoea9nBhQYKMVeAYNYhv1ZLKDK3bskjzfHQLBQBykAYQtkd62 DV/I+W3XgYqe1mVwhKPRAATL+lTJFXqqs4Ql8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=s4xqy7uag4tcfOx1wgPWFg71+pgJ+mrA2C7Zbrh4VwmFVjIRbiAz6gqXCldNnRPojt xk6KtKXTei3CCfbO9uLRvELoboZ1YG82sTafDFTqSwb0l4KDt9VDCraGQMG6oEqt8io8 8THMW2L4QWiCBYGwJ+cequTLfoD55n0it1ERE=
- In-reply-to: <AANLkTikcdbiz_reVcrQBWnGwXsL0b9UgRZfizOfhFOfirstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <AANLkTi=hd-eWqRT_PYLzwNXX0Hg_ebdVDONkP=jxiMd7@mail.gmail.com> <4D15F103.email@example.com> <AANLkTi=ZJqFYwHyCWSHU0aPv1DSc3gx5sojp2HZprTkh@mail.gmail.com> <4D180536.firstname.lastname@example.org> <AANLkTik17hHUMiwpw4rh+ZguDWpe2UJXeLAGemail@example.com> <4D1A4D39.firstname.lastname@example.org> <AANLkTinjNXQh0k__6UkEp+QwwnAdfccGp2ssoynTemail@example.com> <4D23D753.firstname.lastname@example.org> <9E85EB37BE49424480E1829239B6C9C511095E@008-AM1MPN1-015.mgdnok.nokia.com> <AANLkTikcdbiz_reVcrQBWnGwXsL0b9UgRZfizOfhFOemail@example.com>
- Sender: firstname.lastname@example.org
I hope somebody could actually check, which GPUs in the phones do not
support conditional jumps (and tell us so I can avoid models with
Anyway, it doesn't matter here, because the issue is entirely
syntactic. The restriction only makes sense if the platform does not
have jumps, and the driver is only intended for running programs made
for that specific platform (then the syntax follows more closely to
the implementation). If the driver is intended to run portable
programs it makes no sense, it just forces programmers to use kludges.
You can easily figure out if arbitrary loops work by testing with a
simple program (for example while loop bounded by uniform). The WebGL
implementation could try to execute this kind of program to see if it
works. It is much more difficult to find out how loop unrolling is
handled. For example unrolling can be handled differently when the
iterator variable is float vs. int. Then there can be error when
compiling, or the compilation does not terminate at all, so even test
programs cannot be used. There are plenty of similar parameters, like
nesting level of if-statements...
On Wed, Jan 5, 2011 at 7:52 PM, Kenneth Russell <email@example.com> wrote:
> On Wed, Jan 5, 2011 at 8:02 AM, <firstname.lastname@example.org> wrote:
>> Hi Mark,
>> Can you give any examples of such implementations? I'm wondering whether such hardware will be able to run any practical WebGL content in the first place, irrespective of looping restrictions.
>> For the record, I do not understand why WebGL should reject perfectly valid GLSL ES shaders just because they happen to use variable-length loops. Why should this particular low-end GPU limitation be enforced on even the most powerful desktop GPUs, when most others are not? If we go down that road, then why not reject code that uses more than 8 textures, or more than 128 uniforms, or a canvas larger than 64x64 pixels?
> There is no way to query an OpenGL ES 2.0 implementation to discover
> whether it supports loops with arbitrary loop test expressions.
> Because of this, enforcing this particular restriction was done to
> maximize portability of WebGL content. The other resource limitations
> you mention can be queried, so correctly written applications can
> adjust at run time.
>> Someone already pointed out, and I agree, that imposing these rather arbitrary restrictions is only going to result in less portable shaders as developers come up with dirty workarounds.
> That's a matter of opinion. As WebGL implementations and content
> become more widely available on true OpenGL ES 2.0 hardware, we'll all
> gain more experience and make adjustments as necessary in future
> versions of the spec.
>> Best regards,
>> -----Original Message-----
>> From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of ext Mark Callow
>> Sent: 5. tammikuuta 2011 4:29
>> To: email@example.com
>> Subject: Re: [Public WebGL] some samples and a question about looping
>> On 29/12/2010 09:28, Sami Mäkelä wrote:
>>> Probably most
>>> common use of variable length loops would be loops that are simply
>>> bounded by uniforms.
>> There are many OpenGL ES implementations that do not support this, which is why they are not allowed in WebGL.
>> 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: