| Summary: | [UBO] row_major layout partially ignored for arrays of structures | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Ian Romanick <idr> |
| Component: | glsl-compiler | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Test case | ||
I run it against today's master (d69da58) on a HSW machine and I got the right offset for the UBO access: (expression int ubo_load (constant uint (0)) (constant uint (112)) Is it still happening to you? Fixed by: commit c3f17bb18f597d7f606805ae94363dae7fd51582 glsl: Strip arrayness from ir_type_dereference_variable too If the thing being dereferenced is a record or an array of records, it should be treated as row-major. The ir_type_derference_record path already does this, and I think I intended to do the same for this path in b17a4d5d. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83741 Cc: mesa-stable@lists.freedesktop.org |
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 106089 [details] Test case The API reports the correct offsets for everything, but the compiler generates the following for the UBO access: (expression int ubo_load (constant uint (0)) (constant uint (64))) The offset should be 112, not 64.