GP2X Tinygl Ported To Gp2x


Julius posted on Feb 7 2006 at 03:35 PM said:
Now that sparked my interest ;) Are you working with the second CPU?

Yes, I think modifying an existing implementation of OpenGL to use the second CPU will be very tricky. I have designed my version from the ground up to use the second CPU. I have a simple client library that the treats the second CPU as if it were a GPU and sends it messages to render the graphics.

It's going to be tricky to get working right, but I think the idea is sound...

Andrew
 
Last edited by a moderator:
andrew_j_w posted on Feb 7 2006 at 05:59 PM said:
Julius posted on Feb 7 2006 at 03:35 PM said:
Now that sparked my interest ;) Are you working with the second CPU?

Yes, I think modifying an existing implementation of OpenGL to use the second CPU will be very tricky. I have designed my version from the ground up to use the second CPU. I have a simple client library that the treats the second CPU as if it were a GPU and sends it messages to render the graphics.

It's going to be tricky to get working right, but I think the idea is sound...

Andrew

But what about the memory access? Perhaps it could be better to use the second cpu for really processing intensive tasks like transforms and do it in bulks (to maximize effect of cache).
 
Last edited by a moderator:
Radek posted on Feb 7 2006 at 11:59 AM said:
what about the memory access? Perhaps it could be better to use the second cpu for really processing intensive tasks like transforms and do it in bulks (to maximize effect of cache).

I'm working on Yet Another 3D Engine for my own amusement, and I'm planning on doing the transformation part of the "pipeline" on the secondary processor and then doing rasterization on the primary processor. It seemed like a reasonable approach, i guess we'll see how much it actually helps.

When you say "what about the memory access?", what specifically do you mean?
 
Last edited by a moderator:
Dzz posted on Feb 7 2006 at 07:16 PM said:
Radek posted on Feb 7 2006 at 11:59 AM said:
what about the memory access? Perhaps it could be better to use the second cpu for really processing intensive tasks like transforms and do it in bulks (to maximize effect of cache).

I'm working on Yet Another 3D Engine for my own amusement, and I'm planning on doing the transformation part of the "pipeline" on the secondary processor and then doing rasterization on the primary processor. It seemed like a reasonable approach, i guess we'll see how much it actually helps.

When you say "what about the memory access?", what specifically do you mean?

I mean the effective load/store perfomance as available bandwith is finite. As the first cpu will fill the pixels so the second better not interrupt its access to memory. For the best perfomance loading a bulk into a cache would be ideal. I was experimenting with some routines (mostly 2d/colors blending/blitting) and get that doing random "ldr/str" is much slower than rendering by scanlines (via "ldm/stm") so intermediate results fit in the cache.

But it will depends what the rasterizer will be doing. For simple polygons filled with just color it'd important but for textured surfaces (as they will be mostly limited by available cpu cycles) far less.
 
Last edited by a moderator:
Radek posted on Feb 7 2006 at 12:43 PM said:
I mean the effective load/store perfomance as available bandwith is finite. As the first cpu will fill the pixels so the second better not interrupt its access to memory. For the best perfomance loading a bulk into a cache would be ideal.

That's a good point. Lots of potential areas for efficiency gains, this stuff is fun.
 
Last edited by a moderator:
Radek posted on Feb 7 2006 at 04:59 PM said:
But what about the memory access? Perhaps it could be better to use the second cpu for really processing intensive tasks like transforms and do it in bulks (to maximize effect of cache).

I have currently designed it so the second cpu does pretty much everything: it transforms and projects the vertices and renders everything to the screen. I wanted to leave us much time as possible for the primary processor to handle AI/Physics/Sound etc.

Of course there are a whole range of ways to tweak the performance, but I'm concentrating on getting things running first! Currently I do stupid things like clipping at the pixel level rather than clipping whole triangles. It might be stupid but it reduces the amount of code that can go wrong, and that's what's important at the moment :)

Andrew
 
Last edited by a moderator:
God Ginrai posted on Feb 8 2006 at 12:35 AM said:
Your GL2X, this is theoretically going to be compatible with games that use OpenGL?

That's the plan. I have glQuake compiling using my library, but not enough of the OpenGL spec is implemented for it to actually draw anything useful on the screen.

Andrew
 
Last edited by a moderator:
What kind of speed do you anticipate getting with your library, for example, do you think it would be competitive with the quake software renderer?
 
BradN posted on Feb 8 2006 at 03:28 PM said:
What kind of speed do you anticipate getting with your library, for example, do you think it would be competitive with the quake software renderer?

