Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
LMcRae
Posts: 163
Registered: ‎04-16-2009
My Device: Not Specified

OpenGL inital findings

Hello everyone.  I have been working with the new OpenGL API for a few weeks now and I have some findings I would like to share and maybe a few people could comment on them.   So far everything is working out well but we really need VBO.

 

1) Converting from floating point to fixed point for all my buffers (vertices, normals and texture coords) is actually slower.  This was surprising and leads me to believe that the GPU uses full floats, which is pretty surprising.  I can only speculate that the fixed point stuff is around for dynamic geometry that is being generated in fixed point for cpu performance reasons.  Having the driver doing the conversion from fixed to float would be faster in native code.  Comments?

 

2) FloatBuffers are terrible for dynamic geometry.  It's actually faster to have a mirrored version in arrays for working and then put them in the FloatBuffer when done.  This again was surprising.  Maybe someone could comment on this?

 

3) This one is a shocker.  My frame rate drops 20% when all my geometry is offscreen.  I am not using view frustum culling since I felt the more I could put on the GPU the better.  I am already carrying Java on my back :smileyhappy:   Perhaps RIM could supply a native function to do a basic sphere fustum check.

 

4) GLUtils.gluLookAt allocates memory.  Thanks for the helper but I will be writting my own thank you.

 

5) Bitmap.scaleInto will destroy your alpha if you intend to make mipmaps on the fly.  Hopefully this will save someone an hour or two..  Oddly enough the simulator supports auto mipmaps but the device doesn't. 

 

6) It would be helpful to have a small doc talking about how the windowing is being done. Particularly I am interested in how the Bitmap that is used to create the Graphics works.  I am talking about the Graphics that is supplied to eglWaitNative.  When I create a surface using eglCreateWindowSurface, is it double buffered?  What happens to the FullScreen.paint and FullScreen.paintBackground? What is the Bitmap that was used to create the Graphics used for? Could we get a sample showing how to use native fields like ButtonField overtop of an OpenGL scene?

 

7) I am concerned eglWaitNative, eglWaitGL and eglSwapBuffers blocking.  Usually a graphics driver has a push buffer (DMA buffer) of commands that get built and swapbuffers does a flush not a finish.  This allows the thread to continue to do other things and not block  Is this what is happening?

 

 

 

Please use plain text.
Developer
rcmaniac25
Posts: 1,804
Registered: ‎04-28-2009
My Device: Z10 (STL100-4)-10.2.1.3253, Z10 (STL100-3)-10.3.1.634 Dev OS, Z30 (STA100-5)-10.3.1.634 Dev OS, Passport (SQW100-1)-10.3.0.1154, PlayBook (16GB)-2.1.0.1917
My Carrier: Verizon

Re: OpenGL initial findings

Good to hear your research.

 

  1. Are you converting floating point to fixed-point or do have the fixed-point data and you are talking about the processing itself? Also is this testing on the simulator or the device itself? The specifications for the GPU on the Storm 2 (the only device that currently supports OpenGL [from what I read]) say that it uses fixed-point.
  2. I have not tried working with dynamic geometry so I don't have any real comments on this.
  3. It could be something to ask for on the Issue Tracker, you could also try making your own and optimizing the heck out of it.
  4. Good to know, did you profile it? If so, how much memory does it use?
  5. The auto mipmaps is likely a result of the simulator using DirectX (ironic isn't it? I had a question about OpenGL support in the simulators and MSohm said that DirectX is needed to do OpenGL) which if it has the ability to will often do as many optimizations as it can.
  6. This could be another thing to ask for in Documentation on Issue Tracker. I would like to know more myself, I want to add a title and status to the screen. Would OpenGL work in the remaining area or do I need to create a special Screen to do that.
  7. No clue.

I would like to ask you if you ever encountered something like this before:

http://supportforums.blackberry.com/t5/Java-Development/5-0-Simulator-supporting-OpenGL-ES/m-p/38644...

(The message posted at  11-24-2009 08:58 PM).

---Spends time in #blackberrydev on freenode (IRC)----
Three simple rules:
1. Please use the search bar before making new posts.
2. "Like" posts that you find helpful.
3. If a solution has been found for your post, mark it as solved.
--I code too much. Well, too bad.
Please use plain text.
Developer
LMcRae
Posts: 163
Registered: ‎04-16-2009
My Device: Not Specified

Re: OpenGL inital findings

1) All my data is in floating point since I wanted to just get things going.  I have recently made a conditional compile that will convert the data to fixed point once at load time.  I have a static scene that I use to test frame rate and I went from 17fps with floating point to 14fps for fixed.  It's pretty shocking.  I can see it not gaining me anything as perhaps the scene is fill bound or bottled somewhere else but actually loosing frame rate is shocking.  My test must be wrong somewhere.  I will double check it.

 

