See earlier posts, they describe how to get both ports

1. I seem to be getting pretty good performance running at the standard 222 mhz CPU speed (typically 46 FPS as reported in periodic console statements).  What is the "ultimate" UQM framerate?

222 MHz should be fine, and I certainly wouldn't release my version at 333 MHz, but was just doing that for testing.  I wanted to make sure threading issues weren't speed issues (the thread priorities should be correct in SDL now).  SDL graphics speed should also be faster than when I was working on it, as there has been a lot of work done on the GU acceleration since then.

2. While load times are definitely too long they are nowhere near the 1-2 minutes as reported in this thread.  Perhaps 0.5.0 is more efficient in how it uses content files.

Wouldn't surprise me.

3. One of the disadvantage of the cwd changes you made is that you loose some flexibility.  For example, for development I use PSPLINK and run the elf file from the host0:/ drive but content/config directories from ms0:/.

psplink and hostfs didn't exist when I wrote that code .  You still might be able to get around it differently, by e.g. mounting the directories to /ms0/ and /host0/ instead.  Or, at least, handle the "string:/path" format in such a way that the same code is used for Windows and PSP.

For our thoughts on memory and load times, just read this thread.

Slightly more stable version posted at original link with source changes included

You really should take a look at how I did things in my port.  The majority of your patch is dealing with path issues, which I fixed in a much cleaner way by just providing a modified getcwd() that returns a standard Unix-style path.  Also, I integrated the PSP as a normal cross target into the build system, rather than just providing a static build.vars.  Finally, creating a separate PSP-specific startup function as I did (src/psp/main.c) lets you easily do other initialization and keeps you from having to make PSP-specific changes to the default options in src/starcon2.c. 

If I get a chance I'll see about syncing my code with a current snapshot (some patches have already been applied upstream).

I didn't have to make any changes to the PSP SDL or newlib libraries so things seem to have improved since you did your initial work.

I committed all my fixes back in October, so yeah, they should be OK now.

Hey guys,
Sorry for being slow with this; been really busy lately.  Fortunately, most of what I did to port UQM involved writing and improving SDL and newlib in the pspsdk, so hopefully you didn't spend too much time duplicating work.  You can get my work-in-progress here via Subversion:

Code:

https://jim.sh/svn/jim/devl/playstation/psp/ports/uqm/

The last time I merged with upstream was snapshot 20060110.1200, and you can see the relatively short diffs easily enough:

Code:

svn diff https://jim.sh/svn/jim/vendor/uqm/20060110.1200 https://jim.sh/svn/jim/devl/playstation/psp/ports/uqm/

To build, just run "pspbuild.sh".  Remember to run psp-fixup-imports and strip the resulting binary before transferring to the PSP.

The rated speed for my memory stick is 15MB/sec. As you can see, the PSP hardware is quite capable of reaching that, but only with very large reads.

Hmm? The speed on the PC seems to be 127 times higher than that.

Sure, but my hard drive unfortunately can't really read 2 gigabytes per second, so that's clearly the result of having a real OS providing a buffer cache.   The PSP's kernel is basically just giving direct access to the hardware.

Ah, good. Don't forget to send in patches.

Will do.. I might have some stuff already I could give to you, I'll take a look.

What's the result if you do larger reads?

See http://psp.jim.sh/uqm/benchmark.txt.  The rated speed for my memory stick is 15MB/sec.  As you can see, the PSP hardware is quite capable of reaching that, but only with very large reads.

We really haven't done much memory profiling so far.

And rightly so, as it's really not that bad for a desktop PC to warrant wasting much time on it.  For the PSP, It looks like there are some pretty obvious killers in there (like 8 megs of SDL surfaces when you visit a planet); I think Andy is looking into those.

If I take out the seeks it's closer to 5,000 reads/sec on the PSP.

About the RAM usage, I ran UQM under valgrid's "massif" tool on Linux.  The PDF here shows memory usage versus time.  I started a new game at around 50 seconds, visited a planet at 90 seconds, and left about 10 seconds later without scanning or landing.

I ran a quick benchmark just to verify what we thought.  I create a 4 KB file, then lseek to sequential offsets within it and read 32 bytes each time.  It's measuring how many lseek/read pairs it can do per second.  On my PC it's easily 1,200,000, while the PSP does 3,000.  On a PC, just starting UQM causes at least 20,000 lseeks/reads within the content zip by the time the title screen loads.

