Bug 23335

Created attachment 28810 [details]
crash log

I've found that in x86 wine doesn't emit an error but crashes when it runs the game.
I've attached the crash in the message.

Comment on attachment 28810 [details]
crash log

Disregard my last post, on x86 the game runs fine.

What version of Mesa was this?  Is the original bug (glCheckFramebufferStatus returning 0) still reproducible?  I've inspected the code, and it appears that the only way _mesa_CheckFramebufferStatus can return 0 is if an invalid parameter is passed.  In this case, a debug build of Mesa will also log a message to stderr.

Appears to be a GLX problem:

anholt@gaiman:anholt/src/piglit% mesagl ./bin/fbo-readpixels
libGL: OpenDriver: trying /home/anholt/src/mesa/lib/tls/i965_dri.so
libGL: OpenDriver: trying /home/anholt/src/mesa/lib/i965_dri.so
testing with format 0x8058, 0x80e1, 0x8367 (8,8,8,8 rgba)
testing with format 0x8050, 0x1907, 0x8363 (5,6,5,0 rgba)
testing with format 0x8056, 0x80e1, 0x8365 (4,4,4,4 rgba)
testing with format 0x8057, 0x80e1, 0x8366 (5,5,5,1 rgba)

anholt@gaiman:anholt/src/piglit% LIBGL_ALWAYS_INDIRECT=yes mesagl ./bin/fbo-readpixels
testing with format 0x8058, 0x80e1, 0x8367 (8,8,8,8 rgba)
texture for internalformat 0x8058. format 0x80e1, type 0x8367 is framebuffer incomplete (0)
testing with format 0x8050, 0x1907, 0x8363 (5,6,5,0 rgba)
texture for internalformat 0x8050. format 0x1907, type 0x8363 is framebuffer incomplete (0)
testing with format 0x8056, 0x80e1, 0x8365 (4,4,4,4 rgba)
texture for internalformat 0x8056. format 0x80e1, type 0x8365 is framebuffer incomplete (0)
testing with format 0x8057, 0x80e1, 0x8366 (5,5,5,1 rgba)
texture for internalformat 0x8057. format 0x80e1, type 0x8366 is framebuffer incomplete (0)

On the other hand, ensuring that you get direct rendering should avoid this bug and improve performance as well.

*** Bug 24049 has been marked as a duplicate of this bug. ***

(In reply to comment #4)
> Appears to be a GLX problem:

I played with this a little bit.  I noticed a bunch of "no-op dispatch" messages being logged by the X server.  It would seem that something isn't being wired up correctly in the X server.

*** Bug 24817 has been marked as a duplicate of this bug. ***

Here's what's happening, and it's a pretty significant bug.

During 3D driver boot-strap, Mesa calls _mesa_init_remap_table.  This calls _mesa_map_function_spec, which in turn calls _glapi_add_dispatch.

_glapi_add_dispatch, in the X server's GLX module, calls add_function_name.  add_function_name, finally, calls generate_entrypoint. The server's GLX module is built without any USE_*_ASM flags defined, so generate_entrypoint always returns NULL.  As a result, the whole call chain fails.

This leaves the entry in the driDispatchRemapTable set to -1.  Since this is -1, the driver never installs its implementation of glGenFramebuffersEXT (or any other remapped extension function) into the dispatch table.  When GLX protocol comes in for one of these functions it ends up calling the no-op dispatch handler.

I think the correct fix is to change add_function_name to not call generate_entrypoint.  The entrypoints are returned by glXGetProcAddress to applications.  They are *never* used in the server.

However, making this change converted the client-side application failure to an assertion failure in the X server:

X: swrast/s_depth.c:580: depth_test_span: Assertion `rb->DataType == 0x1405' failed.

(In reply to comment #8)

> X: swrast/s_depth.c:580: depth_test_span: Assertion `rb->DataType == 0x1405'
> failed.

This assertion occurred with progs/demos/shadowtex, and is a different bug altogether.  For indirect rendering, GL_EXT_packed_depth_stencil is not supported.  However, the demo doesn't bother to check that.  Somewhere inside Mesa there's a missing check about this extension when it gets a packed depth/stencil format.  This causes the depth attachment renderbuffer to not be properly wrapped, and BANG!

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/55.