[Mesa-dev] [Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start

[b***@freedesktop.org]

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

Jamey Sharp <***@minilop.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
OS|Linux (All) |All
CC| |***@minilop.net
Component|Drivers/Gallium/radeonsi |Mesa core
QA Contact|dri-***@lists.freedesktop |mesa-***@lists.freedesktop.
|.org |org
Hardware|x86-64 (AMD64) |All
Assignee|dri-***@lists.freedesktop |mesa-***@lists.freedesktop.
|.org |org

--- Comment #10 from Jamey Sharp <***@minilop.net> ---
(In reply to smidjar2.reg from comment #6)

I disassembled ApplyConstants() where the game crashes when using OpenGL
override to 4.2.

I spent a while poking at this crash in gdb, and I was definitely seeing the
same segfault at the same instruction and call-stack.

I've sent a (one-line!) patch to mesa-dev that fixes this segfault on startup:

https://lists.freedesktop.org/archives/mesa-dev/2016-April/114614.html

And a Piglit patch that tests for the non-conforming behavior that led to this
crash:

https://lists.freedesktop.org/archives/mesa-dev/2016-April/114613.html

Thanks to Karol Herbst's mesa-dev post, linked from comment #7, for pointing me
in the right direction to find this Mesa bug.

Granted, the game developers ought to check for errors returned from
glLinkProgram and fail more gracefully than a segfault, but I doubt we're going
to get them to do *that*...

I can now play this game somewhat successfully on i965 with
MESA_GL_VERSION_OVERRIDE=4.2. There are still plenty of rendering bugs I
haven't dug into yet, but I played for an hour without crashes, at least!

I don't have (or particularly want) a commit bit on Mesa or Piglit, so now we
need somebody to review and hopefully merge these patches.

[b***@freedesktop.org]

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

--- Comment #11 from Ernst Sjöstrand <***@gmail.com> ---
If I apply the "change shader" fix with RadeonSI I get a bunch of these
glNamedStringARB errors when running the game with APITrace:

2833: message: major api error 1: GL_INVALID_OPERATION in unsupported function
called (unsupported extension or deprecated function?)
2833 @0 glNamedStringARB(type = GL_SHADER_INCLUDE_ARB, namelen = -1, name =
"/Shaders/GlobalConstants_OGL.shdh", stringlen = 1553, string = "#define HD4000
0

glNamedStringARB is from ARB_shading_language_include, which is not implemented
in Mesa afaict? Probably because the extension is not part of any GL
specification?

[b***@freedesktop.org]

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

--- Comment #12 from Jamey Sharp <***@minilop.net> ---
(In reply to Ernst Sjöstrand from comment #11)

Post by b***@freedesktop.org
If I apply the "change shader" fix with RadeonSI I get a bunch of these

But you can confirm that my patch fixes the crash on startup, right?

I've opened bug #95215 for implementing ARB_shading_language_include.

I think *this* bug can be resolved once my patch is merged in Mesa.

[b***@freedesktop.org]

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

Timothy Arceri <***@yahoo.com.au> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED

--- Comment #13 from Timothy Arceri <***@yahoo.com.au> ---
Fixed by:

author Jamey Sharp <***@minilop.net>
committer Timothy Arceri <***@collabora.com>
commit 595d56cc866638f371626cc1d0137a6a54a7d0f8

glShaderSource must not change compile status.

OpenGL 4.5 Core Profile section 7.1, in the documentation for
CompileShader, says: "Changing the source code of a shader object with
ShaderSource does not change its compile status or the compiled shader
code."

According to Karol Herbst, the game "Divinity: Original Sin - Enhanced
Edition" depends on this odd quirk of the spec.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93551
Signed-off-by: Jamey Sharp <***@minilop.net>
Reviewed-by: Ian Romanick <***@intel.com>
Reviewed-by: Kenneth Graunke <***@whitecape.org>
Reviewed-by: Timothy Arceri <***@collabora.com>

[b***@freedesktop.org]

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

--- Comment #14 from Ernst Sjöstrand <***@gmail.com> ---
I still get the ApplyConstants() crash, both with and without your fix it seems
like.
Is your fix for the ChangeShader() crash?

[b***@freedesktop.org]

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

--- Comment #15 from Jamey Sharp <***@minilop.net> ---
(In reply to Ernst Sjöstrand from comment #14)

Post by b***@freedesktop.org
I still get the ApplyConstants() crash, both with and without your fix it
seems like.
Is your fix for the ChangeShader() crash?

Hmm. No, I'm still just working around the ChangeShader crash with
MESA_GL_VERSION_OVERRIDE=4.2. That patch fixed the ApplyConstants crash for me.
I hate to ask, but are you sure you're testing with the patched Mesa?

[b***@freedesktop.org]

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

--- Comment #16 from Ernst Sjöstrand <***@gmail.com> ---
Yes I know because when I merged in
https://github.com/karolherbst/mesa/commits/ARB_shading_language_include I
suddenly got a loading progress bar and a splash screen. However at 95% it
crashed like this instead:

shader 778 count 1 string 103C70B511F7679091DC56132979D359 length -1
shader 652 count 1 string 624FCDF076807F156DBD30FB6C3F4668 length -1
shader 780 count 1 string CC5F8835705A6A4CFBBA629BE97C3F72 length -1
shader 225 count 1 string DF99049D80233C85B78294C6A86F5E82 length -1
shader 265 count 1 string 19EAE983A5FB81AC8E9D4B850BB124B4 length -1
Thread "EoCApp" (4215990208)
received signal 11

Call stack:

(0) /lib/x86_64-linux-gnu/libpthread.so.0 : +0x113d0 [0x7f8afe63c3d0]
(1) ./libOGLBinding.so : api::OpenGLRenderer::ApplyConstants()+0x65
[0x7f8aff570845]
(2) ./libRenderFramework.so : rf::Renderer::Apply(bool)+0x57 [0x7f8aff216437]
(3) ./libRenderFramework.so : rf::RCB_ApplyCommand::Execute(rf::Renderer*, void
const*)+0xd [0x7f8aff231f4d]
(4) ./libRenderFramework.so :
rf::RendererCommandBuffer::ExecuteCommandBuffer(bool)+0x37 [0x7f8aff21ec77]
(5) ./libGameEngine.so : ls::PostProcessStage::Execute(rf::RenderView
const*)+0x44 [0x7f8aff37cde4]
(6) ./libRenderFramework.so : rf::StageGroup::Execute(rf::RenderView const*)
const+0x31 [0x7f8aff2284d1]
(7) ./EoCApp : ecl::EoCRenderView::Execute()+0x114 [0x95b664]
(8) ./libRenderFramework.so : rf::RenderFrame::Execute()+0x60 [0x7f8aff21d570]
(9) ./libGameEngine.so : BaseApp::ExecuteFrame(rf::Renderer*)+0x1c
[0x7f8aff370d9c]
(10) ./libGameEngine.so : BaseApp::MakeFrame()+0x33b [0x7f8aff37146b]
(11) ./libGameEngine.so : BaseApp::OnIdle()+0xe0 [0x7f8aff36fcb0]
(12) ./EoCApp : main+0x170 [0x6d5180]
(13) /lib/x86_64-linux-gnu/libc.so.6 : __libc_start_main+0xf0 [0x7f8afe282830]
(14) ./EoCApp : _start+0x29 [0x6d4ef9]
Segmentation fault

[b***@freedesktop.org]

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

--- Comment #17 from Jamey Sharp <***@minilop.net> ---
(In reply to Ernst Sjöstrand from comment #16)

Post by b***@freedesktop.org
Yes I know because when I merged in
https://github.com/karolherbst/mesa/commits/ARB_shading_language_include I
suddenly got a loading progress bar and a splash screen. However at 95% it

Oh, I never tested Karol's patches and didn't entirely understand them, to be
honest. I don't think those patches actually tried to fix the ApplyConstants
crash, just the lack of ARB_shading_language_include. Would you try my patch
instead? It's merged to Mesa git master now (thanks Timothy!), so you can just
build stock Mesa.

I've just re-tested that Mesa commit cf6dadb00b93b828e8cc95e8136d4c2013d76e40,
which was the newest when I checked a few minutes ago, works with this game for
me on Intel graphics.

I'm using two workarounds in addition to the Mesa fix. One is
MESA_GL_VERSION_OVERRIDE=4.2. The other is to configure the game to cap its
frame-rate to 15 fps, because if the game renders frames too quickly, I get all
sorts of wrong drawing. (Sarah glanced at it and thought it might be missing
sync fences or some such thing, leading to some rendering finishing after the
buffer swap.)

Even then I have some textures getting sprayed on the screen in places they
shouldn't be and UI icons often failing to show up at all, but the game is
fairly playable for me.

If you still get the ApplyConstants crash with the git master version of Mesa,
I'm afraid you're going to have to do more debugging to find out why, since I
can't reproduce the problem any more.

[b***@freedesktop.org]

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

--- Comment #18 from Ernst Sjöstrand <***@gmail.com> ---
Jamey: I have had your patch applied the whole time, now I tested with you
patch + Karol's patches. It seems highly unlikely to me that the game would
have any chance of working without ARB_shading_language_include if those
features are actually used, which they seem to be in my case at least.

Radeon exposes 4.2 by default, I tried with 4.3 also just to experiment.

[b***@freedesktop.org]

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

Vladimir Usikov <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED

--- Comment #19 from Vladimir Usikov <***@gmail.com> ---

mesa git 5541e11

[***@ArchLinux Divinity Original Sin Enhanced Edition]$ LANG=C ./start.sh
Running Divinity: Original Sin - Enhanced Edition
Language detected: English
[S_API FAIL] SteamAPI_Init() failed; no appID found.
Either launch the game from Steam, or put the file steam_appid.txt containing
the correct appID in your game folder.
Thread "EoCApp" (1988364224)
received signal 11

Call stack:

(0) /usr/lib/libpthread.so.0 : +0x10e80 [0x7f7b722fbe80]
(1) ./libOGLBinding.so : api::OpenGLRenderer::ApplyConstants()+0x65
[0x7f7b73247845]
(2) ./libRenderFramework.so : rf::Renderer::Apply(bool)+0x57 [0x7f7b72ee6437]
(3) ./EoCApp : ig::IggyBinding::Swap(rf::Renderer*)+0xfc [0xececfc]
(4) ./libGameEngine.so : BaseApp::EndDrawGUI(rf::Renderer*)+0x9b
[0x7f7b73043dcb]
(5) ./libGameEngine.so : BaseApp::MakeFrame()+0x3a4 [0x7f7b730442f4]
(6) ./libGameEngine.so : BaseApp::OnIdle()+0xe0 [0x7f7b73042ad0]
(7) ./EoCApp : main+0x170 [0x6d4dc0]
(8) /usr/lib/libc.so.6 : __libc_start_main+0xf0 [0x7f7b71f63710]
(9) ./EoCApp : _start+0x29 [0x6d4b39]
./runner.sh: line 3: 6081 Segmentation fault (core dumped)
LD_LIBRARY_PATH="." ./EoCApp

[b***@freedesktop.org]

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

Vladimir Usikov <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |---
Status|CLOSED |REOPENED

[b***@freedesktop.org]

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

--- Comment #20 from kilobug <***@kilobug.org> ---
I just tried with latest Mesash->CompileStatus = GL_FALSE;

[b***@freedesktop.org]

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

--- Comment #21 from kilobug <***@kilobug.org> ---
(In reply to kilobug from comment #20)

Post by b***@freedesktop.org
I just tried with latest Mesash->CompileStatus = GL_FALSE;

Hrm sorry didn't finish my comment, sorry for the noise :/

So, I just tried with latest Mesa from Oibaf's PPA on my Radeon R9 380X which
contains the patch for "sh->CompileStatus = GL_FALSE;" and I still get :

(***@drizzt) ~/gog/Divinity Original Sin Enhanced Edition $
ALSOFT_DRIVERS=pulse MESA_GL_VERSION_OVERRIDE=4.2 ./start.sh
Running Divinity: Original Sin - Enhanced Edition
Language detected: English
Thread "EoCApp" (2444249152)
received signal 11

Call stack:

(0) /lib/x86_64-linux-gnu/libpthread.so.0 : +0x10d30 [0x7f8d8d2ebd30]
(1) ./libOGLBinding.so : api::OpenGLRenderer::ApplyConstants()+0x65
[0x7f8d91b87845]
(2) ./libRenderFramework.so : rf::Renderer::Apply(bool)+0x57 [0x7f8d91b3e437]
(3) ./EoCApp : ig::IggyBinding::Swap(rf::Renderer*)+0xfc [0xed032c]
(4) ./libGameEngine.so : BaseApp::EndDrawGUI(rf::Renderer*)+0x9b
[0x7f8d8e01bfab]
(5) ./libGameEngine.so : BaseApp::MakeFrame()+0x3a4 [0x7f8d8e01c4d4]
(6) ./libGameEngine.so : BaseApp::OnIdle()+0xe0 [0x7f8d8e01acb0]
(7) ./EoCApp : main+0x170 [0x6d5180]
(8) /lib/x86_64-linux-gnu/libc.so.6 : __libc_start_main+0xf0 [0x7f8d8cf53610]
(9) ./EoCApp : _start+0x29 [0x6d4ef9]
Segmentation fault

[b***@freedesktop.org]

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

--- Comment #22 from Karol Herbst <***@karolherbst.de> ---
this is due the game requiring a 4.2 context. They asked for it and then it
crashes because they don't error check.

Then the game crashes because there is no ARB_shading_language_include.

try out:

https://github.com/karolherbst/mesa.git
branch: ARB_shading_language_include

but you will get graphical glitches, because you need to spoof the GL vendor to
ATI to force the ATI rendering path

[b***@freedesktop.org]

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

--- Comment #23 from Karol Herbst <***@karolherbst.de> ---
(In reply to Jamey Sharp from comment #17)

Post by b***@freedesktop.org
(In reply to Ernst Sjöstrand from comment #16)

Post by b***@freedesktop.org
Yes I know because when I merged in
https://github.com/karolherbst/mesa/commits/ARB_shading_language_include I
suddenly got a loading progress bar and a splash screen. However at 95% it

Oh, I never tested Karol's patches and didn't entirely understand them, to
be honest. I don't think those patches actually tried to fix the
ApplyConstants crash, just the lack of ARB_shading_language_include. Would
you try my patch instead? It's merged to Mesa git master now (thanks
Timothy!), so you can just build stock Mesa.
I've just re-tested that Mesa commit
cf6dadb00b93b828e8cc95e8136d4c2013d76e40, which was the newest when I
checked a few minutes ago, works with this game for me on Intel graphics.
I'm using two workarounds in addition to the Mesa fix. One is
MESA_GL_VERSION_OVERRIDE=4.2. The other is to configure the game to cap its
frame-rate to 15 fps, because if the game renders frames too quickly, I get
all sorts of wrong drawing. (Sarah glanced at it and thought it might be
missing sync fences or some such thing, leading to some rendering finishing
after the buffer swap.)
Even then I have some textures getting sprayed on the screen in places they
shouldn't be and UI icons often failing to show up at all, but the game is
fairly playable for me.
If you still get the ApplyConstants crash with the git master version of
Mesa, I'm afraid you're going to have to do more debugging to find out why,
since I can't reproduce the problem any more.

not entirely true. Yes they partly implement ARB_shading_language_include, But
I also hacked around the compile status thing. And then you need a 4.2 context.

Anyhow, their engine requires ARB_shading_language_include, GL4.2 and
595d56cc866638f371626cc1d0137a6a54a7d0f8

[b***@freedesktop.org]

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

--- Comment #25 from kilobug <***@kilobug.org> ---
Perhaps it's due to LLVM version, for the Intel vs radeonsi ? I tried with llvm
3.8, and some of OpenGL 4.2 extensions require llvm 3.9... but I've to admit it
scares me a bit to recompile llvm and all of mesa with an experimental llvm...
I'll see what I can do.

And yeah, I'm a bit disappointed by how Larian handled the Linux version...
they made us wait for years (despite us backing the game on Kickstarter because
it advertised Linux support) and then they deliver this buggy thing that uses
non-standard OpenGL extensions, and stop support :/ But well... I've full faith
that radeonsi will one day support it, Mesa devs are amazing :)

[b***@freedesktop.org]

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

--- Comment #24 from Jamey Sharp <***@minilop.net> ---
(In reply to Karol Herbst from comment #23)

Post by b***@freedesktop.org
Anyhow, their engine requires ARB_shading_language_include, GL4.2 and
595d56cc866638f371626cc1d0137a6a54a7d0f8

I'm still super confused about this. I'm playing the game more or less
successfully on Intel graphics, without ARB_shading_language_include, and while
disassembling I found code paths in the game to handle the case where that
extension isn't supported.

Also, all the extensions between OpenGL 4.0 and 4.2 that are implemented on
Intel are also implemented on radeonsi, according to mesamatrix.net.

So what's different when the game runs on radeonsi? Why does it crash there but
work on Intel? I can provide a short apitrace from a successful run on Intel if
you want to try replaying it on your drivers; e-mail me if you want it.

BTW, the game developers tell me that all Linux development has stopped and we
shouldn't expect any new patches from them. :-(

[b***@freedesktop.org]

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

--- Comment #26 from Karol Herbst <***@karolherbst.de> ---
(In reply to kilobug from comment #25)

Post by b***@freedesktop.org
Perhaps it's due to LLVM version, for the Intel vs radeonsi ? I tried with
llvm 3.8, and some of OpenGL 4.2 extensions require llvm 3.9... but I've to
admit it scares me a bit to recompile llvm and all of mesa with an
experimental llvm... I'll see what I can do.
And yeah, I'm a bit disappointed by how Larian handled the Linux version...
they made us wait for years (despite us backing the game on Kickstarter
because it advertised Linux support) and then they deliver this buggy thing
that uses non-standard OpenGL extensions, and stop support :/ But well...
I've full faith that radeonsi will one day support it, Mesa devs are amazing
:)

Well there are simple hacks now to get divinity running.

https://github.com/karolherbst/mesa/commit/aad2543bf6cfbd7df795d836e5ff4ec8686e4fdf
(by Laurent Carlier)

and

https://gist.github.com/karolherbst/b279233f8b13c9db1f3e1e57c6ecfbd2
(by Kenneth Graunke)

recent mesa master + both patches + forcing gl 4.2 + forcing glsl 420 should
work for you.

[b***@freedesktop.org]

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

--- Comment #27 from Karol Herbst <***@karolherbst.de> ---
as it turns out, divinity also needs allow_glsl_extension_directive_midshader

[b***@freedesktop.org]

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

Vedran Miletić <***@miletic.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@miletic.net

--- Comment #28 from Vedran Miletić <***@miletic.net> ---
(In reply to Karol Herbst from comment #26)

Post by b***@freedesktop.org
Well there are simple hacks now to get divinity running.
https://github.com/karolherbst/mesa/commit/
aad2543bf6cfbd7df795d836e5ff4ec8686e4fdf
(by Laurent Carlier)
and
https://gist.github.com/karolherbst/b279233f8b13c9db1f3e1e57c6ecfbd2
(by Kenneth Graunke)
recent mesa master + both patches + forcing gl 4.2 + forcing glsl 420 should
work for you.

It works on radeonsi with those two patches and
https://gist.github.com/karolherbst/56a548cf74b514baf0889b9ad5d7cf48

With recent enough Mesa, forcing OpenGL 4.2 and GLSL 420 is not required.

[b***@freedesktop.org]

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

--- Comment #30 from Vedran Miletić <***@miletic.net> ---
(In reply to kilobug from comment #29)

Post by b***@freedesktop.org
With recent enough Mesa, forcing OpenGL 4.2 and GLSL 420 is not required.

Did you use llvm 3.8 or 3.9 ?

3.9.

[b***@freedesktop.org]

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

Post by b***@freedesktop.org
With recent enough Mesa, forcing OpenGL 4.2 and GLSL 420 is not required.

Did you use llvm 3.8 or 3.9 ?

[b***@freedesktop.org]

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

Kai <***@dev.carbon-project.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@dev.carbon-project.org

--- Comment #31 from Kai <***@dev.carbon-project.org> ---
Seeing a crash on start as well with the following stack (Debian testing as a
base):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/cee459d84d
libdrm: 2.4.68-1
LLVM: SVN:trunk/r271192 (3.9 devel)
X.Org: 2:1.18.3-1
Linux: 4.5.4
Firmware: firmware-amd-graphics/20160110-1
libclc: Git:master/20d977a3e6
DDX: 1:7.7.0-1

[b***@freedesktop.org]

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

Jonas Platte <***@jonasplatte.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@jonasplatte.de

[b***@freedesktop.org]

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

Thomas J. Moore <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #32 from Thomas J. Moore <***@gmail.com> ---
Created attachment 125302
--> https://bugs.freedesktop.org/attachment.cgi?id=125302&action=edit
Simple LD_PRELOAD shim to apply necessary patches for divos

Game works great for me with the above patches (thanks to those who figured
this out!). However, since they are not likely to be incorporated into Mesa,
and patching my system Mesa just for one poorly written game is a bad idea, I
think one of two alternate solutions needs to be provided. My preference would
be to patch the game binaries. I don't really want to mess with that right
now, though (especially since I can't easily locate where it does the vendor
check). The other would be to provide the patches in the form of an LD_PRELOAD
shim. I have attached the source code for one that seems to work for me.

[b***@freedesktop.org]

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

--- Comment #33 from Mikhail Korolev <***@gmail.com> ---
Created attachment 125311
--> https://bugs.freedesktop.org/attachment.cgi?id=125311&action=edit
divos-hack.patch

(In reply to Thomas J. Moore from comment #32)

Created attachment 125302 [details]
Simple LD_PRELOAD shim to apply necessary patches for divos
Game works great for me with the above patches (thanks to those who figured
this out!). However, since they are not likely to be incorporated into
Mesa, and patching my system Mesa just for one poorly written game is a bad
idea, I think one of two alternate solutions needs to be provided. My
preference would be to patch the game binaries. I don't really want to mess
with that right now, though (especially since I can't easily locate where it
does the vendor check). The other would be to provide the patches in the
form of an LD_PRELOAD shim. I have attached the source code for one that
seems to work for me.

Your code calls dlsym at every call of glGetString/glXGetProcAddressARB instead
of call it only at startup. Fix in attachments.

[b***@freedesktop.org]

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

--- Comment #34 from Mikhail Korolev <***@gmail.com> ---
(In reply to Thomas J. Moore from comment #32)

Created attachment 125302 [details]
Simple LD_PRELOAD shim to apply necessary patches for divos
Game works great for me with the above patches (thanks to those who figured
this out!). However, since they are not likely to be incorporated into
Mesa, and patching my system Mesa just for one poorly written game is a bad
idea, I think one of two alternate solutions needs to be provided. My
preference would be to patch the game binaries. I don't really want to mess
with that right now, though (especially since I can't easily locate where it
does the vendor check). The other would be to provide the patches in the
form of an LD_PRELOAD shim. I have attached the source code for one that
seems to work for me.

As for vendor check location:

[ /media/Storage/Games/GOG/Linux/DivinityOriginalSinEnhancedEdition/game ] $
GAME_DIR="/media/Storage/Games/GOG/Linux/DivinityOriginalSinEnhancedEdition"
MESA_GL_VERSION_OVERRIDE=4.2 MESA_GLSL_VERSION_OVERRIDE=420
LD_PRELOAD="${GAME_DIR}/workaround/divos-hack-f.so"
LD_LIBRARY_PATH="${GAME_DIR}/game" gdb -q ${GAME_DIR}/game/EoCApp
Reading symbols from
/media/Storage/Games/GOG/Linux/DivinityOriginalSinEnhancedEdition/game/EoCApp...(no
debugging symbols found)...done.
(gdb) b divos-hack-f.c:38
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (divos-hack-f.c:38) pending.
(gdb) ru
Starting program:
/media/Storage/Games/GOG/Linux/DivinityOriginalSinEnhancedEdition/game/EoCApp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffe4827700 (LWP 1452)]

Thread 1 "EoCApp" hit Breakpoint 1, glGetString (name=7936) at
divos-hack-f.c:38
38 return (const GLubyte *)vendor;
(gdb) bt
#0 glGetString (name=7936) at divos-hack-f.c:38
#1 0x00007ffff4624dce in api::OpenGLRenderer::OpenGLRenderer(api::IAPI*,
void*) ()
from
/media/Storage/Games/GOG/Linux/DivinityOriginalSinEnhancedEdition/game/libOGLBinding.so
#2 0x00007ffff4623f79 in api::OpenGLAPI::CreateRenderer() () from
/media/Storage/Games/GOG/Linux/DivinityOriginalSinEnhancedEdition/game/libOGLBinding.so
#3 0x00007ffff4623b23 in api::OpenGLAPI::Init() () from
/media/Storage/Games/GOG/Linux/DivinityOriginalSinEnhancedEdition/game/libOGLBinding.so
#4 0x00007ffff44309aa in BaseApp::InitAPI() () from
/media/Storage/Games/GOG/Linux/DivinityOriginalSinEnhancedEdition/game/libGameEngine.so
#5 0x00007ffff442f578 in BaseApp::Start(ls::InitStruct*) () from
/media/Storage/Games/GOG/Linux/DivinityOriginalSinEnhancedEdition/game/libGameEngine.so
#6 0x00000000006d5160 in main ()
(gdb)

[b***@freedesktop.org]

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

--- Comment #35 from Thomas J. Moore <***@gmail.com> ---
(In reply to Mikhail Korolev from comment #33)

Post by b***@freedesktop.org
Your code calls dlsym at every call of glGetString/glXGetProcAddressARB
instead of call it only at startup.

If so, your version of gcc is broken. Just in case my gcc is broken as well, I
checked with gdb and the lines of code executing dlsym are executed exactly
once, while the wrappers themselves are called more than once. The only error
I can see on reviewing my code is that I misspelled Enhanced, which is not
worth correcting. That's not to say my code is perfect, though.

Post by b***@freedesktop.org
Fix in attachments.

If you say so. Thanks for trying, at least. Seems more complex to me with
little benefit (the benefit being no longer executing the NULL check every
call, which probably takes a few nanoseconds). In fact, using _init like that
makes me uncomfortable, since the time of symbol resolution is less obvious.
If it works, it works, though.

(In reply to Mikhail Korolev from comment #33)
Thanks. I guess what I really meant to say is that I no longer have the
patience and dedication needed to properly reverse engineer and provide patches
for the code. Last time I did that was over 20 years ago
(http://aminet.net/package/disk/misc/cdfix).

[b***@freedesktop.org]

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

--- Comment #36 from Mikhail Korolev <***@gmail.com> ---
(In reply to Thomas J. Moore from comment #35)

Post by b***@freedesktop.org
(In reply to Mikhail Korolev from comment #33)

Post by b***@freedesktop.org
Your code calls dlsym at every call of glGetString/glXGetProcAddressARB
instead of call it only at startup.

If so, your version of gcc is broken. Just in case my gcc is broken as
well, I checked with gdb and the lines of code executing dlsym are executed
exactly once, while the wrappers themselves are called more than once. The
only error I can see on reviewing my code is that I misspelled Enhanced,
which is not worth correcting. That's not to say my code is perfect, though.

My fault. I missed `static` part. Sorry for distraction.

[b***@freedesktop.org]

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

--- Comment #37 from kilobug <***@kilobug.org> ---
(In reply to Thomas J. Moore from comment #32)

Created attachment 125302 [details]
Simple LD_PRELOAD shim to apply necessary patches for divos
Game works great for me with the above patches (thanks to those who figured
this out!). However, since they are not likely to be incorporated into
Mesa, and patching my system Mesa just for one poorly written game is a bad
idea, I think one of two alternate solutions needs to be provided. My
preference would be to patch the game binaries. I don't really want to mess
with that right now, though (especially since I can't easily locate where it
does the vendor check). The other would be to provide the patches in the
form of an LD_PRELOAD shim. I have attached the source code for one that
seems to work for me.

Thanks for the LD_PRELOAD shim. I just tried it on my R9 R380X using padoka's
ppa (so git Mesa 12.1~git1600727202100.29d70cc~x~padoka0 + svn LLVM
1:4.0~svn276446-0~x~padoka0), and there is a significant improvement, the game
starts and displays the loading screen... but when the loading bar is full,
then it crashes with :


(0) /lib/x86_64-linux-gnu/libpthread.so.0 : +0x10ed0 [0x7f209566ded0]
(1) ./libOGLBinding.so : api::OpenGLRenderer::ApplyConstants()+0x65
[0x7f209a129845]
(2) ./libRenderFramework.so : rf::Renderer::Apply(bool)+0x57 [0x7f209a0e0437]
(3) ./libRenderFramework.so : rf::RCB_ApplyCommand::Execute(rf::Renderer*, void
const*)+0xd [0x7f209a0fbf4d]
(4) ./libRenderFramework.so :
rf::RendererCommandBuffer::ExecuteCommandBuffer(bool)+0x37 [0x7f209a0e8c77]
(5) ./libGameEngine.so : ls::PostProcessStage::Execute(rf::RenderView
const*)+0x44 [0x7f20963b1de4]
(6) ./libRenderFramework.so : rf::StageGroup::Execute(rf::RenderView const*)
const+0x31 [0x7f209a0f24d1]
(7) ./EoCApp : ecl::EoCRenderView::Execute()+0x114 [0x95b664]
(8) ./libRenderFramework.so : rf::RenderFrame::Execute()+0x60 [0x7f209a0e7570]
(9) ./libGameEngine.so : BaseApp::ExecuteFrame(rf::Renderer*)+0x1c
[0x7f20963a5d9c]
(10) ./libGameEngine.so : BaseApp::MakeFrame()+0x33b [0x7f20963a646b]
(11) ./libGameEngine.so : BaseApp::OnIdle()+0xe0 [0x7f20963a4cb0]
(12) ./EoCApp : main+0x170 [0x6d5180]
(13) /lib/x86_64-linux-gnu/libc.so.6 : __libc_start_main+0xf0 [0x7f20952d5730]
(14) ./EoCApp : _start+0x29 [0x6d4ef9]

I tried with and without MESA_GL_VERSION_OVERRIDE=4.2
MESA_GLSL_VERSION_OVERRIDE=420 and it doesn't change anything.

Did I miss something ?

[b***@freedesktop.org]

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

Post by b***@freedesktop.org
Did I miss something ?

allow_glsl_extension_directive_midshader=true ?

[b***@freedesktop.org]

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

--- Comment #39 from kilobug <***@kilobug.org> ---
(In reply to Iaroslav Andrusyak from comment #38)

Post by b***@freedesktop.org

Post by b***@freedesktop.org
Did I miss something ?

allow_glsl_extension_directive_midshader=true ?

Thanks, that was it !

Here is how I can run the game :

allow_glsl_extension_directive_midshader=true ALSOFT_DRIVERS=pulse
LD_PRELOAD="/usr/local/lib/divos-hack.so" ./start.sh

[b***@freedesktop.org]

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

--- Comment #40 from Kai <***@dev.carbon-project.org> ---
Shouldn't this bug be closed as "NOTOURBUG", since it's clearly a game bug? Or
at least as "WONTFIX", since the hack is probably never going to land in Mesa
anyway?

On a different note: I can confirm, that the shim from attachment 125302 in
addition to allowing mid-shader extension directives let me launch and play the
game.

[b***@freedesktop.org]

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

--- Comment #41 from kilobug <***@kilobug.org> ---
(In reply to Kai from comment #40)

Post by b***@freedesktop.org
Shouldn't this bug be closed as "NOTOURBUG", since it's clearly a game bug?
Or at least as "WONTFIX", since the hack is probably never going to land in
Mesa anyway?

In my humble non expert opinion, the "hack" that allows an env variable to
spoof the vendor string could make it in. It's not something that should be
done generally, but it seems generic enough as both a debugging tool and a
workaround for a variety of quirky games/programs.

[b***@freedesktop.org]

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

--- Comment #42 from Alex <***@gmail.com> ---
(In reply to Thomas J. Moore from comment #32)

Created attachment 125302 [details]
Simple LD_PRELOAD shim to apply necessary patches for divos
Game works great for me with the above patches (thanks to those who figured
this out!). However, since they are not likely to be incorporated into
Mesa, and patching my system Mesa just for one poorly written game is a bad
idea, I think one of two alternate solutions needs to be provided. My
preference would be to patch the game binaries. I don't really want to mess
with that right now, though (especially since I can't easily locate where it
does the vendor check). The other would be to provide the patches in the
form of an LD_PRELOAD shim. I have attached the source code for one that
seems to work for me.

Would it be possible to add another function to that shim to override the
output of sysconf (_SC_NPROCESSORS_ONLN)? I spoke to the developer and
apparently the game will only use as many "worker" threads (indicated by "[N]
WT" in the app title bar) as your number of cores minus the main thread, but if
you're in an environment where your single-threaded performance is heavily
constrained (e.g. a Y series Intel notebook chip like mine, when using the iGPU
throttles the CPU speeds) but you have multiple cores available, this isn't
ideal. From looking at my CPU usage under Divinity I'd really like to be able
to hack it to give me 2-3 worker threads instead of 1 to see if that helps
performance at all... I don't have much C experience though.

[b***@freedesktop.org]

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

--- Comment #43 from Aaron Watry <***@gmail.com> ---
I'm not saying it's the ideal solution, but you could force any undesired CPU
cores offline before starting the game if it's affecting the performance
severely.

e.g. echo 0 > /sys/devices/system/cpu/cpuX/online

[b***@freedesktop.org]

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

--- Comment #44 from Thomas J. Moore <***@gmail.com> ---
(In reply to Alex from comment #42)

Post by b***@freedesktop.org
Would it be possible to add another function to that shim to override the
output of sysconf (_SC_NPROCESSORS_ONLN)?

I don't think this bug report is an appropriate place to discuss things not
related to Mesa. In fact, I'm all for closing this bug as fixed, since all
actual bugs in Mesa have been fixed. Unfortunately, there isn't really
anyplace else to go. Perhaps someplace on the Larian forums (which will
exclude me, since I hate vendor forums)?

In any case, I've gone ahead and made the requested change, and put it on
bitbucket:

https://bitbucket.org/darktjm/divos-hack/raw/844453d027e683c5d9830d42c6edf05f4735ddc3/divos-hack.c

This allows you to set the # of processors reported with the env variable
PROCESSORS_ONLINE. You can also post issues against this at bitbucket:

https://bitbucket.org/darktjm/divos-hack/issues

[b***@freedesktop.org]

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

--- Comment #45 from Karol Herbst <***@gmail.com> ---
as far as I know there are no linux devs at larian anymore and the linux
version won't be touched at all.

[b***@freedesktop.org]

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

daradib <***@quietapple.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@quietapple.org

[b***@freedesktop.org]

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

--- Comment #46 from ***@gmail.com ---
Step by step guide for GOG version:
1) Download the source for the LD_PRELOAD shim
2) Compile it using the command given inside the just downloaded patch file.
This will give you a divos-hack.so file.
gcc -s -O2 -shared -fPIC -o divos-hack.{so,c} -ldl
3) Copy the just created divos-hack.so file to your Divinity: Original Sin game
folder (the subfolder called game, within the install path)
4) now, from said game folder, run Divinity using the following command:
allow_glsl_extension_directive_midshader=true LD_PRELOAD="divos-hack.so"
./runner.sh

Step by step guide for Steam vesion:
1) Download the source for the LD_PRELOAD shim
2) Compile it using the command given inside the just downloaded patch file.
This will give you a divos-hack.so file.
gcc -s -O2 -shared -fPIC -o divos-hack.{so,c} -ldl
3) Copy the just created divos-hack.so file to your Divinity: Original Sin game
folder (the subfolder called game, within the install path)
4) Go to the preferences of Divinity: OS in your Steam Library (right click on
the entry -> Preferences), and open the "Set Launch Options" dialogue. There,
put the following:
allow_glsl_extension_directive_midshader=true
LD_PRELOAD="divos-hack.so:$LD_PRELOAD" %command%

source:
https://www.gamingonlinux.com/articles/divinity-original-sin-may-soon-work-with-mesa-drivers.8867/page=2#r81524

[b***@freedesktop.org]

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

--- Comment #47 from Robert G. Brown <***@phy.duke.edu> ---
Installed the shim for Fedora 25, XFCE, and Steam. It worked. Upgraded to F26
(it no longer worked) and then to F27 (and it still no longer works). I've
played with it a fair bit, reinstalled the Divinity binaries, and no matter
what I try, I still get the instant crash.

[b***@freedesktop.org]

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

Philipp Claßen <***@gmx.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmx.net

[b***@freedesktop.org]

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

--- Comment #48 from Alex <***@gmail.com> ---
Yes, the shim seems to no longer work -- I assume newer Mesa versions are no
longer declaring compatibility with whatever version Divinity was hardcoded to?

It's probably possible to create another workaround, but I don't have the
knowledge to do so, and this is obviously quite brittle.

[b***@freedesktop.org]

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

--- Comment #49 from Thomas J. Moore <***@gmail.com> ---
(In reply to Alex from comment #48)

Post by b***@freedesktop.org
Yes, the shim seems to no longer work -- I assume newer Mesa versions are no
longer declaring compatibility with whatever version Divinity was hardcoded
to?

Or maybe it's a Fedora issue, or an Intel issue. I can't test either of those
(well, I could probably test Fedora if I wanted to, but that's a lot of work).
I am currently running mesa 18-rc4 (gentoo/amdgpu), and the game still works
fine (as it has in all previous versions I've tested). So it's not "newer
mesa", at least as far as I can tell.

OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.0.0-rc4
OpenGL core profile shading language version string: 4.50

I set allow_glsl_extension_directive_midshader=true in my .drirc, so my startup
script just adds the game dir to LD_LIBRARY_PATH, sets LD_PRELOAD, and runs the
game. I don't even bother removing game-supplied libraries any more, but I
used to remove libopenal*, libpng16*, libSDL2* and libXss* (not sure any more
why).

The only thing I can think of that I do differently that probably does not
affect things is set R600_DEBUG=nodccfb due to bug #102885. I might have some
other magical settings in my .drirc, but I don't feel like stabbing in the
dark.

[b***@freedesktop.org]

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

--- Comment #50 from Yegor Timoshenko <***@riseup.net> ---
This is definitely now an issue on Intel HD 4000. Workaround shim works fine
for 14.1.x and doesn't work starting from 14.2.0. What I've tried:

* building master

* reverting 6177d60a374a3d48969fcb062ac1d82465850cb4

* returning NULL on glCompileShaderIncludeARB (part of unsupported
ARB_shading_language_include extension, see
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_shading_language_include.txt)

No luck so far. I'll probably have to bisect it, but it would be great if
someone more knowledgeable on topic of OpenGL steps in.

[b***@freedesktop.org]

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

--- Comment #51 from Thomas Crider <***@gmail.com> ---
Just a heads up, tried the shim on Arch and it worked just fine.

1. Download the source or copy it into a file named divos-hack.c

2. Open folder containing divos-hack.c in a terminal and type:

gcc -s -O2 -shared -fPIC -o divos-hack.{so,c} -ldl

3. Copy your new divos-hack.so

4. Open Steam, right click Divinity Original Sin > Properties > Local Files >
Browse local files. Paste your new divos-hack.so into the folder.

5. While still in the Properties menus in steam click the General tab, click
Set Launch Options, and set this for the launch options:

LD_PRELOAD=divos-hack.so:$LD_PRELOAD %command%

good luck!

[b***@freedesktop.org]

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

--- Comment #52 from Thomas Crider <***@gmail.com> ---
just adding my system in case others are wondering what hardware:
Arch 4.19 rc4
Mesa-git (18.3)
llvm-svn (7+)
vega 64
amd tr 1950x

[b***@freedesktop.org]

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

--- Comment #53 from Thomas Crider <***@gmail.com> ---
(In reply to Thomas Crider from comment #52)

Post by b***@freedesktop.org
Arch 4.19 rc4
Mesa-git (18.3)
llvm-svn (7+)
vega 64
amd tr 1950x

edit 3:
if you open runner.sh in the divinity original sin folder and just append
LD_PRELOAD=divos-hack.so:$LD_PRELOAD to the 3rd line so it looks like this:

LD_PRELOAD=divos-hack.so:$LD_PRELOAD LD_LIBRARY_PATH="." ./EoCApp

You wont have to set steam launch options.

This is such a stupid fix for this. I don't know why they haven't done this
already..

[b***@freedesktop.org]

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

--- Comment #54 from Thomas Crider <***@gmail.com> ---
I went ahead and tested this with Ubuntu as well:

For ubuntu users you'll need this to compile it:

sudo apt install libglu1-mesa-dev freeglut3-dev mesa-common-dev

I also tested this on a system with an nvidia 1050 ti using proprietary drivers
just to be sure it did not interfere. The shim did not affect the nvidia driver
from running the game. Thus it would be safe for them to ship this fix with the
game..