Created attachment 94629 [details] Bisect log (for reproducibility) Running Unigine Tropics hangs the GPU on Ironlake. This occurs with 10.1 and master, and is a regression: Mesa 10.0.3 works fine. A bisect shows: 67ebcb4711d7c6d35df03298f065806613a62798 is the first bad commit commit 67ebcb4711d7c6d35df03298f065806613a62798 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Mon Jan 13 14:32:56 2014 -0800 i965: Use the new drm_intel_bo offset64 field. libdrm 2.4.52 introduces a new 'uint64_t offset64' field, intended to replace the old 'unsigned long offset' field. To preserve ABI, libdrm continues to store the presumed offset in both locations. On Broadwell, a 64-bit kernel may place BOs at "high" (> 4G) addresses. However, with a 32-bit userspace, the 'unsigned long offset' field will only be 32-bit, which is not large enough to hold this value. We need to use a proper uint64_t (like the kernel does). Technically, a lot of this code doesn't affect Broadwell, so we could leave it using the old field. But it makes sense to just switch to the new, properly typed field. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Steps to reproduce: $ cd tropics $ export MESA_EXTENSION_OVERRIDE=GL_EXT_framebuffer_multisample $ ./1024x768_windowed.sh
Since this bisected to my commit, I should probably own this.
This also hangs on my GM45 box (using the same hard drive/OS install), but works on Crestline (using a different hard drive/OS install)...
I had libdrm 2.4.52 in 64-bit (including the pkg-config files to make the build succeed), but only 2.4.49 in 32-bit. Which doesn't have offset64, so it uses some rubbish as the address. After upgrading to the actual dependency, it works fine. No bug here.
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.