[Bug 107990] Got Dying Light working in Arch by changing Mesa's compile steps, how to get it working Out Of the Box?

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 3517 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=107990

John Brooks <bugs.freedesktop@fastquake.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugs.freedesktop@fastquake.
                   |                            |com

--- Comment #8 from John Brooks <bugs.freedesktop@fastquake.com> ---
Created attachment 143165
  --> https://bugs.freedesktop.org/attachment.cgi?id=143165&action=edit
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.

[-- Attachment #1.2: Type: text/html, Size: 5181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel