System Environment: -------------------------- Arch: i386 Platform: Huronriver Libdrm: (master)2.4.25-1-g61be94018ae9c403517d53f69357719224fa6ff3 Mesa: (master)f76787b3eae3f0b8af839fabfb24b57715a017f6 Xf86_video_intel: (master)2.15.0-17-g9d6e02a135efdea1d169d1938359ab2b553e941c Xserver:(master)xorg-server-1.10.0-385-g0de7cec90738a7a5020150309866bb0e23b6f479 Kernel: (drm-intel-next)caee6066332b83e7f8bdd6f2f40ce46d4836d69c Bug detailed description: ------------------------- It aborted on i965 platform. Below is error info on screen output. --> 2.4.8 - negative.varying.beyondMaxVaryingFloats subcase: oglconform: brw_eu.h:187: brw_reg brw_reg(GLuint, GLuint, GLuint, GLuint, GLuint, GLuint, GLuint, GLuint, GLuint): Assertion `nr < 128' failed. Aborted (core dumped) Bisect shows 8752764076e5b3f052a57e0134424a37bf2e9164 is the first bad commit. commit 8752764076e5b3f052a57e0134424a37bf2e9164 Author: Eric Anholt <eric@anholt.net> AuthorDate: Mon May 16 15:10:26 2011 -0700 Commit: Eric Anholt <eric@anholt.net> CommitDate: Fri May 27 09:07:32 2011 -0700 i965/fs: Do a FS compile up front at link time to produce link errors. At glLinkShaders time, a fail() call in FS compile in 8-wide (the one that's required to succeed, though we may relax that at some point for pre-Ironlake performance) will now report out as a link error. Reproduce steps: ------------------------- 1. start X 2. ./oglconform -z -s -suite all -v 2 -D 33 -test GLSLlinker negative.varying.beyondMaxVaryingFloats
Did this test previously pass? It seems like it probably failed, but the crash is new. Is that correct?
right, the case previously failed, the crash is new.
I just posted a patch to the mailing list that avoids this particular instance of the crash by fixing the test. http://marc.info/?l=mesa3d-dev&m=130799217415432&w=2 Since we don't pack varyings, I believe there are still cases where the linker (with the patch) will allow a shader, but it will still fail. For example, a shader that uses 17 float varyings will still fail. I believe there is already a piglit test for this.
This should be fixed on master by this commit: commit de77324d8f14951e4dc17f570e49451a0cd33121 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jun 9 13:31:32 2011 -0700 linker: Reject shaders that use too many varyings Previously it was up to the driver or later code generator to reject these shaders. It turns out that nobody did this. This will need changes to support geometry shaders. NOTE: This is a candidate for the stable branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37743 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixed in 7.10 by: commit 85b965b462a27d537b7d9da6e26c43516a3e67fe Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Jun 9 13:31:32 2011 -0700 linker: Reject shaders that use too many varyings Previously it was up to the driver or later code generator to reject these shaders. It turns out that nobody did this. This will need changes to support geometry shaders. NOTE: This is a candidate for the stable branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37743 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit de77324d8f14951e4dc17f570e49451a0cd33121) commit 459012b14882db1f07e335f37ba0dc6dfa767d6b Author: Marek Olšák <maraeo@gmail.com> Date: Thu Jun 23 15:55:41 2011 +0200 r600g: bump shader input limits (cherry picked from commit 1e5cef96d184b00eb588b48ecd02386998077d82)
Verified with Mesa master a9cb01f35597797a83ac940b0230a8f74f99a1b8 and mesa 7.11 b90c710c6cd8017f59b09d935fbbbe94ada81a12.
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.