3) Just ported my c stuff over.  We shall see how it works.  I noticed Andriod has a culling funciton for spheres.

 

4) Not sue how much memory.  I just had it running in JDE with break when any object is created and it kept hitting it.  That was enough for me.  Allocation == evil.

 

5) True enough but it cost me a few hours figuring out why my textures stopped working on device. 

 

It would be good to get more info on this as testing on the simulator is useless and the turn around time on device is brutal. I also ended up writing my own profiling since the on device one isn't very good.

Please use plain text.
Developer
rcmaniac25
Posts: 1,804
Registered: ‎04-28-2009
My Device: Z10 (STL100-4)-10.2.1.3253, Z10 (STL100-3)-10.3.1.634 Dev OS, Z30 (STA100-5)-10.3.1.634 Dev OS, Passport (SQW100-1)-10.3.0.1154, PlayBook (16GB)-2.1.0.1917
My Carrier: Verizon

Re: OpenGL inital findings

1. That is odd, I wonder if it is some code oddity (I know there are cases of an app not working it App A is in the background, the WebBrowser is open, etc. etc., odd bugs like that).

3. Android, from what I remeber reading, doesn't have a full standards complient namespace. It has most of it but they wrote some extra functions in there.

4. It might be temporary allocation, each app has the ability to create local variables. It doesn't mean that the memory will remain allocated.

5. That always stinks.

---Spends time in #blackberrydev on freenode (IRC)----
Three simple rules:
1. Please use the search bar before making new posts.
2. "Like" posts that you find helpful.
3. If a solution has been found for your post, mark it as solved.
--I code too much. Well, too bad.
Please use plain text.
Administrator
MSohm
Posts: 14,528
Registered: ‎07-09-2008
My Device: BlackBerry Z30, BlackBerry PlayBook
My Carrier: Bell

Re: OpenGL inital findings

1.  I believe the BlackBerry smartphone does actually use floating point for buffer data (vertices, texcoords, etc), which would explain your findings.  I'm working on confirming this for sure.

2.  There is currently a bit of overhead when updating direct nio buffers (not just float buffers).  Using a small number of bulk puts instead of a large number of smaller/single puts should definitely perform better today.

3. This is an odity of the GPU driver.  I suggest doing your own view frustum culling.  Java is no reason to leave culling/clipping to the gpu.  Culling out huge numbers of triangles using a very fast frustum-sphere or frustum-box test will be way faster than leaving it to the driver to reject.

 

4.  I've sent this to our development team for further investigation.

 

5.  This has to do with the BlackBerry smartphone simulator using your desktop driver, which differs from that on the device itself.

 

6.  I don't have any samples or documentation to offer on this.  But I have collected your feedback and will be sending it to our documentation team.

 

7.  eglWaitNative and eglWaitGL will block only if the graphics context is drawn to before or after making these calls.  eglSwapBuffers actually does block today.  This may also change eventually, but today it can be assumed that eglSwapBuffers does an internal glFinish.

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Please use plain text.
Developer
LMcRae
Posts: 163
Registered: ‎04-16-2009
My Device: Not Specified

