Summary: | src/glsl/ralloc.c:81: get_header: Assertion `info->canary == 0x5A1106' failed. | ||
---|---|---|---|
Product: | Mesa | Reporter: | Vinson Lee <vlee> |
Component: | glsl-compiler | Assignee: | Kenneth Graunke <kenneth> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | medium | CC: | darxus, idr, stereotype441 |
Version: | git | Keywords: | have-backtrace, regression |
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | attempted fix. |
Description
Vinson Lee
2012-12-09 04:04:58 UTC
I'm experiencing this too. (Running Heroes of Newerth) Though I bisected it to : df87722beccf0255d149668ca54a35cabf99a9c4 is the first bad commit commit df87722beccf0255d149668ca54a35cabf99a9c4 Author: Paul Berry <stereotype441@gmail.com> Date: Sun Dec 9 20:59:26 2012 -0800 glsl/linker: Pack within compound varyings. This patch implements varying packing within varyings that are composed of multiple vectors of size less than 4 (e.g. arrays of vec2's, or matrices with height less than 4). Previously, such varyings used up a full 4-wide varying slot for each constituent vector, meaning that some of the components of each varying slot went unused. For example, a mat4x3 would be stored as follows: <----slot1----> <----slot2----> <----slot3----> <----slot4----> slots * * * * * * * * * * * * * * * * <-column1-> x <-column2-> x <-column3-> x <-column4-> x matrix (Each * represents a varying component, and the "x"s represent wasted space). In addition to wasting precious varying components, this layout complicated transform feedback, since the constituents of the varying are expected to be output to the transform feedback buffer contiguously (e.g. without gaps between the columns, in the case of a matrix). This change packs the constituents of each varying together so that all wasted space is at the end. For the mat4x3 example, this looks like so: <----slot1----> <----slot2----> <----slot3----> <----slot4----> slots * * * * * * * * * * * * * * * * <-column1-> <-column2-> <-column3-> <-column4-> x x x x matrix Note that matrix columns 2 and 3 now cross a boundary between varying slots (a characteristic I call "double parking" of a varying). We don't bother trying to eliminate the wasted space at the end of the varying, since the patch that follows will take care of that. Since compiler back-ends don't (yet) support this packed layout, the lower_packed_varyings function is used to rewrite the shader into a form where each varying occupies a full varying slot. Later, if we add native back-end support for varying packing, we can make this lowering pass optional. Reviewed-by: Eric Anholt <eric@anholt.net> v2: Skip varying packing if ctx->Const.DisableVaryingPacking is true. :040000 040000 8fd42fe4c6d749ff87fcf9a72e8e45cdc03426c5 0b6864612065c45dc8f8feb24c0c2dbb3cd072bc M src And it happens with and withoout the LLVM glsl compiler. I'm using an HD6870 on Linux 3.7, libdrm 2.4.40 and ddx 3c7d024c2671dac541b8f2daed55040f4fd5d62d This is breaking wayland / weston for me. Reverting to the commit before Vinson's first bad commit works. Same error: weston: ../../src/glsl/ralloc.c:81: get_header: Assertion `info->canary == 0x5A1106' failed. Paul, can you do some checking with Valgrind? Created attachment 71572 [details] [review] attempted fix. Dave: Looks like that worked - weston is running with the latest mesa commit ( 4f91f8dd6057b73d05454fc626985183d00e5236 ) plus your patch. Beyond that, I'm in no position to say. pushing fix after testing and review. reopen if seen again or file a new bug for a different backtrace. mesa: fa5078c255b5b57514ae854ecd6264379641c924 (master) I still see still crash with piglit layout11.frag on swrast, softpipe, and llvmpipe. FYI weston is working for me with that same mesa commit ( fa5078c255b5b57514ae854ecd6264379641c924 ). commit 12f3b3d43732b6f9dbed72457a75b131ad621793 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Mon Dec 17 11:20:53 2012 -0800 glsl: Fix gl_context vs. ralloc context in check_version again, again. Dave found some, but there were more. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58039 |
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.