Commen=
t # 8
on bug 10799=
0
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 det=
ect
whether the EXT_direct_state_access OpenGL extension is available. In
experimental mode (glewExperimental=3DGL_TRUE), GLEW implements those macro=
s by
calling glXGetProcAddress() for every function that an extension is suppose=
d 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 g=
ame
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 up=
shot
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(). T=
his
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 G=
LVND
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 wa=
y 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 t=
his
happens with GLVND and not Mesa alone is because Mesa alone returns NULL for
these functions. With Mesa alone, the game calls glMapNamedBufferRange inst=
ead
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 use=
rs
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 log=
ic
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.