Summary: | texelFetch(usampler2D) triggers st_glsl_to_tgsi.cpp:673:get_opcode: Assertion `op != 177' failed. | ||
---|---|---|---|
Product: | Mesa | Reporter: | Jay Cornwall <jay> |
Component: | Mesa core | Assignee: | mesa-dev |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Test case to trigger assertion
Fix target register type for integer texture opcodes in GLSL/TGSI conversion |
Created attachment 67278 [details] [review] Fix target register type for integer texture opcodes in GLSL/TGSI conversion Fixed with 9785ae0973cc206afc36dbc7d5b9553f92d06b47 |
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.
Created attachment 67277 [details] Test case to trigger assertion Problem: The attached test case triggers the following assertion during GLSL to TGSI lowering: ../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:673:get_opcode: Assertion `op != 177' failed. Explanation: The following GLSL IR fragment arises from the test case: (expression int % (expression int u2i (swiz x (txf uvec4 (var_ref S) (constant int (0)) 0 (constant int (0)) ))) (constant int (0)) glsl_to_tgsi_visitor::visit(ir_texture *ir) sets the temporary register holding the TXF result to type glsl::vec4_type. This was correct prior to GL_EXT_texture_integer, which introduced texelFetch(usampler2D) and texelFetch(isampler2D) with return types uvec4 and ivec4 respectively. The incorrect vec4 type propagates further through the lowering process. The inconsistency between this type and its ir_binop_mod consumer eventually triggers the assertion. Solution: It appears to be safe to use ir_texture->type, which carries the correct texelFetch return type, instead of glsl_type::vec4. The attached patch resolves the issue for me. However, it has not been subjected to regression testing.