[Schtruck]

i'm the developper of FPse for android (PS1 emu for android) and recently i ported an OpenGL plugin (made in 1.1) to OpenGL-ES 1.1.

Unfortunally Mali400 have serious problem, 99% of games crash, only Tekken3 is able to run at 100% and once started let other games running perfectly. really strange. this game seems to run a scenarii that unlock something on Shader engine.

So on Mali400 the crash happen quickly on gldrawarrays call with texture set. (except with Tekken3 ....).

all my attempt to trace and compare has failed, so you are my last chance to understand the problem. as driver is not open source.

Hopefully using my Galaxy Note and my Galaxy SII running on android 4.0.3 i'm able to have somes details of the problem, here is the log:


********** Crash dump: **********
Build fingerprint: 'samsung/GT-I9100/GT-I9100:4.0.3/IML74K/XXLPQ:user/release-keys'
pid: 12537, tid: 18785 >>> com.emulator.fpse <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000004d
Stack frame #00 pc 00076194 /system/lib/libMali.so (_essl_mali200_write_instructions): Routine _essl_mali200_write_instructions in hardware/arm/mali-samsung-dev/driver/./src/shared/essl_compiler/src/mali200/mali200_instruction.c:765
Stack frame #01 pc 0009524c /system/lib/libMali.so (schedule): Routine schedule in mali200/mali200_scheduler.rw:154
Stack frame #02 pc 000981d4 /system/lib/libMali.so (_essl_mali200_schedule_single_operation): Routine _essl_mali200_schedule_single_operation in mali200/mali200_scheduler.rw:925
Stack frame #03 pc 0009939c /system/lib/libMali.so (_essl_mali200_schedule_function): Routine _essl_mali200_schedule_function in mali200/mali200_scheduler.rw:1991
Stack frame #04 pc 0008e98c /system/lib/libMali.so (_essl_shadergen_mali200_driver): Routine _essl_shadergen_mali200_driver in hardware/arm/mali-samsung-dev/driver/./src/shared/essl_compiler/src/shadergen_mali200/shadergen_mali200_driver.c:121
Stack frame #05 pc 0008e4ec /system/lib/libMali.so (generate_shader): Routine generate_shader in hardware/arm/mali-samsung-dev/driver/./src/shared/essl_compiler/src/shadergen_mali200/shadergen_mali200.c:1686
Stack frame #06 pc 0008e8a4 /system/lib/libMali.so (_fragment_shadergen_generate_shader): Routine _fragment_shadergen_generate_shader in hardware/arm/mali-samsung-dev/driver/./src/shared/essl_compiler/src/shadergen_mali200/shadergen_mali200.c:1726
Stack frame #07 pc 000350dc /system/lib/egl/libGLESv1_CM_mali.so (_gles_sg_init_draw_call)
Stack frame #08 pc 0002877c /system/lib/egl/libGLESv1_CM_mali.so (_gles1_init_draw)
Stack frame #09 pc 00028a8c /system/lib/egl/libGLESv1_CM_mali.so (_gles1_draw_arrays)
Stack frame #10 pc 0000d054 /system/lib/egl/libGLESv1_CM_mali.so (glDrawArrays)

This post has been edited by Schtruck: 24 March 2012 - 04:29 PM

[KarthikH]

Hi Schtruck,

Sorry to hear that you are having problems on the Samsung devices. Could you let me know the answers to the following questions so that we can try figuring out the problem.

1. Have you tried on an earlier version of Android with the Mali GPU (Gingerbread instead of Icecream Sandwich)?

2. What would be the best way for us to reproduce this issue? Could you give us a trace of the GL Calls that are made when you run Tekken3? Alternatively, a simple test scenario would also help.

3. Does the emulator (FPse) follow a different code path when using Tekken3? Unfortunately, even after installing the emulator, we would not be able to test it using a PS1 game file(due to legal reasons). So you might have to help us isolate the problem.

4. Does the following work? Play game A, play Tekken3, play game A.

regards
Karthik

[Schtruck]

OK here are my answers,

1. Have you tried on an earlier version of Android with the Mali GPU (Gingerbread instead of Icecream Sandwich)?
Yes tried 2.2 (on Chinese device with MALI400 gpu) , 2.3.6 (Galaxy Note) and 4.0.3 (Galaxy SII), same results

