| Summary: | [bisected] moving or clicking mouse cause gl-117 and blender aborted | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | fangxun <xunx.fang> |
| Component: | Drivers/DRI/i965 | Assignee: | Eric Anholt <eric> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | high | CC: | krh, sa |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Xorg log | ||
no_rast=true <any application> appears to also trigger this since around then. I'm having the same problem with Blender, and bisected the crash. If I use the commit before this one, the crash is gone, but none of the menus are drawn, so I guess it's only part of the problem. d449627829e1a4a3250a1a723af2f4e3cd5fd194 is the first bad commit commit d449627829e1a4a3250a1a723af2f4e3cd5fd194 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Feb 17 21:17:55 2010 -0500 intel: Implement the DRI2 invalidate function properly This uses a stamp mechanisms to mark the DRI drawable as invalid. Instead of immediately updating the buffers we just bump the drawable stamp and call out to DRI2GetBuffers "later". "Later" used to be at LOCK_HARDWARE time, and this patch brings back callouts at the points where we used to call LOCK_HARDWARE. A new function, intel_prepare_render(), is called where we used to call LOCK_HARDWARE, and if the buffers are invalid, we call out to DRI2GetBuffers there. This lets us invalidate buffers only when notified instead of on every glViewport() call. If the loader calls the DRI invalidate entrypoint, we disable viewport triggered buffer invalidation. Additionally, we can clean up the old viewport mechanism a bit, since we can just invalidate the buffers and not worry about reentrancy and whatnot. :040000 040000 5205e5b5764796a24b711eb741f34c2312e76d14 b5d71c3e0667eb5d0c1bb32f6f0c9b4dc9fc5aad M src My apologies, the crash in Blender I see is a different one. With bisect the result is the same as bug 27213. d449627829e1a4a3250a1a723af2f4e3cd5fd194 is the first bad commit commit d449627829e1a4a3250a1a723af2f4e3cd5fd194 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Feb 17 21:17:55 2010 -0500 intel: Implement the DRI2 invalidate function properly This uses a stamp mechanisms to mark the DRI drawable as invalid. Instead of immediately updating the buffers we just bump the drawable stamp and call out to DRI2GetBuffers "later". "Later" used to be at LOCK_HARDWARE time, and this patch brings back callouts at the points where we used to call LOCK_HARDWARE. A new function, intel_prepare_render(), is called where we used to call LOCK_HARDWARE, and if the buffers are invalid, we call out to DRI2GetBuffers there. This lets us invalidate buffers only when notified instead of on every glViewport() call. If the loader calls the DRI invalidate entrypoint, we disable viewport triggered buffer invalidation. Additionally, we can clean up the old viewport mechanism a bit, since we can just invalidate the buffers and not worry about reentrancy and whatnot. :040000 040000 5205e5b5764796a24b711eb741f34c2312e76d14 b5d71c3e0667eb5d0c1bb32f6f0c9b4dc9fc5aad M src (In reply to comment #4) > With bisect the result is the same as bug 27213. > Indeed, but it's not fixed by the same changes as bug 27213. (And just to clarify, this crash is triggered by clicking somewhere in the 3D Viewport, clicking on the menus or panels does not trigger it.) Should be fixed on master and the 7.8 branch. It works fine. Verified. |
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 33977 [details] Xorg log System Environment: -------------------------- Arch: x86_64 Platform: G45 Mesa: (7.8)54af54277a7a469ed2b9821ef6ed7ed464381f91 Xserver: (master)f2eacb4646beb25d055de22868f93e6b24f229b6 Xf86_video_intel:(master)318aa9ed799197810e2039dbe3ec51559dcc888c Libdrm: (master)04fd3872ee8bd8d5e2c27740508c67c2d51dbc11 Kernel: (master)60b341b778cc2929df16c0a504c91621b3c6a4ad Bug detailed description: ------------------------- gl-117: After game start, moving mouse, game aborted with below error info: gl-117: tnl/t_draw.c:406: _tnl_draw_prims: Assertion `ctx->NewState == 0x0' failed. Aborted. blender: After blender start, clicking mouse, blender aborted with below error info: blender.bin: tnl/t_draw.c:406: _tnl_draw_prims: Assertion `ctx->NewState == 0x0' failed. /usr/bin/blender: line 92: 4727 Aborted /usr/bin/${blend}.bin $@ This is regression. It works well with code on January 18th. I will bisect this on my free time. Reproduce steps: ---------------- 1.startX 2.run gl-117(blender) 3.move mouse(click mouse)