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

Re: [Public WebGL] Shader validation and limitations



stephen white wrote:
> On 18/06/2010, at 11:58 AM, Steve Baker wrote:
>> The timeout approach is a good one because it directly applies a limit
>> to user-inconvenience - no matter how it's inflicted.  If people are
> while (1) malicious_shader();
>
> The whole system being frozen is the big issue, and reminds me of the
> days before multi-tasking. The obvious option then seems to be some
> form of shader multi-tasking, with the problem shaders able to be
> selected and killed off over time.
But if the GPU can't do that - (and I'm pretty sure it can't) then it's
no solution.  GPU's are far from being general purpose computers - there
are things that they are simply unable to do.

In the 'while(1) malicious_shader();' case, the 'while(1)' part would be
in the CPU - where we can break in and kill it...so that's no more a
problem than writing 'while(1);' in JavaScript and "locking up the
machine" that way.

As I understand it - the problem is with shaders that run for a crazy
amount of time without ever letting the CPU finish waiting for them.  If
the shader stops and returns - for however little time - then the
problem is easy to solve without resorting to new code in the underlying
OpenGL driver.

  -- Steve

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