<div dir="ltr">On Wed, May 1, 2013 at 8:41 PM, Oliver Hunt <span dir="ltr"><<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On May 1, 2013, at 5:29 PM, Antonio Gomes <<a href="mailto:tonikitoo@webkit.org" target="_blank">tonikitoo@webkit.org</a>> wrote:</div><blockquote type="cite">
<div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr">- 4.3 Out-of-Range Memory Access<br></div></div></blockquote></div><div class="im">
<blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><p>The validator will perform static analysis on WebCL kernels to determine violations of WebCL kernel behavior and language restrictions. The results from the analysis will also be used to determine any necessary instrumentation to bring the WebCL kernels in compliance with security and syntactic requirements of the WebCL API. The RFQ for the WebCL Validator located at <a href="https://cvs.khronos.org/wiki/index.php/WebCL_Validator" target="_blank"><span>https://cvs.khronos.org/wiki/index.php/WebCL_Validator</span></a> provides information on the approach recommended by the WebCL working group. </p>
</div></div></blockquote><div><br></div></div><div>How do you statically verify the all memory accesses are within bounds without limiting a WebCL kernel to the functionality already offered by shaders in WebGL?</div></div>
</div></blockquote><div><div><br></div><div>Basically there are three different cases to consider when adding checks to a memory access:</div><div>1. We know at compile time that the access will be inside memory allocated to the program.</div>
<div>2. We know at compile time the limits which the access must respect.</div><div>3. We don’t even know the limits at compile time (this causes most overhead to support).</div><div><br></div><div>I think you are talking about 3? If that is the case, the WebCL validator will handle this case.</div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im">
<blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><p>- 4.6 Prevention of potential denial of service (DoS) from long running kernels:</p>
<p>This is addressed by the OpenCL CL_CONTEXT_TERMINATE extension. In <a href="http://www.khronos.org/registry/cl/specs/opencl-1.2-extensions.pdf" target="_blank"><span>http://www.khronos.org/registry/cl/specs/opencl-1.2-extensions.pdf</span></a><span> </span>, please refer to section "9.16 Terminating OpenCL contexts".</p>
</div></div></blockquote></div><div>I haven't seen any real evidence of widespread support for responsive termination in WebGL shaders yet, and given that the same hardware is involved when you want GPU backed WebCL I don't see how much this will help.</div>
</div></div></blockquote><div><br></div><div>First, from a GPU vendor perspective, OpenCL and OpenGL drivers are different things.</div><div><br></div><div>When WebCL working group proposed this OpenCL security extension, it had to pass through an internal approval process, by vote, where the Khronos members, including GPU vendors, approved it.</div>
<div><br></div><div>In the case of OpenGL/WebGL, I would prefer to defer to someone who is part of these WGs to state on why it was not requested. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><div></div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>It is chicken-egg problem: without Browser vendors commitment to WebCL, the motivation for hardware vendors to implement, for example, OpenCL 1.2 "Memory Initialization" and "Context termination" extensions, required by WebCL, is not as strong.</div>
</div></div></div></blockquote><br></div></div><div>The extensions mentioned above are required by WebGL shaders, and WebGL has been around for a lot longer (and has even more stringent requirements than WebCL) - are there any GPUs that support the WebGL restrictions natively?</div>
<span class=""><font color="#888888"><div><br></div></font></span></div></div></blockquote><div>If you are talking about GL_ARB_robustness, it is supported by NVIDIA and Mesa3D, among others. </div><div><br></div></div>
</div>
</div>