I really have no idea, I'll just get it running and go from there. I would expect it to be fairly fast as the software renderer only runs on a single processor, so there is bound to be some speed up. Whether the speed up will be enough to counteract the fact I'm writing a general solution rather than a heavily optimised specialist renderer I'm not sure.

@Pryankster: Sorry, I didn't mean to highjack your thread - porting something like TinyGL is definitely the way to go to get OpenGL running quickly.

Andrew
 
Last edited by a moderator:
andrew_j_w posted on Feb 8 2006 at 08:37 AM said:
@Pryankster: Sorry, I didn't mean to highjack your thread - porting something like TinyGL is definitely the way to go to get OpenGL running quickly.

Andrew

No problem, no offense taken -- I'm not just looking at TinyGL -- I've also compiled up Klimt, which looks promising (already has support for Fixed point, for example) and seems to run faster than TinyGL (though the jury's still out, and real-life has intruded on my play time with the 2X :-( )

I'd be very interested in taking a look at your library when it's in a usable state.

My plan for using 3D is in a (mostly 2D) RPG -- The characters/NPC's/Monsters will be modeled in 3d but move on a 2d backdrop, and I want the "world map" to be textured onto a sphere; but most of the game will be 2D.

-- pryankster
 
Last edited by a moderator:
Pryankster posted on Feb 9 2006 at 08:31 AM said:
andrew_j_w posted on Feb 8 2006 at 08:37 AM said:
@Pryankster: Sorry, I didn't mean to highjack your thread - porting something like TinyGL is definitely the way to go to get OpenGL running quickly.

Andrew

No problem, no offense taken -- I'm not just looking at TinyGL -- I've also compiled up Klimt, which looks promising (already has support for Fixed point, for example) and seems to run faster than TinyGL (though the jury's still out, and real-life has intruded on my play time with the 2X :-( )

I'd be very interested in taking a look at your library when it's in a usable state.

My plan for using 3D is in a (mostly 2D) RPG -- The characters/NPC's/Monsters will be modeled in 3d but move on a 2d backdrop, and I want the "world map" to be textured onto a sphere; but most of the game will be 2D.

-- pryankster

Is this going to be comerical/shareware/freeware. It sounds very interesting. I'd be in helping out maybe...
 
Last edited by a moderator:
Pryankster posted on Feb 9 2006 at 07:31 AM said:
My plan for using 3D is in a (mostly 2D) RPG -- The characters/NPC's/Monsters will be modeled in 3d but move on a 2d backdrop, and I want the "world map" to be textured onto a sphere; but most of the game will be 2D.

-- pryankster

Damn you! You've been reading my mind, because that is exactly what I was planning to do (for one of my projects anyway). :)
 
Last edited by a moderator:
Quick question on this thread: What's the current status on porting Vincent to the GP2X? Anyone had any success? I am still waiting for my GP2X to arrive, so I haven't have had a chance to get my feet wet myself... But I have started to experiment with a new rasterizer core, which should give this library an edge over the alternatives in terms of performance...

- hm

PS: Yes, I am the original author of Vincent...
 
Last edited by a moderator:
That was me who tried a port of Vincent and posted those comments. Trying to get Vincent to compile under GCC was an arduous task, compared to TinyGL that compiled almost straight off the bat. Then trying to follow the code path through Vincent was made extremely difficult by the over-use of C++ classes and templates. They do not make debugging any easier. Once I got Vincent running and spinning the Dodge on screen, the textures were screwed up, and given the complexity of the C++ code, I gave up trying to find the problem.

Sorry for the critical comments on your code, but that is my honest opinion.
 
slygamer posted on Feb 13 2006 at 12:03 AM said:
That was me who tried a port of Vincent and posted those comments. Trying to get Vincent to compile under GCC was an arduous task, compared to TinyGL that compiled almost straight off the bat. Then trying to follow the code path through Vincent was made extremely difficult by the over-use of C++ classes and templates. They do not make debugging any easier. Once I got Vincent running and spinning the Dodge on screen, the textures were screwed up, and given the complexity of the C++ code, I gave up trying to find the problem.
Well, I'll see what I get. But I am a bit surprised about your difficulties getting it compiled on GCC, because the Symbian builds use GCC, and patches of several others for various versins on Linux have suposedly been merged into the code base quite some time ago (after 0.80). But gcc also changed a lot between 2.9.x and 4.x. For the srewed up pictures, that was using the JIT, I guess? That's the part people usually have problems with when going to a new platform.

To my knowledge Vincent uses templates only for the texture format conversion in the inner loops of the image copying code to load textures, as well as for small array-of-<T> classes. It sounds that you were trying to debug the texture loading code then. Do we need to add support for different formats beyond the ones that are provided?

- HM
 
Last edited by a moderator:
Back
Top