GP2X Vincent On Gp2x

[hmw]

So here is a first build of the little dodge demo of Vincent for GP2X, you can download it here. Usual procedure, unzip, copy to root folder of an SD, launch as game.

What is Vincent?

Vincent is a OSS project working on an implementation of the OpenGL ES 1.1 API for mobile devices. More information on this API can be found on the Khronos web site. The library is actually feature complete, so the major focus at this point is ports to new platforms, performance improvements. The library is using a small JIT to compile certain parts of the rasterizer on the fly. This code generator might also be useful for other hacks.

A couple of things to note:

• 1. Yes, it's upside down; I haven't changed slygamer's surface/egl classes yet. On other platforms, there is ususally a coordinate transform as part of the blit. Alternatively, the surface class for GP2X could accommodate flipping the y-axis.
• 2. It's using the JIT, and I still need to find a good solution for the cache flushing, resp. see if there is not already a suitable function in the kernel.
• 3. Speed: I'm not too thrilled yet; have seen better on 200MHz ARM. The new rasterizer should take improve things a bit. For some discussion and some numbers, see here.
• 4. Some visual artifacts: I turned some parameters lower than for a "conformance" build, but behavior should be comparable to, say, Klimt. Changing the rasterizer to the plane based approach should yield a better performance/quality trade-off.
• 5. Slygamer is using some code which I am not sure is compatible with the current license of Vincent. For the official version, I will proably base the surface on SDL. If folks are wokring on accelerated blitting etc. for SDL, this could be directly benefitted from. Comments? I checked the VS 2005 projects etc. into source forge, though.
• 6. I saw discussion about creating a pipeline that runs on the 940. My suggestion would be an approach where the geometry and light is executed on the 920, and the 940 is doing rasterization only. Main reason for this proposal is the smaller cache size. Anyone having any thoughts on this?

Cheers,
HM

PS: Thanks to slygamer for providing first versions of egl and surface. Besides those pieces and changes to the configuration headers, there was actually really not much to do to get things going on gcc; looks like you started of a source tree before the gcc support got merged down into the HEAD.

 

[Claym99]

is the spinning car a loading screen or is that what this is? explanation?

 

[slygamer]

The spinning car is the demo. It's just to prove that the OpenGL-ES code works.

hmw, I based it on rlyeh's Minimal Library, but if you want to change it to SDL, that should not be difficult. I've never used SDL, nor intend to, which is why I used rlyeh's lib. paeryn's hardware-accelerated version of SDL would probably not benefit Vincent much though since the hardware blitter is basically a fast version of the Windows BitBlt routines.

I used the most recently available distribution of the source at the time I started the port, so I'm not surprised if I missed the GCC compatibility merge.

My thoughts on usage of the dual CPUs goes along the lines of how the PS2 works. The main CPU fills up a drawlist with the basic drawing commands and this drawlist gets passed to the 2nd CPU for rasterizing. Example: If drawing a triangle, you would push a tag that identifies the following data as that for a textured triangle into the drawlist, followed by the local-to-world matrix, a pointer to the texture, a vertex count, followed by each vertex which combines position, colour (after lighting pass) and uv coordinates. This drawlist is then passed to the 2nd CPU which reads the tag, sees the following data is for a textured triangle, reads the data and rasterizes it accordingly. While this triangle is being rasterized, the main CPU is filling up another drawlist with the next frame of data. The two drawlists are then swapped and the process starts again.

 

[timbobsteve]

Congrats, haven't got my 2X to test it ATM, but I will... you can bet on that. This is awsome. Now to learn 3D math so i can start some developing hehehehehe

 

[sand_man]

Impressive. I hope it this opens things up for ports.
Here is a screenshot.

 

[yaustar]

How many Polygons is the car model and what framerates are you guys getting out of interest?

 

[Muncher666]

I don't know how to bring up the framerate, but the movement of the car, albeit slow (I'm not sure if this is an intentional thing of the vincent demo or not) is very smooth. It certainly looks better than say PSX 3d or 1999 video accelerators quality.

Allan

 

[hmw]

How many Polygons is the car model and what framerates are you guys getting out of interest?

