anyone doing ogre on gles2.0?

[Shadow007]

Well done MasterFalcon !!! I think it really adds to Ogre's "multi-platform-ness" credibility...

Perhaps someone could try and compare the framerates with a "current" entry level PC to give a point of comparison ...

[warmi]

Here ya go guys!

http://www.flickr.com/photos/40021446@N07/?saved=1

oh btw.
will there be a fallback to gles 1.1 for older iphones?

grtz

As you can see, especially from the Skeletal Animation demo, performance isn't that great in some cases. The CPU is spending a lot of time with matrix/vector ops. I've stubbed in code to use the SIMD units on both types of CPUs but I haven't gotten to it yet. It's a high priority item on my TODO list.

Back to the day job! It's really cool to see people excited about this, I know I am!

Well, it will never run great when attempting to run code that was meant for GTX style graphics cards
In any case, GLES 1.x based iPhones require tons of hacks to get something resembling decent performance ... the latest one though is much better ... things like vbos finally work as expected , fill rate has improved 5 times etc..

[Wolfmanfx]

Looks already nice great work. Cannot wait to try it on my 3g. Which sdk version do u use 3.1? If need someone to test it on an other mac iphone i will i have time today

[masterfalcon]

Looks already nice great work. Cannot wait to try it on my 3g. Which sdk version do u use 3.1? If need someone to test it on an other mac iphone i will i have time today

Right now it's compiled against 3.1 but will end up requiring 3.0 as the minimum.

[DanielSefton]

Awesome! Count me in as another tester. - I have an original iPhone, a 3GS and a 2nd gen touch, so it will be interesting to see how they differ.

At the end of the day, Ogre will never be as fast as native iPhone 3D engines, since it's not optimized for such a purpose. But the frame rates you're getting so far look promising. (most 3D games in the app store usually use cheap hacks, basic texturing, extreme low polygon models, and small view distances anyway)

[Assaf Raman]

Wow!
nice work.

[masterfalcon]

Fantastic! I've had a nasty cold for the last week so my progress has slowed a little. There are some nasty bugs in a handful of demos and some CMake things that I need to take care of before I'll feel comfortable making a first release into SVN.

A couple other notes for y'all to let you know how much functionality is there.

- CEGUI has not been ported yet. I'll get to it soon though
- I'm not a lawyer and I've heard about some open source licenses having issues with code signing(GPL3 for example). I haven't looked at the licenses for OGRE and it's dependencies to ensure that it will be ok. I really hope so!
- SIMD acceleration will be vital and I've stubbed in support but the release of the 3GS has complicated this by adding another SIMD API so I need to finish the CPU capabilities detection so that the correct language is used for the correct CPU.
- Input is currently limited to single taps and drags. I'll probably commit that code upstream to OIS when it's more mature.

That's all I can think of for now. Building is not as easy as it should be because of some missing CMake functionality(no ability to set project settings from a CMake script...grr).

[jacmoe]

(no ability to set project settings from a CMake script...grr).

What settings do you want/need?

[masterfalcon]

(no ability to set project settings from a CMake script...grr).

What settings do you want/need?

Let me check...

- Project Format (needs to be 3.1 or higher for code signing, defaults to 2.4)
- Other Linker Flags(OTHER_LD_FLAGS). The configuration gets hard coded into the path from the $(CONFIGURATION) variable, but needs to be $(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME). This second var is undefined on OS X and each target can be built for iphoneos and iphonesimulator, using the variable names instead of resolving them allows for greater flexibility.
- GCC_THUMB_SUPPORT would be nice(turning it off boosts performance)
- PRODUCT_NAME. There's an outstanding bug in Xcode that is fixed in 10.6(can I say that?) that complains about underscores. It's a valid character but it kicks out an error in Xcode < 3.2

I think that's all of the issues that I've run into

[warmi]

- GCC_THUMB_SUPPORT would be nice(turning it off boosts performance)

I don't think this even should be an option given what this library is all about. Enabling thumb support will replace every floating point operation with a DLL based call - you can imagine what this will do to performance.

[masterfalcon]

- GCC_THUMB_SUPPORT would be nice(turning it off boosts performance)

I don't think this even should be an option given what this library is all about. Enabling thumb support will replace every floating point operation with a DLL based call - you can imagine what this will do to performance.

I should have elaborated more. It's turned on by default, so I'd want to turn it off. I can add -mno-thumb to CFLAGS but I can't remember how gcc processes options. Since both -mthumb and -mno-thumb are going in, which will be used?

[jacmoe]

Play with add_definitions and set the variables CMAKE_CXX_FLAGS_RELEASE, CMAKE_CXX_FLAGS_DEBUG and CMAKE_EXE_LINKER_FLAGS ..
You can do almost anything with CMake.
I haven't heard that CMake defaults to 2.4.. It uses the latest build tool you have. But, I'm not on a Mac.
If the XCode generator is troublesome, you can import regular Linux makefiles in XCode, how about that?

[warmi]

- GCC_THUMB_SUPPORT would be nice(turning it off boosts performance)

I don't think this even should be an option given what this library is all about. Enabling thumb support will replace every floating point operation with a DLL based call - you can imagine what this will do to performance.

I should have elaborated more. It's turned on by default, so I'd want to turn it off. I can add -mno-thumb to CFLAGS but I can't remember how gcc processes options. Since both -mthumb and -mno-thumb are going in, which will be used?

Actually, that's my mistake. I didn't realize you were using CMake (should have read more closely) to generate an XCode project . In this case, definately set GCC_THUMB_SUPPORT to false - don't add -mno-thumb to CFLAGS because it is going to confuse the hell out of people if for whatever reason they decide to generate code for the 16-bit thumb instruction set.

In any case, you if run instruments and see methods like __multdf3vfp coming up on top, it means you have -mthumb on

[warmi]

- SIMD acceleration will be vital and I've stubbed in support but the release of the 3GS has complicated this by adding another SIMD API so I need to finish the CPU capabilities detection so that the correct language is used for the correct CPU.

One way to handle this is to create a fat binary (lib) ( which is what Optimized (armv6 armv7) arch setting does) and then simply wrap any arm7 code with #ifdef _ARM_ARCH_7 and so on ( I have that working for VFP and now will be implementing for NEON related stuff)
BTW this not only applies to SIMD but also to GLES apis.

I have seen people suggesting doing runtime GLES checks ( starting with 2.0 context check and then falling back on 1.x if unavailable) but that would imply run time checks for everything which I personally find a bit too heavy.

Interestingly, with the release of the 3gs now there are actually 3 different GLES profiles to worry about.

1. The original GLES 1.x (MBX) with various limits like 2 texture units, no clip planes.
2. GLES 1.x (SGX) with support for 8 texture units and other SGX functionality ( FFP emulated with shaders)
2. GLES 2.x (SGX) (no FFP , shaders only)

Also, the original VFP unit is not really a true SIMD the way NEON is. You need to explicitly enable/disable vector mode, which makes it impractical for inlining short burst of vectorized code.
On the other hand with NEON , it makes perfect sense to use intrinsics everywhere because gcc will not generate decent NEON code, and the VFP unit included with Cortex is actually slower than the ARM11 version ( it is called VFP Lite and it is not pipelined)

[masterfalcon]

Play with add_definitions and set the variables CMAKE_CXX_FLAGS_RELEASE, CMAKE_CXX_FLAGS_DEBUG and CMAKE_EXE_LINKER_FLAGS ..
You can do almost anything with CMake.
I haven't heard that CMake defaults to 2.4.. It uses the latest build tool you have. But, I'm not on a Mac.
If the XCode generator is troublesome, you can import regular Linux makefiles in XCode, how about that?

I'll play around with that and see what happens <fingers crossed>

One way to handle this is to create a fat binary (lib) ( which is what Optimized (armv6 armv7) arch setting does) and then simply wrap any arm7 code with #ifdef _ARM_ARCH_7 and so on ( I have that working for VFP and now will be implementing for NEON related stuff)
BTW this not only applies to SIMD but also to GLES apis.

Are you doing NEON stuff for OGRE or another project?

I have seen people suggesting doing runtime GLES checks ( starting with 2.0 context check and then falling back on 1.x if unavailable) but that would imply run time checks for everything which I personally find a bit too heavy.

Ya, the 1.x and 2.0 systems are different enough to warrant them being treated as separate rendersystems. It'll be easier to maintain and read that way.

Also, the original VFP unit is not really a true SIMD the way NEON is. You need to explicitly enable/disable vector mode, which makes it impractical for inlining short burst of vectorized code.
On the other hand with NEON , it makes perfect sense to use intrinsics everywhere because gcc will not generate decent NEON code, and the VFP unit included with Cortex is actually slower than the ARM11 version ( it is called VFP Lite and it is not pipelined)

In your opinion, is it worthwhile to optimize for VFP in OGRE? There is a very large installed hardware base with ARM6 processors right now. Also, are you referring to the gcc intrinsics for NEON?

[warmi]

Are you doing NEON stuff for OGRE or another project?

Another project ( I am just starting with NEON... still learning )

In your opinion, is it worthwhile to optimize for VFP in OGRE? There is a very large installed hardware base with ARM6 processors right now. Also, are you referring to the gcc intrinsics for NEON?

Only if you are doing something in a loop or at least executing enough instructions to offset the cost of switching to vector mode ( which is a serializing instruction meaning it will essentially flush the pipeline.)
In other words there is no point trying to optmize things like

Code: Select all

inline Vector3& operator *= ( const Real fScalar )

.
On the other hand, methods like BillboardSet::genVertices or stuff in OgreOptimisedUtilSSE.cpp would probably benefit from vectorized VFP code.

I remember optimizing Mat4 multiplications and on its own it gave me I think maybe 10% boost over optimized C++ code, but when I reused the same code in a loop (along with unrolling and other arm specific optimizations - doing software vert transforms) I got about 300% speedup.

Frankly, I don't remember being limited by CPU within my code ... what really kills performance on the original iPhone is the OpenGL driver code which insists on copying vertices on every draw call (VBOs or not) which limits your triangle throughput to about 10 K vertices per frame before things start going to hell – this has nothing to do with the GPU.
The only way to get around it is to limit your vertex structure size as much as possible, use shorts for everything – it makes for ugly code though ( you need to include scaling in your node transformations to get back to the original value)
In terms of fill rate, use compressed pvrt textures whenever possible, don’t use alpha-test (use alpha-blend instead) etc …

The latest iPhone though is a completely different beast, vbos actually do work as intended, the fill rate has increased about 5 times … I am still playing with it but so far it looks great.

[masterfalcon]

Cool, I've already begun the setup for OgreOptimizedUtilVFP and OgreOptimizedUtilNEON. That seemed like the most logical place to optimize. Something like the Skeletal animation demo really shows off how optimizing those matrix ops will help on this platform.

[masterfalcon]

Play with add_definitions and set the variables CMAKE_CXX_FLAGS_RELEASE, CMAKE_CXX_FLAGS_DEBUG and CMAKE_EXE_LINKER_FLAGS ..
You can do almost anything with CMake.
I haven't heard that CMake defaults to 2.4.. It uses the latest build tool you have. But, I'm not on a Mac.
If the XCode generator is troublesome, you can import regular Linux makefiles in XCode, how about that?

Upon further inspection, the problem is that compatibilityVersion is not set in the PBXProject section of the project. For some reason, upon being re-saved and formatted by Xcode this gets set to:

compatibilityVersion = "Xcode 2.4";

when we'd like it to be:

compatibilityVersion = "Xcode 3.1";

I'm not sure if that can be accomplished without patching CMake but I'm definitely no expert.

[jacmoe]

compatibilityVersion = "Xcode 3.1";
I'm not sure if that can be accomplished without patching CMake but I'm definitely no expert.

Me neither, but I am a good Googler:
http://www.vtk.org/Bug/view.php?id=8252

[masterfalcon]

compatibilityVersion = "Xcode 3.1";
I'm not sure if that can be accomplished without patching CMake but I'm definitely no expert.

Me neither, but I am a good Googler:
http://www.vtk.org/Bug/view.php?id=8252

Ya, I found that too. But it's still marked as a new issue so who knows when it'll get merged in.

[masterfalcon]

I haven't figured out a way to fixup the library paths without patching CMake. I suppose a running a sed script to alter the Xcode project file is an option.

Meanwhile, a few more screenshots from the 3GS have been posted to the Flickr stream and the CMakefiles have been fleshed out, some minor issues with the code fixed and I'm almost comfortable with submitting it.

[davehorner]

I'm quite excited about the ogre3d on iphone developments. I will be watching this thread for download details...

Very cool stuff.

--dave
http://dave.thehorners.com/

[itistoday]

Any update? Also, are these frame rates on the 3GS typical of the number of triangles being rendered? Or is there still stuff that can be done to bring up the frame rate? Thanks masterfalcon for your work on this! Very exciting addition to Ogre's capabilities.

[masterfalcon]

Any update? Also, are these frame rates on the 3GS typical of the number of triangles being rendered? Or is there still stuff that can be done to bring up the frame rate? Thanks masterfalcon for your work on this! Very exciting addition to Ogre's capabilities.

I'm not sure how it compares to other apps right now but there is certainly still some room for improvement. I'm still investigating and profiling like mad.

[itistoday]

I'm not sure how it compares to other apps right now but there is certainly still some room for improvement. I'm still investigating and profiling like mad.

Thanks for the update! I wish I could help but my OpenGL skills ... are near non-existent. :-p