Bug 105218 - Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8
Summary: Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium blocker
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-22 23:40 UTC by Matias N. Goldberg
Modified: 2018-04-01 19:42 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matias N. Goldberg 2018-02-22 23:40:47 UTC
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.

Cheers
Comment 1 Timothy Arceri 2018-03-30 12:08:04 UTC
To complete the bug report can you report which LLVM are you testing with?

You can find it easily with:

glxinfo | grep OpenGL
Comment 2 Timothy Arceri 2018-03-30 12:44:09 UTC
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.
Comment 3 Matias N. Goldberg 2018-03-30 16:36:24 UTC
Hi!

Thanks for starting to look into this!

First:
 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 extensions:
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.
Comment 4 Matias N. Goldberg 2018-03-30 16:40:42 UTC
This is an example of how JSON settings look in my CMake setup:

https://i.imgur.com/mj77iEz.png
Comment 5 Timothy Arceri 2018-03-30 23:51:32 UTC
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.
Comment 6 Timothy Arceri 2018-03-31 00:39:35 UTC
(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.
Comment 7 Matias N. Goldberg 2018-04-01 19:41:38 UTC
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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.