[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Shader validation and limitations
On Jun 22, 2010, at 5:03 PM, Gregg Tavares wrote:
> On Mon, Jun 21, 2010 at 11:37 AM, Chris Marrin <email@example.com> wrote:
> On Jun 18, 2010, at 1:04 PM, Ilmari Heikkinen wrote:
> > 2010/6/18 Oliver Hunt <firstname.lastname@example.org>:
> >> On Jun 17, 2010, at 9:49 PM, Cedric Vivier wrote:
> >>> On Fri, Jun 18, 2010 at 08:02, Chris Marrin <email@example.com> wrote:
> >>>> I believe this solves the halting problem issue, (although I suspect Ken disagrees with me). But doesn't necessarily prevent a shader from running for an extremely long time, which I suppose is the same thing in most cases.
> >>> It seems Ken and/or others investigated this issue in depth months
> >>> ago, is there any document available demonstrating all shader
> >>> constructs - besides loops - found to possibly take an extremely long
> >>> time to run ?
> >> I believe the trick was to make a very expensive shader, and then throw thousands of large polygons at it.
> > Or you can just throw a model with a million screen-sized triangles at
> > a trivial shader.
> Not with OpenGL ES you can't. It's limited to 65535 vertices per call, which I suppose translates to 65533 triangles if you're using TStrips. But the point is that a malicious author can do damaging things without writing an infinite loop. Even with that, I still advocate restricting shaders to the limits in Appendix A. It is always easier to relax restrictions than to tighten them.
> I don't think OpenGL ES is limited to 65535 vertices per call. It's limited to 16 bit indices but you can draw 2^31 vertices with either DrawArrays or DrawElements
Right. My mistake. You can only index 65536 unique vertices, but you can render many more per call by reusing vertices.
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: