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

Re: [Public WebGL] some samples and a question about looping



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
those GPUs).

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...

-- Sami

On Wed, Jan 5, 2011 at 7:52 PM, Kenneth Russell <kbr@google.com> wrote:
> On Wed, Jan 5, 2011 at 8:02 AM,  <tomi.aarnio@nokia.com> 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.
>
> -Ken
>
>> Best regards,
>>  Tomi
>>
>> -----Original Message-----
>> From: owner-public_webgl@khronos.org [mailto:owner-public_webgl@khronos.org] On Behalf Of ext Mark Callow
>> Sent: 5. tammikuuta 2011 4:29
>> To: public_webgl@khronos.org
>> 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.
>>
>> Regards
>>
>>    -Mark
>>
>>
>> -----------------------------------------------------------
>> 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:
>>
>>
>
> -----------------------------------------------------------
> 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:
>
>

-----------------------------------------------------------
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: