25 replies to this topic

[FeXoR]

myconid, on 15 August 2012 - 03:26 PM, said:

As long as materialmgr.quality is zero, GLSL shouldn't need tangents, but won't try to do anything fancy (I should have asked you to try that earlier). It's really strange that the supposedly "stable" ARB mode doesn't work for you, yet GLSL mode does.

For a stacktrace, pick the options that make the game crash and then run the game with gdb

gdb --args ./pyrogenesis -editor

Once it crashes, type in "bt" and copy the result.

Not sure if that worked. Atlas didn't open. Here's the console output:

fexor@gosarus:~/dat/projekte/0ad-linux/binaries/system$ gdb --args ./pyrogenesis -editor
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /media/dat/projekte/0ad-linux/binaries/system/pyrogenesis...done.
(gdb) bt
No stack.
(gdb) q
fexor@gosarus:~/dat/projekte/0ad-linux/binaries/system$

[myconid]

Oh sorry, you need to type "r" to run it.

[FeXoR]

myconid, on 15 August 2012 - 03:33 PM, said:

Oh sorry, you need to type "r" to run it.

I do:
Change local.cfg to:

gentangents = true
preferglsl = true
# novbo = true
# silhouettes = true
# smoothlos = false

- Bash console: Go to [SVN-Path]/binaries/system
- Bash console: gdb --args ./pyrogenesis -editor
- gdb console: r -> Atlas opens
- Generate NEW RMS Test -> Atlas gets stuck but stays open grayed off (not reacting)
- Take a sceen shot:

- gdb console: bt -> got some output
- gdb console: q -> Askes to kill Atlas
- I agree -> Atlas closes, back to bash console.
- Copy output:

Spoiler

fexor@gosarus:~/dat/projekte/0ad-linux/binaries/system$ gdb --args ./pyrogenesis -editor
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright © 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /media/dat/projekte/0ad-linux/binaries/system/pyrogenesis...done.
(gdb) r
Starting program: /media/dat/projekte/0ad-linux/binaries/system/pyrogenesis -editor
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
TIMER| LoadDLL: 1.37349 s
[New Thread 0xb4fe7b40 (LWP 8493)]
[New Thread 0xb44feb40 (LWP 8494)]
[New Thread 0xb3affb40 (LWP 8495)]
Cache: 200 (total: 2770) MiB
[New Thread 0xa61dfb40 (LWP 8496)]
TIMER| InitVfs: 10.207 ms
[New Thread 0xa59b5b40 (LWP 8497)]
[Thread 0xa59b5b40 (LWP 8497) exited]
[New Thread 0xa59b5b40 (LWP 8498)]
[New Thread 0xa11a3b40 (LWP 8499)]
TIMER| InitScripting: 4.89476 ms
TIMER| CONFIG_Init: 13.5491 ms
[New Thread 0xa03ffb40 (LWP 8500)]
[New Thread 0x9dd97b40 (LWP 8501)]
TIMER| RunHardwareDetection: 24.6825 ms
[New Thread 0x9d1ffb40 (LWP 8504)]
TIMER| InitRenderer: 12.7747 ms
TIMER| ps_console: 23.9604 ms
TIMER| ps_lang_hotkeys: 1.77956 ms
TIMER| common/emptyinit.xml: 11.1252 ms
GAME STARTED, ALL INIT COMPLETE
[New Thread 0x97affb40 (LWP 8505)]
[Thread 0x97affb40 (LWP 8505) exited]
TIMER| ParseTerrain: 5.53813 ms
TIMER| LoadDLL: 199.129 ms
TIMER| ParseEntities: 3.68389 s
GAME STARTED, ALL INIT COMPLETE

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4fe7b40 (LWP 8493)]
0x9f8bb47a in ?? () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
(gdb) bt
#0 0x9f8bb47a in ?? () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#1 0x9f8b85c4 in ?? () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#2 0x9f8ba36d in draw_pipeline_run () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#3 0x9f944897 in ?? () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#4 0x9f944930 in ?? () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#5 0x9f8c5b64 in ?? () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#6 0x9f8bf3fb in ?? () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#7 0x9f8bf72d in draw_vbo () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#8 0x9f8892d0 in ?? () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#9 0x9f88b3fd in ?? () from /usr/lib/i386-linux-gnu/dri/r300_dri.so
#10 0x9f2181da in st_draw_vbo () from /usr/lib/i386-linux-gnu/dri/libgallium.so
#11 0x9f6dcf5d in ?? () from /usr/lib/i386-linux-gnu/dri/libdricore.so
#12 0x9f6dd098 in ?? () from /usr/lib/i386-linux-gnu/dri/libdricore.so
#13 0x9f6dd1cf in ?? () from /usr/lib/i386-linux-gnu/dri/libdricore.so
#14 0x082fd0c1 in InstancingModelRenderer::RenderModel (this=0x99f497b8, shader=..., model=0x94773848)
at ../../../source/renderer/InstancingModelRenderer.cpp:357
#15 0x082add1f in ShaderModelRenderer::Render (this=0x9af348b8, modifier=..., context=..., flags=8) at ../../../source/renderer/ModelRenderer.cpp:715
#16 0x082b869e in CallModelRenderers (flags=8, context=..., this=0xb46c8e50) at ../../../source/renderer/Renderer.cpp:360
#17 CRenderer::RenderSilhouettes (this=0xb4659e08, context=...) at ../../../source/renderer/Renderer.cpp:1265
#18 0x082b99a5 in CRenderer::RenderSubmissions (this=0xb4659e08) at ../../../source/renderer/Renderer.cpp:1483
#19 0x082ba0c6 in CRenderer::RenderScene (this=0xb4659e08, scene=...) at ../../../source/renderer/Renderer.cpp:1675
#20 0x0823768a in CGameView::Render (this=0x9c3ae780) at ../../../source/graphics/GameView.cpp:494
#21 0x081cd40b in Render () at ../../../source/ps/GameSetup/GameSetup.cpp:217
#22 0x08330f45 in AtlasViewGame::Render (this=0x99ba3128) at ../../../source/tools/atlas/GameInterface/View.cpp:262
#23 0x08326bd9 in RunEngine (data=0xbffff0c8) at ../../../source/tools/atlas/GameInterface/GameLoop.cpp:227
#24 0xb7652d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#25 0xb7590ace in clone () from /lib/i386-linux-gnu/libc.so.6
(gdb) q
A debugging session is active.

