My Atempt For A Gp2x Friendly Opengl Implementation


rixed

Member
Joined
Dec 31, 2005
Messages
206
Age
48
Location
Paris (fr)
Website
happyleptic.org
Im still working on my software renderer gpu940 (that I used for the 'code alone' little demo).

Lately, I was adding a GL-ES API to ease the use of the renderer.

So far, I've just ported glxgears, which is not a very good example because of its waste of
ressources (well, the purpose of glxgears is only to benchmark GL implementations).

Anyway, with proper overclocking it runs at 20 fps fullscreen with clipping and zbuffer, which is
twice as much as previous atempts based on vincent-gl and tinyGL, IIRC.

Some part of the renderer can still be optimized, so that I think it's possible to actually use
it for well-optimized GL apps (well optimized means : no over-usage of zbuffer and low-poly models).
And the 920 CPU is free to run anything else (the GL-ES layer runs on the 920, and performs only 3d
transformations and API convertion to the GPU, which then performs all clipping, projections and rendering).

With recent optimizations, the code-alone demo now runs at approx 50fps.

This is definitivelly false to state that the 940 can not handle rendering because of low RAM bandwidth.
[cut]
I am so happy I felt I had to share these news :)

Roadmap for future weeks :
- fix and optimize GL API lighting computations ;
- add textures to the GL API ;
- try to port a little game to see how far we can get ;

After that, probably design a dedicated 3d game for the GP2X, but this is another story.

--
link to gpu940 : http://gna.org/projects/gpu940/[/cut]
 
very cool. you were at the very least among the first to get the 940 to do anything usefull with your clever code alone demo that I enjoyed. now more people seem to be finding use for the 940 which should lead the way for more powerful programs and games that some people thought possible.

good luck with this. how intensive is that gears demo? in your renderer's current state do you think it could help run fairly basic (early psx type) 3d games at a good speed?
 
Good job, but isn't that framerate pretty low considering the polygon count? I recall GLXgears ran at hundred of FPS on very slow CPUs in software rendering-- although this might have something to do with the powerful floating point capabilities of those slower CPUs. Is the 940T the ONLY chip involved in the rendering job?
 
ER, I only get 400fps with glxgears on my 1.6ghz pc with a stupid SIS video card on linux.
So 20fps on 266mhz seems great to me.
 
I think http://www.gp32x.de/cgi-bin/cfiles.cgi?0,0,0,0,27,223 would be a good testing candidate in case you can reach the author and get the source, its a recreation of mgs: vr missions for gp32 and used vincent for opengl, it was very slow, but i guess with you implementation it could run pretty decent.

Ok, thank you for the link ; I will try to reach the author for source-code.

Something written for the gp32 should run OK onto the gp2x, whatever the 3d renderer I guess, but
I'd rather start with something that works to prove it usefull, instead of something that's more graphicaly
impressive but that's also so slow as to not be playable.
 
Last edited by a moderator:
Good job, but isn't that framerate pretty low considering the polygon count? I recall GLXgears ran at hundred of FPS on very slow CPUs in software rendering-- although this might have something to do with the powerful floating point capabilities of those slower CPUs. Is the 940T the ONLY chip involved in the rendering job?
haha, usaly yes, as long as you don't have a ati card and get the famous 50fpsonglxgears bug.

but considering that the gp2x doesn't even have a fpu, take out advanced math functions its a pretty good result, rixed did good work so far :)
 
Last edited by a moderator:
What license is this released under? The project page just says "GPL Compatible".

Great work on this, excited to see what this can do...
 
Good job, but isn't that framerate pretty low considering the polygon count? I recall GLXgears ran at hundred of FPS on very slow CPUs in software rendering-- although this might have something to do with the powerful floating point capabilities of those slower CPUs.

It should be another glxgears then, because on my little 800MHz PC with software rendering, I only get around 100fps from
the pristine glxgears.

glxgears is approx 500 quads. This is not much, yet the 940 still uses more than 40% of its time in the polygon drawer function (which does not include the 'draw a raster' function. This is mainly due to the fact that this complex function handles all cases, including true perspective although this is not necessary here. So this is still very well optimizable, and I expect a fps boost of
about 15 to 20% in a few days.

More if other people help me :)

Perf measurment (on the 940) can be o interrest to you. Here are the rough figures :

clipping+projections -> 15%
polygon "computations" -> 40%
drawing polygons -> 15%
clear pixels and depth buffers -> 3%
all divisions -> 15%

Is the 940T the ONLY chip involved in the rendering job?

Like I said, only clipping, projection and rasterization are done on the 940.
3d rotations and obviously also the opengl API are done on the 920.

I like this way of splitting the task : it's not very demanding on the 920, and you have 3d coordinates at hand if you need them in the game (and usualy you do need them).



good luck with this. how intensive is that gears demo? in your renderer's current state do you think it could help run fairly basic (early psx type) 3d games at a good speed?

The gears demo is not intensive compared to usual 3d apps, but it is intensive compared to what it looks like :)

