| Summary: | GLSL: vectorize optimization goes wrong on dot products | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Aras Pranckevicius <aras> |
| Component: | glsl-compiler | Assignee: | Matt Turner <mattst88> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Oh, I definitely saw this problem before. I'll handle it. Locally I could fix this with:
/* Upon entering an ir_binop_dot, remove the current assignment from
* further consideration. Dot product is "horizontal" instruction
* that we can't vectorize.
*/
ir_visitor_status
ir_vectorize_visitor::visit_enter(ir_expression *ir)
{
if (ir->operation == ir_binop_dot) {
this->current_assignment = NULL;
return visit_continue_with_parent;
}
return visit_continue;
}
But not sure if that's the correct approach.
I've sent two patches to fix this: http://patchwork.freedesktop.org/patch/20935/ http://patchwork.freedesktop.org/patch/20936/ LGTM Committed. I think Ian's picked it over to the release branch too. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
"Vectorize multiple scalar assignments" optimization (added in 4bd6e0d7c69 on master) goes wrong on dot products. For example, on a fragment shader like this: varying vec3 inA; varying vec2 inB; void main() { vec2 v; v.x = dot(inA.xy, inB); v.y = dot(inA.yz, inB); gl_FragColor = vec4(v.x, v.y, 0.0, 1.0); } It produces two problems: 1) tries to vectorize both dots into a v=dot(inA.xy,inB), which is different result. 2) in the result it ends up with an expression node of vec2 type, but a ir_binop_dot operation. asserts in ir_validate in debug build. It feels like these kinds of "horizontal" operations (probably only dot?) shouldn't be attempted to vectorize.