[Bug 71254] Mesa crash on shaders that have large number of active uniforms.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71254

--- Comment #5 from Ian Romanick <idr at freedesktop.org> ---
(In reply to comment #4)
> 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20131106/9deb6ee9/attachment.html>