On Jun 17, 2010, at 10:24 PM, Oliver Hunt wrote:
> On Jun 17, 2010, at 6:46 PM, Vladimir Vukicevic wrote:
>
>>
>> ----- "Steve Baker" <
steve@sjbaker.org> wrote:
>>
>>> Since there is little or no practical use for shader
programs that don't
>>> complete within a very small fraction of a second - a one
second (or so)
>>> watchdog timer would seem to be the best - and perhaps
only - pragmatic
>>> solution. We could even allow users to set how long the
timer would
>>> wait before killing the web page in some '
about:config'
page just in
>>> case they want to use WebGL for some kind of
non-traditional use (eg
>>> CUDA-like applications).
>>
>> If we had a way to do this (abort execution while inside a
long-running shader), we wouldn't be having this conversation :-) The
problem is that in most cases your entire system is locked up waiting
for the GPU to come back; Windows Vista/7 handles this case by forcibly
resetting the entire graphics card (and thus killing any contexts),
which is probably the best response for now. But that functionality
isn't available to any programs to use directly, and no equivalent
exists on other platforms. Something might happen on that front, but
even if it does we need a solution for older (current) driver versions;
that solution might be "you don't get to run complex shader programs
until you upgrade your drivers", though.
>
> The other issue that exists is that even if the OS was willing to
kill off the GPU insanely quickly (say 5ms), i could still write a
piece of code that hammered the GPU by restarting the bad shader. This
would (effectively) produce a DoS of the entire machine.
_javascript_ will kick in its timeouts if you do this, so that's not a
problem. As long as the GPU can kick the shader in a reasonable amount
of time and the damage to the system due to the GPU reset is not
unrecoverable, you will be able to get back control of your system.