Hello. I've got a Samsung Galaxy at the workplace (among other Android devices like G1, Magic, Hero) and i tested an Opengl ES application on it. I've got 5 fps, which is terrible. The same build gets 25 fps+ on G1, Magic, Hero. Weird...

Another problem is that the app crashes if i use VBO extension, just like in the emulator, and that is strange. My conclusion is that HW acceleration for OpenGL is OFF in Galaxy (although the processor -which handles the GL as well- is the same as in Magic).

I saw a video on youtube that shows Galaxy vs Magic in Neocore benchmark (3d heavy) and the two phones got the same score, so the acceleration is somehow available.. Then i searched a little on the web and i found that Neocore benchmark was written in native code so they did not use Java.. The obvious conclusion is that the Galaxy has opengl HW acceleration disabled, but only in java.

The final test was to get from Market a 3d app that was made in java. I found one, a spaceship racer (just like the old PC Star Wars Racing game), and i downloaded it on Galaxy and on G1. The Galaxy was slugging at 3-5 fps meanwhile G1 was rocking smoothly (20 fps+ for sure). I rest my case..

My question are:
Has somebody else written a opengles game and tested it on galaxy?
What is the solution for a 3d Game on Samsung Galaxy (in java, not native code)?
And for what reason Samsung decided to disable HW acceleration, when the Magic has the same processor and it works perfectly?

Wow, I've the same problem here. Only that I don't have the phone itself, so my reports come from users.
Have you managed to get decent acceleration?
If not, can you please try this hack: http://groups.google.com/group/android- ... c6ddeae58b (I've attached the archive to this message.) You will need to run it twice, first with StandardRenderer (all rendering done in Java) and then with NativeRenderer (same rendering sequence, but done entirely in native code). Renderer created in MainActivity::onCreate.
This project was done in NDK 1.5, where native OpenGL was not available, so I created this 'hack'. However this hack does pretty much the same as official OpenGL support in NDK 1.6.

So, if native renderer will show (much) better framerates we will look closely to JNI layer (and maybe will write our own).

Hello and thanks for the reply.

I still not figured out the way to handle the hardware acceleration on the Galaxy. I tried your apk on the phone itself, with both java and native renderer. Unfortunately, they behaved exactly the same: one application frame was rendered in 70-90 ms on both configurations. So i guess that in native mode, the rendering path defaults to software emulation too. It's very odd because the Neocore demo (also written in native code from what i heard) runs in hardware mode, at least that is what i saw in a youtube video (i didn't find the demo on the market anymore to try it on my phone).

I will investigate the matter further, it has to be a way to use the hardware acceleration..

EDIT
I found the Neocore demo on a server and i installed it on my phone. I've got 25.9 FPS, very smoothly... so the solution is out there..

zorro wrote:Hello and thanks for the reply.

EDIT
I found the Neocore demo on a server and i installed it on my phone. I've got 25.9 FPS, very smoothly... so the solution is out there..

Can you post it here? I want to look into it using surgeon tools

UPD: Nevermind, I found it. Ok, after short meditation I can say two things: (1) It uses Qualcomm engine and (2) It doesn't use gl functions with float arguments. I didn't check yet, but I'm sure it accesses GL differently than we do, i.e. it doesn't use NDK's GL library. I've seen this type of access in Armadillo Roll game (which was written by Qualcomm itself), and I didn't understand how exactly they access OpenGL library.
I think we can start by trying to avoid float arguments - there is a #define for that in native code. You will need to recompile library, of course.

UPD2: #define won't help, we need to completely eliminate floating point operations...
UPD3: You can also try 'san-angeles' demo in NDK 1.6 Although it uses floating point for calculations, all rendering seems to be done in fixed point.

So you're thinking that if the program uses float data type in OpenGL, the rendering is done in software mode.

Unfortunately i cannot try 'san-angeles' on the Galaxy because the phone has Android 1.5 only and it has the latest firmware installed. With Android 2.0 already knocking on the door, i guess a new firmware release is imminent. Perhaps in the next firmware Samsung will enable the proper hardware acceleration. Also I read somewhere on a forum that Motorola Cliq has the same problem as Galaxy.

Back on the subject, maybe the way Qualcomm uses the GL functions is something similar with extensions.. obtain the function address at initialization and then use the function directly, without any NDK. And if i'm thinking a little bit, the Neocore demo was available way before the release of the NDK, so it's using it's own stuff.

zorro wrote:So you're thinking that if the program uses float data type in OpenGL, the rendering is done in software mode.

Unfortunately i cannot try 'san-angeles' on the Galaxy because the phone has Android 1.5 only and it has the latest firmware installed. With Android 2.0 already knocking on the door, i guess a new firmware release is imminent. Perhaps in the next firmware Samsung will enable the proper hardware acceleration. Also I read somewhere on a forum that Motorola Cliq has the same problem as Galaxy.

Back on the subject, maybe the way Qualcomm uses the GL functions is something similar with extensions.. obtain the function address at initialization and then use the function directly, without any NDK. And if i'm thinking a little bit, the Neocore demo was available way before the release of the NDK, so it's using it's own stuff.

Well, actually "san-angeles" doesn't link with anything (guessing from code), it just loads OpenGL library and gets functions from there. I think this should work on 1.5 too. I can try to compile it for 1.5 and post result here.

