GP2X Gpu940...how To Start, And Compiling For Pc

[xhyldazhk]

Very interesting thread...

I've followed it.

I must say... OpenGL ES was specifically designed for embedded devices, so I would rather target OGL-ES than OGL. OGL-ES is more targeted at realtime applications (like games) than general rendering (like OGL).

Realtime antialiasing IS possible. Look at Payback. It even has a form of HDRI lighting.

 

[rixed]

I must say... OpenGL ES was specifically designed for embedded devices, so I would rather target OGL-ES than OGL. OGL-ES is more targeted at realtime applications (like games) than general rendering (like OGL).

Right, but there are almost no apps available for GL-ES to play with, so ...

Realtime antialiasing IS possible. Look at Payback. It even has a form of HDRI lighting.

It certainly is. For the moment gpu940 rendering can be improved in so many ways that antialiasing is not on the TODO list yet.

 

[PokeParadox]

:lol: stupid, stupid, stupid thought that made me laugh... PS3 games are programmed in GL_ES... any chance of a port for

Rixed, I did manage to play Egoboo before my 2X crapped up on me, and I think it's an impressive library you have going here. Keep up the good work.

 

[lapoubelle]

This is a little off topic, but why does Descent get such good performance on the GP2x? It doesn't even use hardware acceleration, right?

 

[rixed]

This is a little off topic, but why does Descent get such good performance on the GP2x?

You can draw the whole screen 100 times a second, so, in theory, anything like descent (that does not require massive CPU for computing things, like decoding an ogg to play music) can have a very good framerate.

It doesn't even use hardware acceleration, right?

What hardware acceleration could it use ??

 

[lapoubelle]

Well, accelleration period i guess. I haven't read too far into gpu940, but I assumed it provided some sort of accelleration. I was mostly curious how an old but fully 3d game like descent can have such a high framerate on the gp2x while other 3d games seriously lag. Is it just a matter of very few polygons on screen at once?

 

[PokeParadox]

The descent games were ported directly. That means the engine was (I think converted to ARM ASM and) stripped of features that would slow the renderring. Also as you mentioned the Descent games a quite low poly.

It's the difference with getting a specific game up to speed and a general purpose graphics library. That's how I see it anyway.

 

[STTrife]

Descent doesn't use much polygons, levels are made of big walls

two questions: can I load textures into video memory (and how, and would this speed up things) ?

Is it usefull to do the mmu-hack?

 

[rixed]

two questions: can I load textures into video memory (and how, and would this speed up things) ?

There is no such thing as a "video memory" on the GP2X. With gpu940, almost all the upper 32Mb can serve the purpose of the video memory (as the video controler can be said to display any memory area).

To use a texture with gpu940, you just copy your bitmap in the shared memory buffers and tell gpu940 the address of this buffer and that it holds a texture. When you no longer need the texture, you can reuse this memory (for another texture, a zbuffer, or a frame buffer).

With the helper library, you have a memory allocator that handle these buffers for you.

With OpenGL, you just use glTexImage2D() and/or glTexSubImage2D() that takes care of everything (as long as there is enough room for all the textures). The data you give to these functions are copied to the upper mem where it can be used by gpu940 (plus it convert the pixels to 32bits YUV colors).

Is it usefull to do the mmu-hack?

If I followed correctly, the mmu-hack is a way to have Linux cache the upper 32Mb ?
If so, it won't help much, because Linux programs do not really read/write with the upper mem with gpu940. And when they do, they expect to have the memory uncached (buffer command), so I think using this trick would rather leads to some complex bugs.

 

[STTrife]

I see, thanks. Then I assume I can free the memory allocated with malloc after I called the glTexImage2D() ???

And how much memory can the gpu940 handle for textures? and how do I know when it's full?

 

[rixed]

I see, thanks. Then I assume I can free the memory allocated with malloc after I called the glTexImage2D() ???

Yes. for example, if you load a bitmap from a file in a malloced buffer and then call glTexImage2D(), you can free the buffer : texture was copied before the glTexImage2D returns.
This behavior is required by GL, anyway.

And how much memory can the gpu940 handle for textures? and how do I know when it's full?

You have approx 30MB for everything. With GL, you have 3 frame buffers (and 3 additionnal zbuffers if you enabled them). This eats max 3Mb. That's 27Mb left for textures.

You will know when it's full because... Well, I don't know. Let me look at the code.

	  to->img_res = gpuAlloc(to->mipmaps[0].width_log, 1U<<to->mipmaps[0].height_log, false);
	  if (! to->img_res) return gli_set_error(GL_OUT_OF_MEMORY);

So :

1) you will have this nice GL error (GL_OUT_OF_MEMORY)
2) the rendered primitive will be all wrong (now that I think about it, the primitive should probably not be rendered in this case... :-/)

 

[rixed]

But I'm getting only 50fps on gpugears on my athlon64 3400... :blink:

Now that I think about it : on PC, the vertical IRQ of the GP2X is simulated with a timer, which is set to 50 Hz...

To know how fast the engine can render the gears, you should disable the timer and call vertical_interrupt directly, in bin/gpu940.c (the call is commented out, and there is a #if 1 before the timer initialization that could be turned to a #if 0).



Once this is done, I get approx 200fps on a P4 @ 3GHz.

 

[STTrife]

Are you guys still actively working on the gpu940? Do you have something like a changelog, and a list of features/changes/improvements that you are working on (or going to work on very soon)?

Would be nice also is it normal to get white-line-artifacts? In my demo with a textured model that rotates, you can see white lines in the legs sometimes(on the edge of long triangles I think). I tried cropping the texture-coordinates of the legs further into the 'pants' part of the texture (because I thought it might have something to do with inaccurate texture-coordinate-calculations or so) , but still get those white lines. Any ideas?

 

[rixed]

Are you guys still actively working on the gpu940? Do you have something like a changelog, and a list of features/changes/improvements that you are working on (or going to work on very soon)?

Yes it's still worked on. For example Ive a patchset waiting to be commited, that will improve polygon rasterized speed by aprox 30% (at least that's the result on PC - I did not test it on the GP2X so I can't commit now).

There is a changelog in the sourcetree :

http://cvs.gna.org/cvsweb/gpu940/ChangeLog?cvsroot=gpu940

But it'n not very detailed.

Also you can still use CVS tools to see what's done when.

also is it normal to get white-line-artifacts?

Don't you like it ?

In my demo with a textured model that rotates, you can see white lines in the legs sometimes(on the edge of long triangles I think). I tried cropping the texture-coordinates of the legs further into the 'pants' part of the texture (because I thought it might have something to do with inaccurate texture-coordinate-calculations or so) , but still get those white lines. Any ideas?

As you said, looks like inaccuracies in computation of texture coordinates. Are these lines more vertical or horizontal ?
Im looking for a bug that could be the same as this one if the white-lines were almost horizontal.

If not, well, another one.

 

[STTrife]

horizontal? nope the edges on the texture where the problem occur are vertical. hope you can fix that soon, if the model+texture I used would help you find the problem, let me know and I'll send them your way.

 

[rixed]

horizontal? nope the edges on the texture where the problem occur are vertical. hope you can fix that soon, if the model+texture I used would help you find the problem, let me know and I'll send them your way.

Please first tell me if it's still occuring with the latest gpu940 that's available in binary form here :

http://download.gna.org/gpu940/

 

[STTrife]

no doesn't help (egoboo looks very cool now though, good work!).

I even moved the texture coordinates further 'inside' (about 10 pixels away from the edge in the texture), but there still are white lines on some edges of the model when I show it on the gpu940 (not every frame though, and no always in the same places)

 

[efegea]

I've updated the cvs and now I'm getting this (on the PC):



Is there any way to turn off all of this debug info?

There is another problem, the textured cube on the background doesn't rotate. It's like it's trying to rotate but it can't..I can explain it better :unsure:

Of course the same code did work on previous version of gpu940. And also it was much more illuminated

EDIT: oh, and why my code doesn't compile with g++? It does compile with gcc but with g++ I got a lot of undefined references to al gl* functions. I need to use g++ because what I'm going to code is c++

 

[STTrife]

perhaps it doesn't rotate well because the glRotate changed from radians to degrees (radians go from 0 to 2pi, degrees from 0 to 360). So try increasing the rotationspeed.

If you compile with g++ you should include the gl header files with extern "C" or else the linker can't find it.

 

[PokeParadox]

Ah.. this may be where I'm going wrong.

I'm trying to get the basic GPUGears to compile as a test... but I can't evenget that going... This is the commandline I'm using:


arm-linux-g++ gpugears.c -static -lpthread -lm -I /include/GL -msoft-float
del *.gpe
ren *.out gears.gpe
pause