roluncher Segmentation fault.

[Adrian]

Originally Posted by Elanor

First of all thanks a lot for the quick replies. I got the file from Enio's post but rolancher was still failling, this time with the error:

Can you post the logs? (error_log.txt and log.txt)

There can be a shader failing or something similar.

[Elanor]

Originally Posted by Adrian

Can you post the logs? (error_log.txt and log.txt)

There can be a shader failing or something similar.

https://goo.gl/ShwQGd --> log.txt
https://goo.gl/zQvE3N --> error_log.txt

Someone mentioned GTK requisites. is there a list of pre requisites somewhere?
OFFTOPIC: the limits to attach files to this forum are ridiculous.

[_Enio_]

Originally Posted by Adrian

64-bit one?

Yeah, seems like.

[enio@thinkpad test]$ cat log.txt | grep build
[11/08/2016 16:10:31] [ClientBase][client_base.cpp(343)] Client build: 39669
[enio@thinkpad test]$ file game
game: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.26, BuildID[sha1]=90e30231e6ef31ede2d52c9e4055cfbe471cf0a2, stripped
[enio@thinkpad test]$ objdump -d game | grep sahf
 119671a:    9e                       sahf

Could it come from a statically linked library?

Because it is odd, there is exactly one occurrence of this SAHF instruction, which gcc uses to optimize fmod from glibc (https://code.woboq.org/userspace/gli...hinline.h.html seach for fmod) while theres multiple occurrences of a seemingly unoptimized fmod.

Short excursion in the dirty deeps of assembly, (skip -> go to next bold text):
Its only occurrence:

 1196711: dd 42 08              fldl   0x8(%rdx)
 1196714: dd 02                 fldl   (%rdx)  
 1196716: d9 f8                 fprem
 1196718: df e0                 fnstsw %ax
 119671a: 9e                    sahf
 119671b: 7a f9                 jp     1196716 <luaopen_table@@Base+0x2956>

This loads 2 floats (from adress %rdx and %rdx+8) into the FPU registers, calculates the remainder (kinda modulo) with fprem instruction, result status is now in the FPU flags, these get stored in the CPU ax register (with fnstsw %ax).

Now optimized and normal code changes.

The optimized version pushes the result status into the CPU flags with sahf. The unoptimized does the same with a test 0x4, %ah. Basically checking if the 3rd bit is one, test stores the result of the test in CPU flags.
Next follows a jp (some jump), which jumps somewhere, depending on the status in the CPU flags.
Optimization here is, that sahf seems to be much faster than test.
For the record, the unoptimized remainder calculation (Occurrs 70 times):

  807950: dd 44 24 10           fldl   0x10(%rsp)
  807954: dd 44 24 08           fldl   0x8(%rsp)
  807958: d9 f8                 fprem
  80795a: df e0                 fnstsw %ax
  80795c: f6 c4 04              test   $0x4,%ah
  80795f: 75 f7                 jne    807958 <_ZN6Effect11CMeshEffect15update_internalEf@@Base+0x298>

End excursion.


Since the optimization occurs only once compared to numerous unoptimized remainder calculations, i assume that theres a small part that did not get that "-mno-sahf" - either through some error in the makefiles, or by some statically linked-in code.

[Adrian]

Originally Posted by _Enio_

Yeah, seems like.

[enio@thinkpad test]$ cat log.txt | grep build
[11/08/2016 16:10:31] [ClientBase][client_base.cpp(343)] Client build: 39669
[enio@thinkpad test]$ file game
game: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.26, BuildID[sha1]=90e30231e6ef31ede2d52c9e4055cfbe471cf0a2, stripped
[enio@thinkpad test]$ objdump -d game | grep sahf
 119671a:    9e                       sahf

Could it come from a statically linked library?

Because it is odd, there is exactly one occurrence of this SAHF instruction, which gcc uses to optimize fmod from glibc (https://code.woboq.org/userspace/gli...hinline.h.html seach for fmod) while theres multiple occurrences of a seemingly unoptimized fmod.

Short excursion in the dirty deeps of assembly, (skip -> go to next bold text):
Its only occurrence:

 1196711: dd 42 08              fldl   0x8(%rdx)
 1196714: dd 02                 fldl   (%rdx)  
 1196716: d9 f8                 fprem
 1196718: df e0                 fnstsw %ax
 119671a: 9e                    sahf
 119671b: 7a f9                 jp     1196716 <luaopen_table@@Base+0x2956>

This loads 2 floats (from adress %rdx and %rdx+8) into the FPU registers, calculates the remainder (kinda modulo) with fprem instruction, result status is now in the FPU flags, these get stored in the CPU ax register (with fnstsw %ax).

Now optimized and normal code changes.

The optimized version pushes the result status into the CPU flags with sahf. The unoptimized does the same with a test 0x4, %ah. Basically checking if the 3rd bit is one, test stores the result of the test in CPU flags.
Next follows a jp (some jump), which jumps somewhere, depending on the status in the CPU flags.
Optimization here is, that sahf seems to be much faster than test.
For the record, the unoptimized remainder calculation (Occurrs 70 times):

  807950: dd 44 24 10           fldl   0x10(%rsp)
  807954: dd 44 24 08           fldl   0x8(%rsp)
  807958: d9 f8                 fprem
  80795a: df e0                 fnstsw %ax
  80795c: f6 c4 04              test   $0x4,%ah
  80795f: 75 f7                 jne    807958 <_ZN6Effect11CMeshEffect15update_internalEf@@Base+0x298>

End excursion.


Since the optimization occurs only once compared to numerous unoptimized remainder calculations, i assume that theres a small part that did not get that "-mno-sahf" - either through some error in the makefiles, or by some statically linked-in code.

Check the other thread. I replied there!

[Adrian]

Originally Posted by Elanor

https://goo.gl/ShwQGd --> log.txt
https://goo.gl/zQvE3N --> error_log.txt

Someone mentioned GTK requisites. is there a list of pre requisites somewhere?
OFFTOPIC: the limits to attach files to this forum are ridiculous.

Could you, somehow, check the driver you were using back then with Ubuntu 16 and compare if you're using the same one?

[_Enio_]

Originally Posted by Elanor

https://goo.gl/ShwQGd --> log.txt
https://goo.gl/zQvE3N --> error_log.txt

Seems having issues with your GPU type. I'm using the same versions as you do for

[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl_x11.cpp(224)] X Server vendor: The X.Org Foundation
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl_x11.cpp(228)] X Server release: 1.18.4
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl.cpp(363)] XVidMode Extension version 2.2
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl.cpp(373)] Xinerama Extension version 1.1
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl.cpp(535)] OpenGL version: 3.0 Mesa 12.0.1
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl_extensions_loader.cpp(312)] OpenGL Shading Language version: 1.30
[11/08/2016 16:10:31] [RenderizerGL][renderizer_gl_extensions_loader.cpp(318)] Shader model 2 capable card detected

