| What | Removed | Added |
|---|---|---|
| CC | bugs.freedesktop@fastquake.com |
Comment # 8
on bug 107990
from John Brooks
Created attachment 143165 [details] LD_PRELOAD shim I have investigated the issue and found the cause of the problem. First, some background. The game uses __GLEW_EXT_direct_state_access to detect whether the EXT_direct_state_access OpenGL extension is available. In experimental mode (glewExperimental=GL_TRUE), GLEW implements those macros by calling glXGetProcAddress() for every function that an extension is supposed to provide. If the driver returns non-NULL for every function in that set, then the macro evaluates to true. And if the macro evaluates to true, then the game will use EXT_direct_state_access functions such as glMapNamedBufferRangeEXT. Mesa does not implement EXT_direct_state_access, and returns NULL when its functions are queried with GetProcAddress(). GLVND, however, provides stubs for all OpenGL functions, and returns the stub in glXGetProcAddress(). The stub will eventually end up calling out to the vendor's (Mesa's) implementation of the function when a context is created and the vendor becomes known. The upshot of this is that glvnd will return a stub for every function in EXT_direct_state_access, leading the GLEW macro to return true, and the game will attempt to use those extension functions. The trouble begins when the game tries to use glMapNamedBufferRangeEXT(). This function is supposed to return a pointer to a memory area that maps to an OpenGL buffer. Since Mesa does not implement EXT_direct_state_access, the GLVND stub for glMapNamedBufferRangeEXT remains a no-op, and the return value is undefined. The game tries to write to the pointer that is returned (which of course is not valid as the function was a no-op), and it segfaults. I brought this up in #dri-devel, and imirkin pointed me to this page (https://dri.freedesktop.org/wiki/glXGetProcAddressNeverReturnsNULL/) which explains that checking for NULL from glXGetProcAddress is not a reliable way to determine if a function is supported. GLEW's experimental mode is doing this and reporting that extensions are supported when they are not. The reason this happens with GLVND and not Mesa alone is because Mesa alone returns NULL for these functions. With Mesa alone, the game calls glMapNamedBufferRange instead of glMapNamedBufferRangeEXT, which is just fine because Mesa implements the former. I'm not sure what to do to fix this at the driver level without being too hacky. I've attached code for an LD_PRELOAD shim, it should be very simple to compile (see comments in the file). This isn't ideal as it requires end users to find and compile this, but it's something for now. The game's developers could fix it by setting glewExperimental to GL_FALSE or improving their logic for deciding when to use EXT_direct_state_access. Or maybe not using it at all, since I'm not really sure what the point of using that extension is anyway, even if it is available.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