Actually I don't know myself yet... Does anyone have a fps code snippet that I could throw in? Otherwise I'll wait until I have the SDL adaptation. The car is 732 polys (non-striped), and on another 200 MHz ARM (also a StrongARM derivative) it runs at 25 fps. Right now, the GP2X *looks* like running at a way lower rate, and I am in the middle of looking into that resp. rewriting the rasterizer [the new rasterizer is more compact, and I suspect the current code with all its inlining exceeding the instruction cache]. Anyway, it's work in progress, any help is appreciated , and I'll keep you guys posted.

- HM

 

[slygamer]

I was getting about 10fps on my port.

This some simple code using rlyeh's minilib assuming that the timer rate has been set to 1000.

unsigned long timerRate = 1000;
unsigned long frames = 0;
unsigned long fps = 0;
unsigned long timeStart = gp2x_timer_read();

while (running)
{
  // Do update
  // ...
  // Do draw
  // ...
  // Calculate fps
  ++frames;
  unsigned long timeCurrent = gp2x_timer_read();
  if (timeCurrent - timeStart >= timerRate)
  {
    fps = frames;
    timeStart = timeCurrent;
    frames = 0;
  }
}

 

[hmw]

My thoughts on usage of the dual CPUs goes along the lines of how the PS2 works. The main CPU fills up a drawlist with the basic drawing commands and this drawlist gets passed to the 2nd CPU for rasterizing. Example: If drawing a triangle, you would push a tag that identifies the following data as that for a textured triangle into the drawlist, followed by the local-to-world matrix, a pointer to the texture, a vertex count, followed by each vertex which combines position, colour (after lighting pass) and uv coordinates. This drawlist is then passed to the 2nd CPU which reads the tag, sees the following data is for a textured triangle, reads the data and rasterizes it accordingly. While this triangle is being rasterized, the main CPU is filling up another drawlist with the next frame of data. The two drawlists are then swapped and the process starts again.

Yes, that's about what I thought; with all operations being batched through DrawArrays/DrawElements it's even possible to simplify the commands down to either configuring the rasterizer to point, sprite, line or triangle rasterization (incl. textures), and sending over queue entries of point, line or triangle vertices for rasterization. It's actually almost the interface that's already implemented for the Rasterizer and RasterizerState (which captures the settings).

- HM

 

[hmw]

This some simple code using rlyeh's minilib assuming that the timer rate has been set to 1000.

Thanks, but how do you *display* the timings? You might remember that the original code for Win Mobile even shows the timings for clearing the screen, swapping the buffers and actual rendering time per frame...

- HM

 

[slygamer]

I'd created my own simple font routine that writes directly to the frame buffer.

 

[hmw]

How many Polygons is the car model and what framerates are you guys getting out of interest?

​

Between 15 and 18 fps at 732 triangles per frame. As said, I will post an update once I am through with the improved rasterizer.

As I understand, gp2x_video_flip is pretty much exactly what eglSwapBuffers is supposed to do. So a little could be shaved off (memcpy of the EGL surface) by using the framebuffer pointers maintained by minimal.c as render target; my guestimate is around 5ms per frame.

- HM

 

[Dingo_aus]

Just tried it out, very very nice. GW

 

[Anhaedra]

Any progress with this?

 

[Dingo_aus]

Don't suppose the actual GP2X source code exists on the net does it? Any links?

 

[Anhaedra]

Do you mean the kernel source code? If so, it's on gp2x.de under the firmware section.

 

[rokdcasbah]

i think he means the source of the vincent port. not sure though.

 

[hmw]

Any progress with this?

​

Yes, the new rasterizer is coming along very nicely, and both performance as well as memory footprint are improving substantially. I am currently debugging the non-JIT version, and hope to get the new JIT version hooked up over the next 2 weeks. I expect to post an updated version (incl. support for GP2X) around GDC. That's probably also going to be the point where others can comfortably join in to help improve things even further on the GP2X.

Other than, since my initial post the library went through the full conformance procedure (on a different device, of course) and is now listed as conformant product.

- HM

 

[Hanz™]

Any progress with this?

​

Yes, the new rasterizer is coming along very nicely, and both performance as well as memory footprint are improving substantially. [snip]

​

Brilliant news.