Re: OpenGL initial findings

Thank to everyone for the great responses. 

 

1) I did some more test and I think some of my numbers have been off.  If I have a fully static scene, no moving of camera or anything, then my frame rate usually starts off as 14fps.  This pretty much remains the same even if I leave it for a minute.  When I run the app the second or third time it will settle at 17fps.  Since the device has to reboot every time I update, I suspect the OS is still doing stuff.  With that said, I am finding no difference between fixed point and floating.  The other numbers are correct.

 

3) I see your point to some extent but I can pretty much guarantee no one does there own clipping these days unless it's a special case such as portals.  I can see culling for sure but I can also see not culling for some cases.  It's one thing to make a graphical demo that uses all the CPU but another when you have collision and AI involved.  So you need to retain every bit of CPU possible and make sure the GPU is fully untillized.

 

4) I would fully expect the allocation to be temp but wouldn't it still give the gc a chance to run?  That is what I am ultimately concerned about.

 

5) I can understand that but it does make it much harder to develop if the simulator doesn't show similar results.  It forces me to test on device much more often to see if the results are the same.  Really GL_GENERATE_MIPMAP isn't in the GL10 namespace, it's in GL11.

 

7)  That really helps.  Thank you.  I will try and make a render thread and see if I can reclaim some cycles. 

 

All and all I am extremely happy/grateful that RIM has supported OpenGL ES.  Now all we need is some audio mixing and we are good to go!

 

 

 

 

Please use plain text.
Developer
rcmaniac25
Posts: 1,804
Registered: ‎04-28-2009
My Device: Z10 (STL100-4)-10.2.1.3253, Z10 (STL100-3)-10.3.1.634 Dev OS, Z30 (STA100-5)-10.3.1.634 Dev OS, Passport (SQW100-1)-10.3.0.1154, PlayBook (16GB)-2.1.0.1917
My Carrier: Verizon

Re: OpenGL initial findings

1. The device might be caching some pre-set values causing it to be slow. At least it seems to speed up afterwards.

4. It would give the gc a chance to run but MSohm said he sent it to the dev team so it might not last. By the way how did you get a function/breakpoint to be called whenever memory is allocated?

5. Nothing's perfect, when RIM ports the simulators over to Java so they work on Mac/Linux this might go away.

7. That does help.

 

Try System.getProperty("supports.mixing") to see if your BlackBerry supports audio mixing (running more then one audio Player at the same time). Unfortunately CDMA devices don't support audio mixing, if they could get that implemented that would be great but until then I will need to make my own audio mixer.

---Spends time in #blackberrydev on freenode (IRC)----
Three simple rules:
1. Please use the search bar before making new posts.
2. "Like" posts that you find helpful.
3. If a solution has been found for your post, mark it as solved.
--I code too much. Well, too bad.
Please use plain text.
Developer
LMcRae
Posts: 163
Registered: ‎04-16-2009
My Device: Not Specified

Re: OpenGL initial findings

I tried putting the swap into a thread and got no benefit but it could simply be my poor Java skills or that my updating of the simulation is very light right now so there are no gains at this point.  Here is my code I used.

 

 

class SwapThread extends Thread
{
	public boolean m_bKill		= false;
	public boolean m_bSwapping	= false;

	public synchronized void renderStart()
	{
		m_EGL.eglWaitNative( EGL10.EGL_CORE_NATIVE_ENGINE, m_OffGraphics );
	}
	public synchronized void renderEnd()
	{
		while( m_bSwapping == true )
		{
			try
			{
				wait();
			}
			catch( InterruptedException e )
			{
			}
		}

		m_bSwapping = true;
		notifyAll();
	}

	public void run()
	{
		while( m_bKill == false )
		{
			synchronized( this )
			{
				while( m_bSwapping == false )
				{
					try
					{
						wait();
					}
					catch( InterruptedException e )
					{
					}
				}

				m_bSwapping = true;

				Profiler.Start( Profiler.ENTRY_RENDER_WAIT );
				m_EGL.eglWaitGL();
				Profiler.Finish( Profiler.ENTRY_RENDER_WAIT );

				Profiler.Start( Profiler.ENTRY_RENDER_SWAP );
				if ( m_EGL.eglSwapBuffers( m_Display, m_Surface ) == false )
				{
					if ( m_EGL.eglGetError() == EGL11.EGL_CONTEXT_LOST )
						onLostContext();
				}
				Profiler.Finish( Profiler.ENTRY_RENDER_SWAP );

				m_bSwapping = false;
				notifyAll();
			}
		}
	}
}

private SwapThread	m_SwapThread = new SwapThread();

//----------------------------------------------------------------------------------------------
public void onRenderBegin()
{
//#if SWAP_THREAD
//#         m_SwapThread.renderStart();
//#else
	m_EGL.eglWaitNative( EGL10.EGL_CORE_NATIVE_ENGINE, m_OffGraphics );
//#endif
}
public void onRenderEnd()
{
//#if SWAP_THREAD
//# 		m_SwapThread.renderEnd();
//#else
	Profiler.Start( Profiler.ENTRY_RENDER_WAIT );
	m_EGL.eglWaitGL();
	Profiler.Finish( Profiler.ENTRY_RENDER_WAIT );

	Profiler.Start( Profiler.ENTRY_RENDER_SWAP );
	if ( m_EGL.eglSwapBuffers( m_Display, m_Surface ) == false )
	{
		if ( m_EGL.eglGetError() == EGL11.EGL_CONTEXT_LOST )
			onLostContext();
	}
	Profiler.Finish( Profiler.ENTRY_RENDER_SWAP );
//#endif
}

 

I looked at the support mixing property and its false for Storm and Storm 2.  I also queried some of the JSR 234 properties and it looks like it's only camera stuff.  It's funny you mention writing a mixer as I mentioned this before on the list.  Now that my java is better I was going to try it again.  Have you had any success?  I just don't know if the cpu can handle all of this.  Sorry for hating on java , but when arrays have bounds checking it really kills this sort of thing.

 

 

 

 

Please use plain text.
Developer
rcmaniac25
Posts: 1,804
Registered: ‎04-28-2009
My Device: Z10 (STL100-4)-10.2.1.3253, Z10 (STL100-3)-10.3.1.634 Dev OS, Z30 (STA100-5)-10.3.1.634 Dev OS, Passport (SQW100-1)-10.3.0.1154, PlayBook (16GB)-2.1.0.1917
My Carrier: Verizon

Re: OpenGL initial findings

You have every right to hate on Java, it wasn't until recently that they actually tried speeding it up. Before that it was usually very slow unless you had a high-end computer. The good thing with BlackBerry is that the Java bytecode is converted to lower level code (from what I remember reading somewhere RAPC doesn't just copy the bytecode, it converts it to a lower level code type that reduces the amount of overhead of converting bytecode to the CPU's native ASM.).

 

The property, as you and I stated, returns false. If you search the forum you will find that this occurs only on CDMA devices, no idea why but I am not the one making cell phones.

 

I haven't even tried writing one. The thing is I like to go above and beyond so it may be nice to run two Players at the same time or to mix two audio streams together but I would want something that is limited only by the device it is running on, if I have the ability to mix 100 audio tracks together, I want to be able to. That is why I haven't written one yet but I plan to eventually.

---Spends time in #blackberrydev on freenode (IRC)----
Three simple rules:
1. Please use the search bar before making new posts.
2. "Like" posts that you find helpful.
3. If a solution has been found for your post, mark it as solved.
--I code too much. Well, too bad.
Please use plain text.