I don't think many things could be ported, though - especially many things that were designed to use a hardware
accelerated renderer.

Having said that, perhaps it will be nonetheless usefull for gp2x homebrew ?


What license is this released under? The project page just says "GPL Compatible".

Actually that's GPLv2.
Usualy this is stated as "GPL v2 or any later version at you option", but I don't like this phrasing so
it's simply GPLv2. The fun part of the story is that because of this, a similar project was refused by
savannah.gnu.org because they juged this not compatible enought with the GPL :)
 
Last edited by a moderator:
this is awesome, though of course i understand it won't run games that need good graphics cards, there are a lot of games i have seen that need open_gl, but probly could have been coded to run without it. Understand that i don't understand any of this at all but i just have seen project pages for linux games that don't look very graphically intensive yet still need open_gl as well as sdl that seem like there would be no reason they couldn't be ported. This probly makes no sense, but thanks anyway because anything that will advance gp2x homebrew is great.
 
ER, I only get 400fps with glxgears on my 1.6ghz pc with a stupid SIS video card on linux.
So 20fps on 266mhz seems great to me.
Yeah, 1.6ghz pc has 400fps because of FPU, which is well performing on latest CPU generations. So 20fps on handheld WITHOUT a FPU using only one core is awesome... I think that GP2X is very capable platform..

(remember QUAKE that won't run on PCs without FPU?? QUAKE on gp2x runs wery vell, and a lot can be done with pushing hardware to the max - remember QUAKE2 on PSX?? technically masterpiece)
 
Last edited by a moderator:
I don't think many things could be ported, though - especially many things that were designed to use a hardware
accelerated renderer.

Having said that, perhaps it will be nonetheless usefull for gp2x homebrew ?

So after you get it ported correctly are you releasing the libs for the gp2x because there are a lot of 3d homebrew projects that I would love to do with low polymodels for the gp2x just look at characters like Mario 64 the main character mario is super low polygons I am sure I could get away with 4 or 5 models like that and a simple background.

Keep up the great work I look forward to this lib.
 
ER, I only get 400fps with glxgears on my 1.6ghz pc with a stupid SIS video card on linux.
So 20fps on 266mhz seems great to me.
Yeah, 1.6ghz pc has 400fps because of FPU, which is well performing on latest CPU generations. So 20fps on handheld WITHOUT a FPU using only one core is awesome... I think that GP2X is very capable platform..

(remember QUAKE that won't run on PCs without FPU?? QUAKE on gp2x runs wery vell, and a lot can be done with pushing hardware to the max - remember QUAKE2 on PSX?? technically masterpiece)
It's using 2 cores, just for different tasks. Also, Quake would run without an FPU. It was just much slower because the engine and game rules are almost entirely floating point. As for the Quake 2 port to the PSX, they pretty much ruined it... but I guess it's sort of impressive they got it to run at all. Most of the work was done by the 3D subsystem, at a time when most PCs had very weak GPUs or just used Software rendering which was faster than some of those awful early GPUs. Quake 2 did very little actual CPU intensive math, this wasn't the day of advanced physics. :) Convert the engine/game rules code to integer math and it should run fine on a chip like the PSX's 32 MHz R3000A.
 
Last edited by a moderator:
Most awesome news in quite some time!
If you start making a 3D game make sure you contact me as I am a quite skilled modeler (I think).

Maybe the opengl version of quake could be ported with this also (or the software renderer adjusted to this gpu)? Probably a huge task, but it would free the 920t that is currently software rendering all of the game.
 
It's using 2 cores, just for different tasks. Also, Quake would run without an FPU. It was just much slower because the engine and game rules are almost entirely floating point.
Are you sure about it? I remember quake not running on 486sx, which obviously didn't have FPU (to be precise - they had but it was disabled). It doesn't required Pentium but it req'd FPU. Doom doesn't required (played on my 386sx 40mhz :) but Quake does.
According to wikipedia:
"In fact, the slow operation of Quake on most 486 processors due to their relatively weak (compared to Pentium 1's) integrated floating-point processor (486SX CPUs were not supported at all because they did not have a working FPU) pushed many people to upgrade to Pentium processors"

As for the Quake 2 port to the PSX, they pretty much ruined it... but I guess it's sort of impressive they got it to run at all.
Most of the opinions about it I spotted were very enthiusiastic, personally I haven't played Q2 a lot, but in technical way it was sort of masterpiece. eg. 4 players on the screen at once in deatmatch (similiar to turok2 on n64 but n64 was way better that psx). Imho Q2 on psx plays smoother and better than Q1 (Saturn Q1 was better)

Convert the engine/game rules code to integer math and it should run fine on a chip like the PSX's 32 MHz R3000A.
Yeah, the same goes for NGage - no dedicated 3d chip, everything goes in ARM 104mhz which lacks FPU. But it is possible to code some good looking games (ONE/Asphalt/TombRaider/Cyboid). I wonder how hard it is to convert engine from floating to integer?
 
Last edited by a moderator:
Back
Top