Inferior 1 [process 8490] will be killed.

Quit anyway? (y or n) y
fexor@gosarus:~/dat/projekte/0ad-linux/binaries/system$

Edited by FeXoR, 15 August 2012 - 03:46 PM.

[myconid]

Ok, so now we know it's definitely a driver issue. Also, the "draw_vbo" function call means this is VBO-related as I suspected.

You might want to try testing the configuration that works for you with "novbo = true", just to see what happens. And try this on Windows with a different driver when you get the chance, just to make sure this is indeed the driver's fault.

Not much else we can do right now, I'm afraid. I'll check the memory alignment in the renderers over the weekend and push any changes to git, as that could help a bit (doubt it).

Thanks for your patience, FeXoR.

[FeXoR]

myconid, on 15 August 2012 - 04:13 PM, said:

Ok, so now we know it's definitely a driver issue. Also, the "draw_vbo" function call means this is VBO-related as I suspected.

You might want to try testing the configuration that works for you with "novbo = true", just to see what happens.

With preferglsl and novbo = true I still got the same 3 "minor" issues:
- Distant ground textures look strange,
- Sometimes black polygones on the ground.
- Sometimes building parts are seen-through.

myconid, on 15 August 2012 - 04:13 PM, said:

And try this on Windows with a different driver when you get the chance, just to make sure this is indeed the driver's fault.

I'm pretty sure it will work all right with the official drivers. Will let you know...

myconid, on 15 August 2012 - 04:13 PM, said:

Not much else we can do right now, I'm afraid. I'll check the memory alignment in the renderers over the weekend and push any changes to git, as that could help a bit (doubt it).

Thanks for your patience, FeXoR.

You'r welcome, Thanks for yours.

[myconid]

Apologies for the delay. I've checked the memory alignment in the renderers and found nothing out of the ordinary (that I can see, anyway).

I suppose that's a good thing, but we still have no solution for your problem nor any workaround that might improve it. Let's hope the driver developers will have a fix for it, eventually.