Dmitry.Skiba wrote:Well, actually "san-angeles" doesn't link with anything (guessing from code), it just loads OpenGL library and gets functions from there. I think this should work on 1.5 too. I can try to compile it for 1.5 and post result here.

Well, I was wrong San-angeles links to the OpenGL dispite having mechanism for manually loading lib and retrieving gl functions (it is simply disabled in makefile). Another issue is that it is slow by design, here is an excerpt from Java file:
And indeed, it runs very slow on my G1.

It seems that I was also wrong on how neocore loads gl. It is linked normally, as GLESHack.

Now, lets try this:
(1) Use the same attributes when choosing config as neocore does. This can be done using chooser:

Neocore specifies just depth size of 16. You can also play with color component sizes.
(2) Find game demo for 1.5 which obviously uses OpenGL and performs well. Such demo will likely not use any native GL code, so our chances in replicating its behaviour is pretty high.

Personally I think that the problem is how we setup GL. I use GLSurfaceView, and maybe values that it uses by default is not compatible with Galaxy.


BTW, fps drops heavily when using depth size of 16 on G1. Maybe on Galaxy it other way around somehow.

Man, you're incredible! It works!
I managed in the end to enable HW on galaxy the way you showed me.
All i had to do is add this



before setRenderer(...) in the class that extends GLSurfaceView.

This enables hardware acceleration by a snap. I guess it's the depth size that switches from software render to the hardware one. The build works great on Galaxy, i haven't tried it on G1 to see if works slowly with the new config (i have not used egl config before).

So it is not necesarry to use native code. I added the solution to my game written entirely in java OpneGL (no native code) and it works great.

I searched on the internet and nobody knows how to use HW acceleration in Dalvik on Galaxy, so we're the first to figure it out!

EDIT I tried the same build on HTC Hero and it works the same as before. I must try it on G1 as well to see if it's the same.

EDIT 2 The Galaxy is more sensible at textures bigger than 512x512 than G1 or Hero (in those screens in my game where these textures are used, it has a lower fps) . Otherwise is fine..

zorro wrote:Man, you're incredible! It works!
...

This is sooo good to hear!
Now Galaxy users will finally play my game!

And yes, I was wrong again, it didn't slow down on G1 with this depth size



PS. I think this solution can be interesting to others, so I will post link to this thread to android-developers.

I can confirm that the fix above works on the Huawei Android phone too (the only one i guess, so far). So right now an OpenGL application should run in hardware mode on every Android device out there.

I can confirm that this works on the galaxy (the performance is not quite the same of the g1 though, but at least, now it is bearable).

I noticed this problem on the tattoo as well, but havent been able to test the fix there yet.

Thanks a lot, really made the day worthwhile.

BTW, if you want to have a look at what im developing try searching 'rockonnggl' on the Market.

Cheers,
Filipe

Unfortunately the code above does not work well on Motorola Droid (and other Android 2.0 phones). I don't have the Droid, but users are complaining about 'ghosting' and that's because of the pixel format for sure. The engineers at Google suggest that the best practice is to use the default config provided by GLSurfaceView (without EGL). Using EGL config is more tricky because after that you have to test all the phones and to implement the proper config for each one of them. I tried to find a config that suits all the phones but I didn't succeed (see here).

So I decided to take away from my game the EGL code posted here in order to let GLSurfaceView setup OpenGL without any interfering. With this move I know the Galaxy will move like crap at 2-3 fps, but the Droids are much more popular. After all it's Samsung's fault that the GL renderer is not starting by default with hardware accel.. what can I say..

zorro wrote:Unfortunately the code above does not work well on Motorola Droid (and other Android 2.0 phones). I don't have the Droid, but users are complaining about 'ghosting' and that's because of the pixel format for sure. The engineers at Google suggest that the best practice is to use the default config provided by GLSurfaceView (without EGL). Using EGL config is more tricky because after that you have to test all the phones and to implement the proper config for each one of them. I tried to find a config that suits all the phones but I didn't succeed.

So I decided to take away from my game the EGL code posted here in order to let GLSurfaceView setup OpenGL without any interfering. With this move I know the Galaxy will move like crap at 2-3 fps, but the Droids are much more popular. After all it's Samsung's fault that the GL renderer not start by default on hardware.. what can I say..

So far I haven't received any complaints from Droid users (but I never tested one myself). Are you sure it is the EGL config that is causing the problem? Ive had some other issues with textures flickering when changing the textures while drawing. In the end it was something related to the type of texture overlay i was using (now ive settled with GL_MODULATE if i remember correctly).

I'm using MODULATE as well for textures. If you are using EGL for Droid, what config are you requesting. I used to request a 24 bit zbuffer but users complained about 'ghosting'. Then i used explicitly a RGB565 with Z24 but users complained now that the app was not starting at all (crash at init). I don't have the phone and that is why I don't know how to make it work I guess.

zorro wrote:I'm using MODULATE as well for textures. If you are using EGL for Droid, what config are you requesting. I used to request a 24 bit zbuffer but users complained about 'ghosting'. Then i used explicitly a RGB565 with Z24 but users complained now that the app was not starting at all (crash at init). I don't have the phone and that is why I don't know how to make it work I guess.

Sorry I dont have the code with me right now, but I think I have loaded texture bitmaps in RGB565 as well as ARBG8888.