For those who may not know (but, I see a lot of familiar faces/avatars/handles here), I'm the goofball who came up with the concept for Pi-finity!, an educational game system (not just one game) that will help students learn STEM principles through physical and other simulations, as well as software development tasks. It will be in full 3-D and take advantage of the Pi GPU to the maximum extent possible. The idea is that there will be a different world for each game, comprised of 3-D graphics objects ala a massively multi-player on-line role-playing game (MMORPG).
Players will be able to visit each world and interact with both the world and other players, either collaboratively or competitively, to achieve various goals (it will be up to the game designers). I plan to develop a toolset that will allow people to easily create worlds and their constituent objects using off-the-shelf 3-D models developed in tools such as Blender, SolidWorks, etc. Programming problems will be a core feature of games, and will range from very simple, constrained problems (e.g., simple noun-verb procedural syntax) all the way up to Python, and perhaps even C code.
I'm exploring multiple paths to build the toolsets, and there are a few others working on various bits and pieces of software, including potentially porting 3-D libraries/APIs/game engines to the Pi, such as Panda3D. It has Python and C bindings and already supports OGLES2, but, was designed for systems with much more RAM and CPU power than the Pi, so, I'm teasing it apart to see what can be fit into the meager Pi CPU and RAM with no more than 192 MB of CPU RAM (i.e., the 64 MB GPU configuration), as that's the CPU RAM maximum where the GPU can still produce 1080p (i.e., the 32 MB GPU option can't support 1080p).
At the same time, I'm working directly with OGLES2 in C using EGL as in the hello_triangle.c rotating texture-mapped cube demo in the Debian armel release, as well as the shader program object based approach demonstrated in the Munshi/Ginsburg/Schreiner OpenGL ES 2.0 Programming Guide examples (Chapters 2, 8, 9, 10, 11, 13, and 15) as ported in http://benosteen.wordpress.com/2012/04/ ... -x-windows . BTW, his GL Shader Language (GLSL) sandbox script that can execute the examples in http://glsl.heroku.com .
The CPU RAM constraint in the Pi is a real bugger, and I'm having to watch memory usage on a continuing basis. I hope to eventually get to the point where the Pi can be run on a 128 MB / 128 MB CPU/GPU RAM split, where as much is done in the GPU as possible. That has the potential to minimize/eliminate armhf dependency since the GPU can perform floating-point computations in hardware in parallel in ways that don't require interaction with the CPU for many cycles.
I don't know specific numbers in performance enhancement as I don't know what the upper limits are in what the GPU can do simultaneously, as well as the tradeoffs between setup time prepping the GPU with data vs. execution time. Obviously, the more asymmetry that can be achieved (data I/O is small relative to computation achieved), the better. This is analogous to how high-performance computations (aka supercomputing) are performed in massively-parallel systems, particularly those that use large numbers of GPUs (e.g., the Tianjin Chinese TOP500 record-breaking configurations of a couple of years ago, which have recently been eclipsed by higher-density multi-core IBM Sequoia and Fujitsu K systems).
In any case, I'm having fun resharpening my teeth, as I've been away from OGL for a while. I date back to the 1986 Original Flavor Silicon Graphics proprietary GL that formed the basis for OpenGL much later. We were thrilled to have 30,000 Gouraud-shaded polygons/second on $50,000 workstations (yes, each) and when hidden-surface removal was added into SGI's hardware Geometry Pipeline (R), we could barely contain our excitement. 40,000,000 Gouraud-shaded polygons/second on a $35 Pi is almost too much to contemplate, not to mention the huge expansion of the OGLES2 APIs over the early GL subset. It is great to have GLSL available in OGLES2, though, as it's a core portion of the full OpenGL standard used on the highest-end hardware. Being able to get such performance on a $25 board when the Model A arrives will probably cause me to faint!
