Summary: | Need help in running Dying Light | ||
---|---|---|---|
Product: | Mesa | Reporter: | Anthony Jagers <noonetinone> |
Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED NOTOURBUG | QA Contact: | Default DRI bug account <dri-devel> |
Severity: | trivial | ||
Priority: | lowest | ||
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Anthony Jagers
2017-05-31 23:21:42 UTC
I have new information. My current OS is Linux from Scratch. I tried Dying Light in Ubuntu and it works. The log still show no video memory. So, that is not the problem. The only thing different in Ubuntu's logs is the reported pciids for the video card. Right after the seg fault in the logs my target OS give the line: GPU's vendor id: 1 [0x0001]; GPU's device id: 2 [0x0002]. instead of [0x1002:0x67ef]. Those are incorrectly filled. But nvidia closed drivers reports the same thing. So that isn't the problem. ______________________________________ At the steam console with mesa debugging turned on I get some interesting lines. Steam: An X Error occurred X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 40 (X_TranslateCoords) Resource id in failed request: 0x1000fce Serial number of failed request: 25757 xerror_handler: X failed, continuing . . . Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) Mesa: 4 similar GL_INVALID_OPERATION errors Mesa: User error: GL_INVALID_ENUM in glEnable(GL_TEXTURE_2D) Mesa: User error: GL_INVALID_ENUM in glDisable(GL_TEXTURE_2D) My guess is I need help in tracing this. How would you trace a steam game? (In reply to Anthony Jagers from comment #2) > My guess is I need help in tracing this. > How would you trace a steam game? See https://wiki.archlinux.org/index.php/Steam/Troubleshooting#Debugging_Steam No idea which extension the game uses, so it may be that Mesa does not implement it. IIRC only GLX_MESA_query_renderer is done - see the output of glxinfo. You'll get something like Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) (0x1616) Version: 17.0.7 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.1 Whatever the problem is, it is clearly not a mesa bug. It seems only lesser used distros are having problems. Gentoo and LFS are the ones. I'm closing this. Closed That bug is due to missing /usr/bin/lspci. Dying Light tries to execve /usr/bin/lspci in a fork and when it fails it calls exit function instead of _exit. exit calls exit handler registered by mesa which causes the segmentation fault and 'hangup' of Dying Light. I have reported this bug to the developers on 10th May 2018. Additional info that some people might find useful: a) Dying Light requires haptic support in SDL, otherwise it shows uninformative dialog and exits. b) Dying Light requires OpenGL 4.4 (according to devs) and uses glew to detect OpenGL version which parses GL version string. Since mesa returns OpenGL version 3.0~3.1 for GL contexts created by glew, override variables have to be used to run Dying Light, e.g.: MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command% in launch options in steam. Sorry for commenting inside "resolved" bug. |
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.