Bug 93551 - Divinity: Original Sin Enhanced Edition(Native) crash on start
Summary: Divinity: Original Sin Enhanced Edition(Native) crash on start
Status: REOPENED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-01 08:07 UTC by Vladimir Usikov
Modified: 2016-11-16 02:18 UTC (History)
11 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Simple LD_PRELOAD shim to apply necessary patches for divos (1.67 KB, text/plain)
2016-07-24 21:36 UTC, Thomas J. Moore
Details
divos-hack.patch (2.07 KB, patch)
2016-07-25 13:20 UTC, Mikhail Korolev
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Usikov 2016-01-01 08:07:33 UTC
LD_LIBRARY_PATH="." ./EoCApp
[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" (3053090816)
received signal 11

Call stack:

(0) /usr/lib/libpthread.so.0 : +0x10d60 [0x7f1fb1a53d60]
Ошибка сегментирования (core dumped)

Radeon HD 7950, ArchLinux 64, kernel 4.3.1, mesa|llvm from git.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff47fa563 in api::OpenGLRenderer::ChangeShader(ls::ObjectHandle, bool) () from ./libOGLBinding.so
#2  0x00007ffff44a01f5 in rf::Renderer::Apply(bool) () from ./libRenderFramework.so
#3  0x00007ffff47ec7bd in api::OpenGLRenderer::OpenGLRenderer(api::IAPI*, void*) () from ./libOGLBinding.so
#4  0x00007ffff47ebe19 in api::OpenGLAPI::CreateRenderer() () from ./libOGLBinding.so
#5  0x00007ffff47eba38 in api::OpenGLAPI::Init() () from ./libOGLBinding.so
#6  0x00007ffff45fa28a in BaseApp::InitAPI() () from ./libGameEngine.so
#7  0x00007ffff45f8e58 in BaseApp::Start(ls::InitStruct*) () from ./libGameEngine.so
#8  0x00000000006d4410 in main ()
Comment 1 Vladimir Usikov 2016-01-01 08:10:49 UTC
With llvm-pipe same crash

LIBGL_ALWAYS_SOFTWARE=1 LD_LIBRARY_PATH="." ./EoCApp    
[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" (2800719872)
received signal 11

Call stack:

(0) /usr/lib/libpthread.so.0 : +0x10d60 [0x7fd9a29a3d60]
Ошибка сегментирования (core dumped)

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff47fa563 in api::OpenGLRenderer::ChangeShader(ls::ObjectHandle, bool) () from ./libOGLBinding.so
#2  0x00007ffff44a01f5 in rf::Renderer::Apply(bool) () from ./libRenderFramework.so
#3  0x00007ffff47ec7bd in api::OpenGLRenderer::OpenGLRenderer(api::IAPI*, void*) () from ./libOGLBinding.so
#4  0x00007ffff47ebe19 in api::OpenGLAPI::CreateRenderer() () from ./libOGLBinding.so
#5  0x00007ffff47eba38 in api::OpenGLAPI::Init() () from ./libOGLBinding.so
#6  0x00007ffff45fa28a in BaseApp::InitAPI() () from ./libGameEngine.so
#7  0x00007ffff45f8e58 in BaseApp::Start(ls::InitStruct*) () from ./libGameEngine.so
#8  0x00000000006d4410 in main ()
Comment 2 Nicolai Hähnle 2016-01-04 15:28:01 UTC
Thanks for the report, but to be honest, the backtrace looks like this is a game bug. The last function on the stack belongs to the game, and then it jumps to 0. This is what you would see if a game doesn't properly check extension support, for example.
Comment 3 Vladimir Usikov 2016-01-09 22:01:16 UTC
I run with MESA_GL_VERSION_OVERRIDE=4.2  MESA_GLSL_VERSION_OVERRIDE=420 and receive call stack:
                  
(0) /usr/lib/libpthread.so.0 : +0x10d60 [0x7f360f099d60]
(1) ./libOGLBinding.so : api::OpenGLRenderer::ApplyConstants()+0x65 [0x7f360ffd57d5]
(2) ./libRenderFramework.so : rf::Renderer::Apply(bool)+0x57 [0x7f360fc74207]
(3) ./EoCApp : ig::IggyBinding::Swap(rf::Renderer*)+0xfc [0xebf16c]
(4) ./libGameEngine.so : BaseApp::EndDrawGUI(rf::Renderer*)+0x9b [0x7f360fdd288b]
(5) ./libGameEngine.so : BaseApp::MakeFrame()+0x3a4 [0x7f360fdd2db4]
(6) ./libGameEngine.so : BaseApp::OnIdle()+0xe0 [0x7f360fdd1590]
(7) ./EoCApp : main+0x170 [0x6d4430]
(8) /usr/lib/libc.so.6 : __libc_start_main+0xf0 [0x7f360ed01610]
(9) ./EoCApp : _start+0x29 [0x6d41a9]
Comment 4 Andrei Amuraritei 2016-01-17 22:28:15 UTC
(0) /lib64/libpthread.so.0 : +0x109f0 [0x7f7dde77b9f0]
(1) ./libOGLBinding.so : api::OpenGLRenderer::ApplyConstants()+0x65 [0x7f7ddf6bf7d5]
(2) ./libRenderFramework.so : rf::Renderer::Apply(bool)+0x57 [0x7f7ddf35e207]
(3) ./EoCApp : ig::IggyBinding::Swap(rf::Renderer*)+0xfc [0xebf16c]
(4) ./libGameEngine.so : BaseApp::EndDrawGUI(rf::Renderer*)+0x9b [0x7f7ddf4bc88b]
(5) ./libGameEngine.so : BaseApp::MakeFrame()+0x3a4 [0x7f7ddf4bcdb4]
(6) ./libGameEngine.so : BaseApp::OnIdle()+0xe0 [0x7f7ddf4bb590]
(7) ./EoCApp : main+0x170 [0x6d4430]
(8) /lib64/libc.so.6 : __libc_start_main+0xf0 [0x7f7dde3c3580]
(9) ./EoCApp : _start+0x29 [0x6d41a9]

I get the above in a window when trying to start the game with MESA_GL_VERSION_OVERRIDE=4.2  MESA_GLSL_VERSION_OVERRIDE=420, after clicking OK, I get a black screen with the mouse cursor from the game and a bit of sound, and the game exits.
Comment 5 Nicolai Hähnle 2016-01-18 21:20:37 UTC
Thanks for the backtrace, but again, without further evidence to the contrary I'd say that this is a game bug. The crash happens in pthread, which is called directly by the game. I suspect that the game isn't using the OpenGL API correctly.
Comment 6 smidjar2.reg 2016-03-31 13:11:53 UTC
I disassembled ApplyConstants() where the game crashes when using OpenGL override to 4.2. It is indeed a game bug, caused by possible NULL dereference. Crash occurs at line marked by =>

   0x00007ffff48467e0 <+0>:	push   r15
   0x00007ffff48467e2 <+2>:	push   r14
   0x00007ffff48467e4 <+4>:	push   r12
   0x00007ffff48467e6 <+6>:	push   rbx
   0x00007ffff48467e7 <+7>:	push   rax
   0x00007ffff48467e8 <+8>:	mov    r14,rdi
   0x00007ffff48467eb <+11>:	mov    eax,DWORD PTR [r14+0x6f8]
   0x00007ffff48467f2 <+18>:	mov    rcx,QWORD PTR [rip+0xd297]        # 0x7ffff4853a90
   0x00007ffff48467f9 <+25>:	cmp    eax,DWORD PTR [rcx]
   0x00007ffff48467fb <+27>:	je     0x7ffff4846959 <_ZN3api14OpenGLRenderer14ApplyConstantsEv+377>
   0x00007ffff4846801 <+33>:	xor    r15d,r15d
   0x00007ffff4846804 <+36>:	test   eax,0x3ff0000
   0x00007ffff4846809 <+41>:	je     0x7ffff4846845 <_ZN3api14OpenGLRenderer14ApplyConstantsEv+101>
   0x00007ffff484680b <+43>:	movzx  ecx,ax
   0x00007ffff484680e <+46>:	mov    edx,DWORD PTR [r14+0xc4]
   0x00007ffff4846815 <+53>:	xor    r15d,r15d
   0x00007ffff4846818 <+56>:	cmp    rcx,rdx
   0x00007ffff484681b <+59>:	jae    0x7ffff4846845 <_ZN3api14OpenGLRenderer14ApplyConstantsEv+101>
   0x00007ffff484681d <+61>:	shr    eax,0x10
   0x00007ffff4846820 <+64>:	mov    rdx,QWORD PTR [r14+0xe0]
   0x00007ffff4846827 <+71>:	xor    r15d,r15d
   0x00007ffff484682a <+74>:	movzx  edx,WORD PTR [rdx+rcx*2]
   0x00007ffff484682e <+78>:	and    eax,0x3ff
   0x00007ffff4846833 <+83>:	cmp    eax,edx
   0x00007ffff4846835 <+85>:	jne    0x7ffff4846845 <_ZN3api14OpenGLRenderer14ApplyConstantsEv+101>
   0x00007ffff4846837 <+87>:	imul   r15,rcx,0x110
   0x00007ffff484683e <+94>:	add    r15,QWORD PTR [r14+0xb8]
=> 0x00007ffff4846845 <+101>:	mov    rcx,QWORD PTR [r15+0x10]
   ......


//0x00007ffff48467eb:
  eax = this->variable_at_offset_0x6f8
//0x00007ffff48467f2:
  rcx = some_related_global_or_static_variable
//0x00007ffff48467fb:
  if (eax != rcx) {
    // 0x00007ffff4846801:
    r15 = NULL
    if ((eax & 0x3ff0000) != 0) {
       // ...
       // r15 is set in this block to valid value
       // ...
    }
    // 0x00007ffff4846845:
    rcx = r15->variable_at_offset_0x10 // crash here because r15 can be NULL
  }
// function end
Comment 8 Kamil Páral 2016-03-31 14:45:25 UTC
Would somebody care to contact the game developers and describe the issue in detail? And if you did, do you have a link (to a forum topic, public bug report, etc)? Thanks.
Comment 9 smidjar2.reg 2016-03-31 15:49:45 UTC
(In reply to Kamil Páral from comment #8)
> Would somebody care to contact the game developers and describe the issue in
> detail? And if you did, do you have a link (to a forum topic, public bug
> report, etc)? Thanks.

I posted it as a reply to nouveau issue topic in forum. Maybe someone will pick it up there.

http://larian.com/forums/ubbthreads.php?ubb=showflat&Number=580880&#Post580880
Comment 10 Jamey Sharp 2016-04-26 06:49:46 UTC
(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.
Comment 11 Ernst Sjöstrand 2016-04-30 12:13:51 UTC
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?
Comment 12 Jamey Sharp 2016-04-30 18:32:30 UTC
(In reply to Ernst Sjöstrand from comment #11)
> If I apply the "change shader" fix with RadeonSI I get a bunch of these
> glNamedStringARB errors when running the game with APITrace:

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.
Comment 13 Timothy Arceri 2016-05-01 09:05:03 UTC
Fixed by:

author  Jamey Sharp <jamey@minilop.net>
committer Timothy Arceri <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 <jamey@minilop.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Comment 14 Ernst Sjöstrand 2016-05-01 13:30:26 UTC
I still get the ApplyConstants() crash, both with and without your fix it seems like.
Is your fix for the ChangeShader() crash?
Comment 15 Jamey Sharp 2016-05-01 14:27:30 UTC
(In reply to Ernst Sjöstrand from comment #14)
> 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?
Comment 16 Ernst Sjöstrand 2016-05-01 15:09:56 UTC
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
Comment 17 Jamey Sharp 2016-05-02 05:59:35 UTC
(In reply to Ernst Sjöstrand from comment #16)
> 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:

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.
Comment 18 Ernst Sjöstrand 2016-05-02 07:16:00 UTC
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.
Comment 19 Vladimir Usikov 2016-05-03 12:59:34 UTC
mesa git 5541e11

[behem0th@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
Comment 20 kilobug 2016-05-05 07:15:35 UTC
I just tried with latest Mesash->CompileStatus = GL_FALSE;
Comment 21 kilobug 2016-05-05 07:17:36 UTC
(In reply to kilobug from comment #20)
> 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 :

(kilobug@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
Comment 22 Karol Herbst 2016-05-08 00:48:37 UTC
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
Comment 23 Karol Herbst 2016-05-08 01:01:09 UTC
(In reply to Jamey Sharp from comment #17)
> (In reply to Ernst Sjöstrand from comment #16)
> > 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:
> 
> 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
Comment 24 Jamey Sharp 2016-05-08 03:27:01 UTC
(In reply to Karol Herbst from comment #23)
> 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. :-(
Comment 25 kilobug 2016-05-08 07:41:18 UTC
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 :)
Comment 26 Karol Herbst 2016-05-09 12:36:48 UTC
(In reply to kilobug from comment #25)
> 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.
Comment 27 Karol Herbst 2016-05-22 13:59:11 UTC
as it turns out, divinity also needs allow_glsl_extension_directive_midshader
Comment 28 Vedran Miletić 2016-05-22 14:06:25 UTC
(In reply to Karol Herbst from comment #26)
> 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.
Comment 29 kilobug 2016-05-29 14:23:44 UTC
> With recent enough Mesa, forcing OpenGL 4.2 and GLSL 420 is not required.

Did you use llvm 3.8 or 3.9 ?
Comment 30 Vedran Miletić 2016-05-29 16:42:50 UTC
(In reply to kilobug from comment #29)
> > 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.
Comment 31 Kai 2016-05-31 18:33:10 UTC
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
Comment 32 Thomas J. Moore 2016-07-24 21:36:46 UTC
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.
Comment 33 Mikhail Korolev 2016-07-25 13:20:58 UTC
Created attachment 125311 [details] [review]
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.
Comment 34 Mikhail Korolev 2016-07-25 13:30:28 UTC
(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)
Comment 35 Thomas J. Moore 2016-07-25 16:07:45 UTC
(In reply to Mikhail Korolev from comment #33)
 > 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.

> 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)
> As for vendor check location:

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).
Comment 36 Mikhail Korolev 2016-07-25 17:06:42 UTC
(In reply to Thomas J. Moore from comment #35)
> (In reply to Mikhail Korolev from comment #33)
>  > 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.
Comment 37 kilobug 2016-07-30 09:13:56 UTC
(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 ?
Comment 38 Iaroslav Andrusyak 2016-07-30 09:30:18 UTC
> Did I miss something ?

allow_glsl_extension_directive_midshader=true ?
Comment 39 kilobug 2016-07-30 09:46:57 UTC
(In reply to Iaroslav Andrusyak from comment #38)
> > 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
Comment 40 Kai 2016-07-30 13:16:17 UTC
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 [details] in addition to allowing mid-shader extension directives let me launch and play the game.
Comment 41 kilobug 2016-07-30 13:55:55 UTC
(In reply to Kai from comment #40)
> 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.
Comment 42 Alex 2016-08-18 18:43:01 UTC
(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.
Comment 43 Aaron Watry 2016-08-24 14:30:39 UTC
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
Comment 44 Thomas J. Moore 2016-08-24 16:05:33 UTC
(In reply to Alex from comment #42)
> 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
Comment 45 Karol Herbst 2016-08-24 19:01:05 UTC
as far as I know there are no linux devs at larian anymore and the linux version won't be touched at all.


bug/show.html.tmpl processed on Feb 19, 2017 at 16:41:53.
(provided by the Example extension).