<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Mesa crash on shaders that have large number of active uniforms." href="https://bugs.freedesktop.org/show_bug.cgi?id=71254#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Mesa crash on shaders that have large number of active uniforms." href="https://bugs.freedesktop.org/show_bug.cgi?id=71254">bug 71254</a> from <a class="email" href="mailto:idr@freedesktop.org" title="Ian Romanick <idr@freedesktop.org>"> Ian Romanick</a> <pre>(In reply to <a href="show_bug.cgi?id=71254#c4">comment #4</a>) > I do not think changing the array size from MAX_UNIFORMS to 4*MAX_UNIFORMS > will fix either crash causes. > > The first crash cause, writing past the array. The first main issue is this: > the real beans is not so much maximum number of uniforms, but maximum number > of -active- uniforms. If that is true, then unless the GLSL front-end walks > the IR and removes dead code to then compute the "active" uniforms, then the > issue shall remain. If GLSL IR does do that or is modified to do so, or in a > pinch modified to simply reject immediately GLSL code that goes past the > MAX_UNIFORMS limit then leaving that array as MAX_UNIFORMS in size is fine. It basically does that. If the shader has more than MAX_UNFORMS*4 components of data, the linker will generate an error... because the shader exceeds hardware limits and won't run. > However, the correct solution is to just make the array dynamic in size; the > obvious benefit is that it will likely even save a little memory since only > room needed to enumerate the uniforms for an active shader will be allocated. There is no benefit to the added complexity of making this dyanamic. > The second cause, the stack overflow on visitors. One can machine generate > expressions that only use -one- uniform (or just an in, be it shader global > scope of function scope) that cause the stack overflow. Fixing this is > non-trivial except to just not bother walking such large expressions. > > One can argue that "real application" code would not have such expressions. > That argument does not pan out so well when inlining comes into play. > Imagine a noise computation where the the arguments fed to it are also noise > values and so on. Even ignoring that case, a GL implementation must also > guard against malicious shaders (in particular well formed malicious > shaders). The severe burning example is using Mesa on a system that has a > browser that implement WebGL. At the end of the day, all those shaders from > the *web* will be passed to the GL implementation. Crash driver, will > potentially crash the browser. For the case of Chrome/Blink, this will crash > the GPU process of a browser which will likely bring down all GL state for > all WebGL canvases and likely just crash the entire browser too.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>