| Summary: | [bisected] OilRsh_x86 forced quit | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | libo <bo.c.li> |
| Component: | Drivers/DRI/i965 | Assignee: | Kenneth Graunke <kenneth> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | high | CC: | idr, kenneth |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
libo
2012-08-03 02:19:19 UTC
Ian, is this expected? I don't know what "force quit" means. Does it crash? Is there a backtrace? Ken, can you reproduce this? When hit the the "run" button,the game will be shutdown with the follow error messages: GLRender::require_extension(): required extension GL_ARB_vertex_array_object is not supported Shutdown (In reply to comment #2) > I don't know what "force quit" means. Does it crash? Is there a backtrace? I don't have a modern computer handy, but there's one really easy explanation for this: QA's mesa build is broken. Evidence: - "This error is only happened on 32-bit OS." This is almost always a red herring that means build fail. - Missing GL_ARB_vertex_array_object extension. Indirect rendering doesn't support this extension, but direct rendering always does. A bad build (or 32/64 mismatch) would lead to indirect rendering. I have no other explanation for GL_ARB_vertex_array_object disappearing. Also note that it's _not_ a GLX extension, which means it isn't a Unigine bug where they check extensions wrong. It's basically impossible for them to screw that up. It has to be indirect rendering. OilRush 1.11 is working just fine here. Closing. 1.The bug still exists. When I reverted this commit,the game run well. 2.The Oil-rush1.11 provides both 32-bit and 64-bit binaries for Linux. This bug can be reproduced when I run 32-bit binary with 32-bit OS. 3.The extension GL_ARB_vertex_array_object is supported when run glxinfo. Weird, but you're right, it hits an assertion failure with OilRush_x86 but works fine with the OilRush_x64. They must be slightly different in how they initialize their GL contexts. That's very odd... This turns out to be the same issue I ran into while trying to apitrace the 64-bit version of Unigine Heaven. I've verified that it's fixed by the following patch: [PATCH] glx/dri: Initialize reset to __DRI_CTX_RESET_NO_NOTIFICATION. http://lists.freedesktop.org/archives/mesa-dev/2012-August/025226.html Sorry for the mistake. I'll commit that soon. Fixed on master with: commit 68bccc40f55aee7f4af8eb64b15a95f0b49d6a17 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Mon Aug 6 15:12:07 2012 -0700 glx/dri: Initialize reset to __DRI_CTX_RESET_NO_NOTIFICATION. If the application has requested reset notification, then dri2_convert_glx_attribs will initialize this to the correct value. Otherwise, it's supposed to initialize this to NO_NOTIFICATION, but doesn't when num_attribs == 0. (The consensus seems to be that we should make it do so, but that's more invasive, so I'm pushing this for now.) Fixes a regression since a8724d85f8cb2f0fb73b9c6c1f268f9084c6d473 where trying to run OilRush_x86 or apitrace heaven_x64 would result in: dri_util.c:221: dri2CreateContextAttribs: Assertion `!"Should not get here."' failed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53076 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> It works well with Kenneth's commit. 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.