Our Terrain sample from Ogre 2.1 uses a compute shader to generate the shadows of the terrain, and later uses a special vs & ps to render the terrain.
What's special about that sample over the rest (that run fine) are:
1. The compute shader that generates the shadows (https://bitbucket.org/sinbad/ogre/src/09181053ca69f4760b655c2eed5b5ca7d62fd7bc/Samples/Media/2.0/scripts/materials/Tutorial_Terrain/GLSL/TerraShadowGenerator.glsl?at=v2-1&fileviewer=file-view-default). The heigthmap is in format R16_UNORM, the generated shadows texture is in RGB10A2
2. A PS that generates the normals (https://bitbucket.org/sinbad/ogre/src/09181053ca69f4760b655c2eed5b5ca7d62fd7bc/Samples/Media/2.0/scripts/materials/Tutorial_Terrain/GLSL/GpuNormalMapper_ps.glsl?at=v2-1&fileviewer=file-view-default). The normals' texture are in RGB10A2
3. The VS has no vertex buffer bound, but rather relies on gl_VertexID and integer ops (https://bitbucket.org/sinbad/ogre/src/09181053ca69f4760b655c2eed5b5ca7d62fd7bc/Samples/Media/Hlms/Terra/GLSL/VertexShader_vs.glsl?at=v2-1&fileviewer=file-view-default#VertexShader_vs.glsl-66) and reads the heightmap.
After commit 847d0a393d7f0f967f39302900d5330f32b804c8 and at least until latest from today, running this sample causes an entire system freeze: Mouse cursor is the only thing that responds. Keyboard does not respond, hard resetting is the only way and tends to corrupt files in the drive (This was painful to bisect).
Before this commit the sample behaves as expected.
My GPU is a Radeon RX 560 2GB
I can provide a binary with the failing sample, or instructions on how to build from source (https://ogrecave.github.io/ogre/api/2.1/SettingUpOgreLinux.html). Whatever you need.
I'm flagging this as blocker because of the security implications of freezing the entire system with ease.
To complete the bug report can you report which LLVM are you testing with?
You can find it easily with:
glxinfo | grep OpenGL
I built from source and for me the Terrain sample crashes with:
An exception has occured: OGRE EXCEPTION(5:ItemIdentityException): Compute Job with name Terra/ShadowGenerator not found in HlmsCompute::findComputeJob at /home/tarceri/merc/Ogre/OgreMain/src/OgreHlmsCompute.cpp (line 570)
Tested with Mesa/LLVM master.
Thanks for starting to look into this!
glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon RX 560 Series (POLARIS11 / DRM 3.19.0 / 4.14.11, LLVM 6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel (git-b3a1d9588e)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 18.1.0-devel (git-b3a1d9588e)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel (git-b3a1d9588e)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
To be more specific, my LLVM is from SVN revision 321389
As for the Terra crash: It seems the build didn't pick rapidjson, so there's no JSON material support.
Place rapidjson into <OgreRepo>/Dependencies/include/rapidjson folder (create it if it doesn't exist) so that the header lies at <OgreRepo>/Dependencies/include/rapidjson/rapidjson.h
To avoid any potential problem just grab rapidjson files from here: https://bitbucket.org/cabalistic/ogredeps/src/d0f0609a769a5a4a5824256280e07b3a72637a63/src/rapidjson/include/?at=default
Then run CMake again on Ogre so that it picks up rapidjson and build again.
This is an example of how JSON settings look in my CMake setup:
Ok built it correctly this time.
No crash with Mesa git and LLVM 7 the sample runs fine on my RX580. Possible there is a bug in LLVM 6.
(In reply to Timothy Arceri from comment #5)
> Ok built it correctly this time.
> No crash with Mesa git and LLVM 7 the sample runs fine on my RX580. Possible
> there is a bug in LLVM 6.
Ok I tested the LLVM 6.0.0 release with git master and that worked fine for me too.
I just tested with Mesa latest from git (2f175bfe5d8ca59a8a68b6d6d072cd7bf2f8baa9) and LLVM 7.0 revision 328838 (anything newer and Mesa won't compile due to a known issue) and the problem is gone.
Either a later Mesa commit already fixed it, or my LLVM version was too old.
This ticket can be closed as the problem can no longer be reproduced.
Thanks and Cheers