Can't Run 1.8.0.1 on Nexus 7 Device Without Crashing

Hi @REDACTEDUSER

Thank you for your interest in Lumberyard on Android. May I ask which version of the Nexus 7 are you using?

The version released in 2012, which uses the Tegra 3 chipset, does not meet the min hardware specs of OpenGL ES 3.0. The 2013 version, however, does but unfortunately there is currently a bug in the ES 3.0 support we are working on and planning on releasing in the near future.

In the meantime, an ES 3.1 or newer device is required to run Lumberyard on Android. Apologies for any inconveniences this may cause.

Thanks for the hardware spec - that looks like it should run Lumberyard. You will want to check the system_android_es3.cfg to make sure that it has r_ShaderCompilerServer set to the IP address of the PC where you are running the remote shader compiler.

Also you will want to create a file called config.ini in the same directory where the remote shader compiler executable is located and in that file add the line: whitelist=[Android IP Address]

Replacing [Android IP Addess] with the actual IP address of your android device. An example would be: whitelist=192.168.0.1

In the window where the remote shader compiler is running you should see it print out lines that it is processing the shader requests from the device.

Also you will want to run the following command from the command line: adb logcat -s "LMBR"

That will dump to the command line output from the engine as it starts up. Attaching this output to a question will help us better answer your questions/help figure out what is going wrong with your setup.

As for not needing the remote shader compiler it is difficult at the moment because we generate shader permutations at runtime. Since the permutations are run-time dependent we don't know what shaders to generate/compile for you at compile time. This is why in the docs it talks about flying around your level. Once you have done that you can package up the shaders and pack them into your APK. You will need to do this to release your game on Android.

So... once you have the UI showing up on your Android device you could technically run the process to generate that shader pak file and then you would not need the remote shader compiler. The problem will come if you add a new UI component that triggers the creation of a new shader permutation that you don't have already. In that case the game may hang (depends on what values you have in the system_android_es3.cfg file). :)

Thanks, Chris

Are there any plans in the future to remove the need for a shader compiler entirely? For example, if I opt to use only a few, pre-built shaders in my app for everything; then I wouldn't need to use a running shader compiler? I'd also like to know, when running live, in production, would all of my apps require our backend to have a shader compiler running and accessible to all users globally?

Thanks.

-Kevin

I think the point is to generate these paks - apps get submitted with the paks built, right? Sorry, I asked a kind of dumb question because I have never worked with a shader compiler before and have no reference for why one would be needed... I've even written my own, simple shaders in used in Unity; but even the largest game I've ever worked on only had a couple hundred shaders.

Yeah, we are not big fans of the remote shader compiler either but I cannot state what are plans are for it at this time.

As for when you release your game you won't need to have your customers connect to the shader compiler. The remote shader compiler is only for development and when you release your game you will put the compiled shaders into the APK. Here is the documentation that describes that process (look for the section labeled: Generate and Retrieving Shaders and read from there on): http://docs.aws.amazon.com/lumberyard/latest/userguide/android-shaders-building.htm

You can use that same process now in your development process to pack up the shaders and not connect to the remote shader compiler every time.

No dumb questions here - the remote shader compiler is not a traditional way of handling shaders and so if you are confused by it, welcome to the club. :)

As for why we use it - mainly a legacy pipeline we inherited from CryEngine. What it helps in is converting the HLSL shaders into GLSL/Metal. Unity does a similar thing, though it is better hidden/handled than the remote shader compiler solution. This makes it easier to maintain shaders as we don't have to write the same shader three or more times for each shader language. We write it once then use the remote shader compiler to convert it to the native shader language for the device that is requesting it.

I could not get it running on the device above. Attached is a log file of it running. Also, when running on the N7, it doesn't even try to compile shaders (no Shader Compiler activity).

Somewhat of a success though - I was able to get the SamplesProject running on the device below.

When running on that device, I get hundreds of this log messages a second:

04-26 11:26:48.404 4766 4787 I LMBR : $4[Error] OpenGLError: Source: Other Type: Performance Id: 2147483647 Severity: High Message: Namespace collision detected, using slow path<a href="/forums/storage/attachments/4426-nexus7log.txt">nexus7log.txt</a>

Looking through the log and I see this line which explains why it is not running on the Nexus 7:

04-26 11:12:03.222 11420 11457 I LMBR : The available graphic adapters don't meet the minimum requirements for running the game. Device Qualcomm Adreno (TM) 320 doesn't support the minimum version needed of OpenGL (ES). Required 310, found 300.

We are currently improving our OpenGL ES 3.0 support and this should be resolved in a future release. For now you will have to work on the Snapdragon device for Android development. That or update the Nexus 7 to a newer version of Android that has OpenGL ES 3.1 support.

As for the OpenGL errors we have been trying to track those down and obviously have not had much luck in doing so. We are still digging into them and will hopefully figure out what the driver is telling us and get things running on the non-slow path.