I'm not sure if the latest pspsdk has faster stdio operations but I did get a 2-3x speed increase when switching to the sceXXX file io functions a while ago when linking newlibc.

UQM uses unbuffered functions (open, read, lseek) that are just simple wrappers in newlib to the underlying sceIo* stuff.  If you're seeing that sceIoRead() is faster than read(), it's a bug, and if you could post an example to ps2dev.org we'll fix it.

fstat() may be slower than expected because we need to emulate it with stat().

Buffered I/O (fopen, fread, fseek) may be slower for other reasons (which may or may not be fixable) but that shouldn't affect UQM.

Not true. UQM reads the central directory at startup, and it will never need to read it again.

OK, I was almost certain I had been seeing tons of back-and-forth calls to stdio_seek, but perhaps I'm misremembering.  I'll have to look at that again when I get time; I no longer have any of my logs.

Reading in short blocks however sounds like a good reason. If the OS doesn't read in pages at a time, each read would mean a new request.

As far as I am aware the OS does no buffering, so yeah, it would have to be a new request each time.

Do you have an URL to those benchmarks?  64k sounds like rather a lot to me btw.

Sure, try this.
I believe this particular test was over the USB interface, but I was told that we get similar results with code on the PSP.  I should probably test it for myself rather than just trust them I suppose.

Do you have console output? Is the delay right at the start or is it spread over all files?

I think it was spread all over.  For example: selecting my next ship in Super Melee would take 5-10 seconds to load.  I do have a console and can attach gdb to the process, although that's over a serial link and slows things down quite a bit itself.

While there shouldn't be any short (low level) reads for reading files, there are quite a lot of them when the zip file is mounted, when the central directory is read in.  I actually have a todo remark somewhere to add read-ahead buffering. I'll see if I can do that somewhere in the next few days. It shouldn't take much time.

OK, that would be interesting to try out, but take your time, I'm quite busy myself for the next few weeks 

Does the PSP have memory mapped IO btw? In that case there would be room for even more optimisation.

Nope, there's only a rudimentary hardware MMU that appears to have fixed mappings.

no seeking within compressed data is done. And seeking within a single file is a much cheaper operation than opening files. Even more so when you can do random access. And a memory stick is RAM, after all.

The zip contains a ton of tiny files.  Every time UQM tries to open or read from one, it seeks at least to the centeral zipfile directory at the end, then back to where the actual file is.  Individual files may be buffered from UQM's point of view, but it's the initial finding and getting those files out of the zipfile that appears to be taking so much time.  I agree that using non-zipped content would only be worse in that regard.

The memory stick isn't really RAM.  It's accessed serially, and more like a disk in that sequential access is faster than having to keep changing the address (from what I understand from publically available info out there).  On the PSP in particular, benchmarks show that reading in large blocks (at least 64k) is important for getting decent performance.

when using a CD-ROM, using zipped content is actually very noticably faster, because it takes less time to decompress than it would take to read the extra bytes.

But now you're talking about a system where the OS provides a generous page cache that will easily retain things like the zipfile directory, and coalesce lots of small requests into larger ones before sending them to the hardware.  The PSP OS has nothing like that, and I think that's the real source of the performance difference here.  A user-level version of a buffer cache like this is exactly what I'm proposing.

The ones provided by us have the .ogg files stored uncompressed.

I haven't touched oggs yet.  I was seeing times of something like 1-2 minutes just to get past the initial splash screen, almost entirely due to I/O.  Working on this was going to be my next goal once I have time.

Hi cooleyandy,
Glad to see someone else working on this.  I can certainly share my code with you if you'd like; no reason to duplicate effort.  Send an e-mail and I'll give you access to my svn repository.  I personally still won't have a chance to work on this until later in the month at the earliest.  Most of the work that I did was to fix up the pspsdk and SDL port, as I mentioned, so you should hopefully have found that the UQM code just works with only minor build changes.  As for RAM, I did get a crash when exploring a planet that I assumed was memory-related, but didn't explore it further.  I was hoping it was just a simple fix like removing the rotating planet animation.  One problem that I was seeing is that zipped content is preferable on the memory stick (due to small files and a large FAT cluster size), but the frequent unbuffered seeks and small reads in the zip are a killer for performance and it's very slow.  Perhaps a buffering layer would be useful, at least for the zipfile directory.

The PSP only supports single-precision floats, and libvorbis uses doubles a lot.  Also, my eventual goal would be to move the ogg decoding to the second CPU, which lacks a FPU.