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

RE: [Public WebGL] Infinite loops allowed in WebGL 1.0 currently?



The 'easily' part is the gaping wound in this spec :) I argue that allowing breaks et al that are basically dynamic flow control are not easy to determine at compile time. The HLSL compiler itself will balk at this stuff in some situations.

But I do concede that we have content out there that is running already and we have to look forward somewhat. I will see what I can do that constitutes the (a) path that Ken recommended and get back to you all.

-----Original Message-----
From: Olli Etuaho [mailto:oetuaho@nvidia.com] 
Sent: Tuesday, March 10, 2015 8:31 AM
To: Kenneth Russell; Jamie Madill
Cc: Ben Constable; public webgl
Subject: RE: [Public WebGL] Infinite loops allowed in WebGL 1.0 currently?

The intent of the spec is clearly to only allow loops with a constant number of iterations, to quote Appendix A where the limitations come from:

"In general, control flow is limited to forward branching and to loops where the maximum number of iterations can easily be determined at compile time."

I'd say it's a bug if a WebGL implementation doesn't validate loops for a constant number of iterations. Of course, shader timeouts are a problem regardless of what kind of loops are allowed. If a restriction was added, it would just force content authors use loops with a million iterations instead of loops with infinite iterations, and the problems would be practically the same. So I agree that it doesn't seem like it's worth the effort to address this.

-Olli
________________________________________
From: owners-public_webgl@khronos.org <owners-public_webgl@khronos.org> on behalf of Kenneth Russell <kbr@google.com>
Sent: Tuesday, March 10, 2015 1:23 AM
To: Jamie Madill
Cc: Ben Constable; public webgl
Subject: Re: [Public WebGL] Infinite loops allowed in WebGL 1.0 currently?

On Mon, Mar 9, 2015 at 4:21 PM, Jamie Madill <jmadill@chromium.org> wrote:
> On Mon, Mar 9, 2015 at 5:35 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>>
>> > On another fork I saw Jamie mention a desire to do some kind of an 
>> > amend here.
>>
>> Right; I think this was
>> https://code.google.com/p/angleproject/issues/detail?id=901 , which 
>> is blocking the integration of drawElements' AOSP tests in ANGLE. I'm 
>> not sure but think it's likely these tests will only pass on hardware 
>> that supports dynamic loops and that doesn't require loops to be unrolled.
>
>
> dEQP has a test case with an infinite loop with a conditional break. 
> This test applies to GLES 2 and 3, to the best of my knowledge (just 
> tried GLES 2 today). If I understood the discussion earlier we should 
> reject this shader on the older GLES 2 hardware?

That's the proposal. Is this feasible to do in ANGLE? I don't remember in what situations the [[flatten]] attribute is applied in ANGLE's HLSL translator, but is it possible to make this test pass on most
D3D9 hardware, and only fail compilation on D3D9 hardware that doesn't support dynamic loops?

-Ken


> I'm inclined to trust Ken's judgement on leaving the spec as is. It 
> might be more of a theoretical problem right now  more than a real 
> problem. If WebGL gets compute shaders, maybe we'll see a lot more 
> slow scientific computation shaders, with TDRs.
>

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


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