[sldev] Porting SL to a new platform

Soft soft at lindenlab.com
Fri Jan 2 13:59:00 PST 2009


On Fri, Jan 2, 2009 at 1:06 PM, Gareth Nelson <gareth at garethnelson.com> wrote:
> I've recently discovered the joy of games console development via the
> sony PSP (Playstation Portable) and have been pondering an SL port for
> it.
> Would it be sensible to even attempt a straight port or would I be
> better off writing a new client from scratch?

Not only is the GPU underpowered*, but you have to write some very
tailored assembly and lay your data out really intelligently to get
even reasonable throughput. For the CPU, the cache size and
architecture are very poorly suited to willy nilly scattered data
structure and virtual function use. It's also famously slow at the
floating point operations that SL thrives on. If you're using
Codewarrior, that's even another mark against. It's an excellent tool
for people writing code with game systems and embedded code in mind,
but it's much less forgiving of the ease-of-coding inefficiencies than
MS and GNU compilers are designed to hide.

Before spending too much time on that, I'd grab a 266MHz Pentium class
machine, disable the L2 cache, and throw in a low-end card like a
Geforce MX. See if you can get a usable amount of performance with our
code by turning off textures, etc.

That said... it would be awesome if you got this working, and "Nothing
will ever be attempted, if all possible objections must first be
overcome." -- Samuel Johnson


* Console mfr GPU stats are about as useful as determining a car's top
speed by seeing how fast a separate machine can spin an axle without
the burden of having a car attached. No console mfr pushes stats based
on a real world pipeline. They also push stats without as much worry
about John Q. Public loading up a benchmark and doing a little fact
checking. The typical "benchmark" is the result of continuously
resubmitting whatever can be done without having to repopulate the
texture cache or bring new geometry out of core - the CPU may even be
halted to keep it off the bus. In the real world, games use more
textures and geometry than fit in the cache, the CPU stays active, and
devs borrow the GPU to do SIMD work when the CPU sucks at it. That
borrowing would have to happen a lot with the SL code base.


More information about the SLDev mailing list