[sldev] Porting SL to a new platform

[Gareth Nelson]

Going back on list :)

The proxy you mention was my initial idea, and one that could be
hacked up in about an hour or two for an IM-only client. I decided not
to go this route because it makes things rather more tricky to get
going - the idea is you should be able to login to SL from any public
wifi hotspot without needing another machine with you to run the proxy
and not everyone who'd be interested in this code would be able to
host the proxy 24/7 if away from home/office.

Prebaking sims on the proxy would be a great idea for a less
lightweight setup, but has all the problems i've just described above
when you bring proxies into the mix.

I suppose the question here is how much time can the user afford to
waste waiting for the sim to load at login while the client builds a
BSP map and is it an unreasonably long time.

On Sat, Jan 3, 2009 at 12:05 AM, Soft <soft at lindenlab.com> wrote:
> I don't know if you meant to reply off list. Going back on list with
> this is fine if you want.
>
> afaik, all MIPS processors have a separate core for floating point.
> The MIPS supports four total cores. Typically, the MMU and floating
> point units hang off these, and then it's a useful interconnect point
> for GPUs, etc. I think at least one of the VUs in the PS2 is hung
> here.
>
> SL already has optimization similar to what you speak of, so long as
> the scene isn't changing. The scene thrashing comes from the interest
> list letting objects in pretty much every frame. If you can think of a
> scene management approach that's more efficient with bulk insertion an
> removal, maybe there would be a win in storing the full update packets
> for sections, and then inserting them in batch.
>
> Well-designed open map games benefit hugely from prebaked map areas.
> Typically they're even pre-sorted to minimize texture and render
> pipeline thrashing, and there's zero memory management overhead as
> it's allocated and freed as a single block, with shared library-style
> address fixups for all the internal data structures. Maybe the optimal
> solution even sees a hosted proxy layer that delivers sections of a
> sim in this fashion. It would sure inflate the project, but if you got
> that working it would be worth a lot to mobile companies wanting to
> deliver SL, etc on iPhones, netbooks, tablets, etc.
>
> On Fri, Jan 2, 2009 at 5:48 PM, Gareth Nelson <gareth at garethnelson.com> wrote:
>> Considering this it would perhaps be a better idea to start from
>> scratch then, or at least scrapping the SL rendering engine.
>> I'll have a go at compiling a simple test app using llmessage alone
>> and try to bounce some IMs, see how much CPU load it uses and then if
>> reasonable bring in a 3D engine
>>
>> As to codewarrior, i'm using the standard GNU binutils and gcc. To my
>> knowledge, code warrior is only available to licensed Sony developers
>> and the license costs quite a hefty amount ($100K roughly). By the
>> way, floating point operations are not handled by the MIPS core on the
>> PSP but on another specialist chip. Some retail games render some
>> fairly huge environments smoothly using this platform - obviously with
>> heavy optimisation.
>> One game that's inspirational in this regard is Silent Hill Origins.
>> Earlier titles in the SH series used to load bits of the environment
>> just before you reached them (the famous fog effect is rumoured to
>> have been introduced to hide this). Origins loads the whole area (in
>> something about the size of 4 SL sims) and uses a cloud-based fog for
>> atmosphere. The environment is of course likely pre-optimised with a
>> ready-made BSP tree, but there might perhaps be a way to optimize at
>> least static prims in an SL the same way.
>>
>> On 1/2/09, Soft <soft at lindenlab.com> wrote:
>>> 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.
>>>
>>
>>
>> --
>> Please avoid sending me Word or PowerPoint attachments.
>> See http://www.gnu.org/philosophy/no-word-attachments.html
>>
>



-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html