except its Fedora vendor, does that one differ from the normal one? Dont think so.

I think this needs to be fixed on NGDs end.

[Elanor]

Enio & Adrian
I'm trying to get a vm running 16.04 to compare it with what i have on my bare metal fedora 24.
In the meantime here are some specifics from my laptop:

[siggy@alnair regnum]$ uname -a
Linux alnair 4.6.4-301.fc24.x86_64 #1 SMP Tue Jul 12 11:50:00 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[siggy@alnair regnum]$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 12.0.1
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 12.0.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 12.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

[siggy@alnair regnum]$ lspci -vk 
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device 3977
	Flags: bus master, fast devsel, latency 0, IRQ 26
	Memory at e0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 3000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915
	Kernel modules: i915

[Elanor]

I also see this in the logs (that i just started fresh):
error_log.txt

[siggy@alnair live]$ cat error_log.txt | grep Error | wc -l
961
[11/08/2016 15:56:13] [Texture Manager][texture_manager.cpp(212)] Error uploading texture, resource ID: 72524

log.txt

[siggy@alnair live]$ cat log.txt | grep error
0:33(42): preprocessor error: extra tokens at end of directive
error: linking with uncompiled shader

[_Enio_]

Do you have any options you can set in rolauncher options (just after login, top right) regarding render quality or anything?

Can you post the part after "OpenGL extensions:" in glxinfo? Maybe a diff to mine gives hints what your GPU doesnt like about the regnum textures.

[Elanor]

Originally Posted by _Enio_

Do you have any options you can set in rolauncher options (just after login, top right) regarding render quality or anything?

Can you post the part after "OpenGL extensions:" in glxinfo? Maybe a diff to mine gives hints what your GPU doesnt like about the regnum textures.

This is the complete output of glxinfo

https://goo.gl/1BRNB8

I don't think OpenGL or the Intel driver have nothing to do with this, though. I think is either something pointing to a wrong location for the textures within the binary (ius there a reason why you guys don't provide sourceces?) or missing libraries of some sort.