OpenGL performance on N950

[magicdave]

I'm working on a game engine targetted at both S^3 and Harmattan (currently testing on the N950). I am experiencing what seems to be very strange performance - OpenGL performance is really slow on the N950 compared to an E7, which seems totally wrong to me. To render a scene the N950 is taking about 22ms per frame where the E7 is taking 7ms.

To troubleshoot the issue I have found that it can be seen with only one instruction, glClear( GL_COLOR_BUFFER_BIT ) - this takes approximately 7ms which is obviously off.
I am using the [classify gaming] conf file which is working as volume control works properly.
I have based most of my setup code on the E-Pong example available on this site - I'm wondering if there is something I need to do differently when initialising GL, some resource I need to request to get decent performance, etc?

I haven't put this under gaming as it is a general OpenGL issue. Any help much appreciated!

[vladest]

Hi
cant say about OGL, couse have no experience with this, but writing another multithreaded heavy loaded app I've found that currently my E7 multitask is much better than n950 with beta2 FW. hope this just because of beta status of the FW

[magicdave]

Hi vladest

That's interesting thanks. I also thought that it could be firmware, but then noticed that the Angry Birds that comes with the new firmware is clearly running at a smooth 60fps. With my current performance of 7ms for a screen clear, just 2 screen draws already pushes me past this point so I suspect that there may be some specific opengl or policy options I need to enable to get good performance.

[mikpeson]

How do you measure the performance?

It's not possible to measure single GL calls as GL driver might return immediately but the GL HW would start the task and therefore might block the next GL call. Best thing you can do is to measure overall FPS.

When you clear the frame buffer always remember to clear the depth buffer as well (glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)). N950 uses SGX graphics HW and as it is a tiled based graphics architecture this is one important tip. I recommend you to check other tips from these docs:

http://imgtec.com/powervr/insider/powervr-sdk-docs.asp

We are currently porting EPONG game to Meego and it should be ready in few weeks. This question fits perfectly to the game development forum as apps usually do not use GL and you are building a game.

[magicdave]

Hi Mikpeson

Thanks for your reply, that's great news on the EPong example. That's a useful link, I have read up on the PowerVR optimisation previously and am using good practices as far as I know, but at the moment what I am rendering is not complex enough for this to be a real factor. I am measuring the performance in 2 places - firstly, as the game is system/component based, the execution time of each system (rendering using openGL is one of these).
Then as you suggested, a general frame timing averaged over the last x frames, to account for delays and hardware buffering etc. This one will usually lock to closest screen update timing on Symbian due to eglswapbuffers blocking (if my understanding is correct).

I'm aware that this is a "naive" measurement due to some calls blocking, some returning immediately etc, however in a simple way I figure both of these timings would need to be under 16ms to get 60fps - if the GL draw instructions themselves are already taking longer than a frame to return, the driver caching doesn't really enter into it yet.

As my game is 2d I am not using the depth buffer and had it disabled in my eglconfig, and with glDisable( GL_DEPTH_TEST ). However in case it was a hardware issue I tried setting EGL_DEPTH_SIZE, 16 and adding the depth buffer to clear with glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT). This didn't make any difference to the performance.

It's almost like there is some initial high cost to a GL frame draw, as increasing the complexity of the scene a bit makes very little difference to speed (it does more on the E7), but drawing anything at all has this initial performance penalty.

Proper numbers:
Frame execution time is the time to execute all the instructions for a frame EXCEPT eglSwapBuffers, total frame is the time to complete a full loop (both of these averaged) for the same scene:

E7: Frame execution time 4.4875 / Total frame time 16.4667
N950: Frame execution time 25.7167 / Total frame time 27.4958

[mikpeson]

As N9/N950 has large screen you might be fillrate limited.

Can you limit your rendering to smaller area by doing glViewport(0,0,w/2,h/2) and see if you get 60 fps. If you do then you are filling just too many pixels or your shaders are too complex. Reducing amount of transparent pixels or using texture compression might help to get more performance.

[magicdave]

I've tested with that quarter area and the timings there are 16.8 / 20. It would seem that fill rate is definitely a factor. I am still confused though, because this is rendering 427 X 240 a lot slower than E7 is rendering 480 X 360.
As I said it's a 2D scene, and has about 2.5x overdraw which I would imagine should be well within N9 capabilities. Shaders are very standard projmatrix mviewmatrix texture at the moment... no lighting or anything special.

As an update I have tested this also now on an N9 and it has the same result so it's not any N950 or firmware problem. I'm sure that it must be something in my code but can't think what could cause this performance difference between the devices.

When getting the framework from EPONG / QtGameEnabler to run on Meego I had to remove most of the EGL config to get it to work otherwise got invalid configurations, so now it is just

EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
EGL_BUFFER_SIZE, 16,
EGL_DEPTH_SIZE, 0,
EGL_NONE

Don't know if this could be it?

I definitely plan to add texture compression, I know Symbian phones only support ETC1, does N9 have greater support (like PVRTC)?

Thanks very much for your help.

[shpe]

from what I see, Qt has performance issue as well

question... does Qt have some quality setting like LOW, MEDIUM, HIGH, which says how smooth should render the graphics (anti-alias / interpolations in images)

flash does have this setting... and I made a game which sets it's quality based from the FPS of the phone... goes LOW in S60V5 and HIGH in S^3 phones... this is the game: http://store.ovi.com/content/205196

anyway, flash(AS2) is the fastest developing medium for me... still I'm not convinced with Qt, especially it's future with Nokia-Windows

[magicdave]

Just an update - finished the first game version for symbian, on the 700 the frame performance is about 1.8 - so over 10 times better than N9... still kind of mystified. Now that I'm moving on to focusing on the N9 I'm going to see about running a proper benchmark accross the two platforms to get to the bottom of this.

[mikpeson]

Yes, new Nokia Belle devices with the upgraded GPU gives a lot of per pixel performance as the display resolution is only NHD. As N9 includes WVGA resolution and if your game is doing heavy blending operations your game might not run properly.

I just discovered that you can actually do really low-level investigation with PVRTuneLinuxARM tool as N9 uses SGX graphics accelerator.

I downloaded that and copied SGXPerfServerDeveloper binary to /home/developer/bin directory using SCP and started it from SSH console. Then I launched PVRTuneDeveloper.exe on my PC and connected to the device. After that you can just run your application and see where the potential bottlenecks are.

[mikpeson]

Just did some more benchmarking and here are the results.

N9
Const color shader: 10 layers, 232 Mpixels/s
Color shader: 2 layers, 47 Mpixels/s
Texture2D shader: 6 layers, 140 Mpixels/s
Texture2D*const color shader: 5 layers, 116 Mpixels/s
Texture2D*color shader: 2 layers, 47 Mpixels/s

Nokia 701
Const color shader: 25 layers, 331 Mpixels/s
Color shader: 23 layers, 305 Mpixels/s
Texture2D shader: 21 layers, 278 Mpixels/s
Texture2D*const color shader: 19 layers, 253 Mpixels/s
Texture2D*color shader: 18 layers, 240 Mpixels/s

Based on those results there are couple of shader running at low speed on N9 marked with bold so basically if you are interpolating 4-component RGBA color it won't run very fast but basic texture2D without modulation you can fill N9 screen 6 times.

[magicdave]

Thanks mikpeson, that's awesome, this is exactly what I was looking for

I had a uniform colour multiply in my standard fragment texture shader, mostly unused at 1, 1, 1, 1 which on the N9 seems to have a huge performance impact. Having removed that I am now down from 85% (which may as well be 100% I'd guess) to 40% on the USSE pixel load. I will need to add it in as a shader for some specifics things but I think it should be quite manageable if it is only enabled when needed.

My framerate is now up to ~45fps at the moment, much better. I'd like to get to 60 if possible and I think texture compression would be the next thing to try since none of the metrics are now that high - I've seen good results from it in the past for speed increase. I've seen the presentation about epong which mentions that ETC1 is supported on N8 and so I assume N9, and I will need to implement this to fit the games graphics into video memory on N8 in future - so from here I have 2 further questions:

1. Do you know if other compression schemes are supported on the new Belle devices and N9, i.e. PVRTC maybe?
2. Is there somewhere example code for using ETC1, simple rgb565 (not actually compression I know) or other schemes on these devices? I've searched the documentation but it gets a bit cryptic for me as to what the actual texture loading call is (glCompressedTexImage2D or similar, and what the best tools are to compress the texture)

Thanks again for your help so far.

[mikpeson]

Good to hear that you are progressing with the performance.

You should also take a look at the other tools from Imagination. You compress your textures with PVRTexTool and PVRTexLib tools. Imagination also provides full SDK examples how to use texture compression in general.

Do you need alpha channels for your textures? PVRTC format supports alpha but ETC does not. ETC is available on N8/Belle devices and for those you could do more shader code to combine compressed RGB and A textures. Remember to use mipmaps as those help a lot if you are doing rotation or zooming for your textures.

Imagination also provides offline shader compiler (PVRUniSCo Editor) and you can use the command line tool (PVRUniSCo_SGX53x.exe) to check how many cycles are spend on your vertex/fragment shaders. However, I don't know if this offline tool fully captured all my previous performance findings and therefore PVRTune is the best tool as it runs with the real HW.