2. What would be the best way for us to reproduce this issue? Could you give us a trace of the GL Calls that are made when you run Tekken3? Alternatively, a simple test scenario would also help.
The source code of the plugin is available here: SOURCE , and if you can test on android device too, then the best is to give you the APK of FPse. But i can give you all the GL calls before crash, what i did but found not much differences. For example the Scenerii is Different with Tekken3 with BIOS set and without Bios set. With Bios Set, Tekken3 crash after about 30 GL calls, this is perhaps a good start to understand.
I can tell you that it's related to Textures, because if i comment glEnable(GL_TEXTURE2D) , there is no more crash, but flat polygon... (to be sure i tested on all others 3D GPU chipset available on other ARM CPU and everything works everytime)


3. Does the emulator (FPse) follow a different code path when using Tekken3? Unfortunately, even after installing the emulator, we would not be able to test it using a PS1 game file(due to legal reasons). So you might have to help us isolate the problem.
Yes, as FPse is an Emulator, the code path is different with games, and as it's one of the last games released on PS1, he used different modeling software and Polygons were better modeled than any other previous 3D games. About Using Tekken3 or any other Game, it's legal if you own the Original Game.
I will post the List of GL call before the crash, and the List with the same game when crash doesn't happen.

4. Does the following work? Play game A, play Tekken3, play game A.
No Tekken3 without Bios set is the game that start normaly without crash.

This post has been edited by Schtruck: 27 March 2012 - 06:43 AM

[Stephen Barton]

Hi Schtruck,

Just letting you know that your request is still going through our legal department. I will be in touch with you shortly hopefully being able to help you.

Kind regards,
Stephen

[Schtruck]

have you got any news for this problem?

can you just take a look at the code which is at this place:

file: mali200_instruction.c line: 765

this is on my galaxy note on android 2.3.4

this file is one used by samsung to compile the library libMali.so

that will be very helpfull for sure as it s the driver which crash, not my program...

thanks

schtruck

[PitchLabApp]

Similar problems here: GT-I9100, OpenGL 1.1, app crashing with full system power-down and reboot required.

I've never been able to get my hands on a device to get a stacktrace but here is the device info from a user that I'm currently working with in an attempt to resolve the issue:

Samsung Galaxy S2 (GT-9100)
Android: 4.0.4
Baseband: I9100XXLQ6
Kernel: 3.0.15-1056084 dpi@DELL168 #3 SMP PREEMPT Wed Aug 22 22:55:24 KST 2012
Build number: IMM76D.XWLPW

The user reports that the app crashes after 1...5 minutes of operation with the only recovery options being to hold the power button until the device shuts down and then reboot from scratch.

My app is small, completely free and available for download here (no network permission required):

https://play.google....mbolic.pitchlab

I've had a lot of reports of instant lock-up when running the app on Samsung Infuse 4G (SGH-I997). So many that I had to exclude it from the list of compatible devices so you might find it even easier to reproduce the issue on an Infuse 4G.

I've also used the Google Play developer console statistics to do an analysis of the ratio of total downloads vs. active downloads for each device and, using a beta distribution to model the probability of users with a given device installing and then uninstalling my app, I find the following devices to have the highest rejection probability (which, in the absence of detailed user feedback, might be a useful proxy for the app not working):

Samsung Galaxy S (GT-I9000B)
Samsung Galaxy S (SHW-M190S)
Samsung Galaxy Neo (SHW-M220L)
Samsung Sidekick 4G (SGH-T839)
Samsung Galaxy S (SCH-R910)

[isogen74]

> I've had a lot of reports of instant lock-up when running the app on Samsung Infuse 4G


I suspect that's a different problem. I believe the Infuse uses the Samsung Hummingbird processor, which uses an Imagination GPU.

[PitchLabApp]

Re: GT-I9100 crash.

With the help of a very patient user who was prepared to manually install debug versions and report the results, I eventually managed to come up work a workaround that seems to have cured this driver issue, at least for my app.

When calling glDrawArrays, I now limit the calls to processing at most 256 triangles in one go. If the vertex buffer contains more than 256 triangles, I split it up into separate calls to glDrawArrays with 256 triangles and then handle the remainder at the end.

All the best.