A rather ambitious idea; SL OS?

One of the problems with alot of software is that is doesn't communicate with the processor efficiently enough, the leads to problem with a variety of software that has to use middleware to communicate with the processor. Specifically SL's case alot of data requiring alot of bandwidth and alot of power to render/execute it. You get the best results for software if the software runs independently on the hardware, if the software is streamed line correctly, bandwidth and render requirments are reduced. The only thing better than that is to design hardware and software from the ground up together, but that is beyond the abillity of LL. I think that LL should seriously consider this approach. I understand it is rather ambitious and would take alot of work designing an OS, or even manipulating an exsisiting opensource one so that it serves as a SL client. I feel even with the amount of work involved, if would be worth the wait, and defiantly revolutionize SL, SL like software and MMORPGs. Of course the client that is OS dependent would still be necessary to keep around.

i dont see the point

someone uploads a 100mb of textures to sl for their sim
you come by and see it
your still downloading the same information
your video card still has to render the same data

doesnt matter if your on mac windows linux or whatever

Not all PC's are identical. The OS has drivers for various parts of the PC and gives application programs a common interface. That would take a lot of work to repeat just for SL. Also, manufacturers of cards and motherboards write the drivers for the OS; they have the info, we don't.

Nah


What I want to see, is SL OS... Except actually an OS, a real full featured OS where your computer IS a sim, and your files items in the sim.

The main issue with SL's performance is that it isn't properly multi-threaded, rendering a scene is forced to wait for textures to be decoded, rather than simply rendering in one thread with the data available, and decoding in another in the background. The result is that a lot of performance is lost invisibly to things you don't realise are happening, Level Of Detail calculations and Occlusion Culling, if they aren't threaded yet should be, as the actual calculation that has to be done for those features to have an effect can be intensive as well, and actually reduce performance if a scene is waiting for LOD or OC to finish before it renders.

Network bandwidth as well, when SL for me is running at a low frame-rate, packet-loss seems to go up, so because SL is rendering inefficiently I can't connect to the simulators properly. At the same time the reverse is also true, packet-loss reduces rendering efficiency as you lose data that is to be rendered, forcing waits.

SL doesn't really need anything revolutionary, it just needs the code we have now to be separated out a bit and run as individual threads that won't interfere with one another. The result is two main threads, rendering (drawing what we have) and download (retrieving and decoding stuff we don't have), with separate threads for other less constant things, such as upload (sending client commands such as movement) and things like level of detail and occlusion culling which scenes don't HAVE to wait on, but will benefit from once they are completed.

Still a mammoth task, but they did tell us when the client was open-sourced that it was being done, but all we've seen is "Use multiple threads" in the Rendering debug menu, but it doesn't really do much of anything.

I made a JIRA proposal about it here: https://jira.secondlife.com/browse/VWR-1135

Actually if SL was an OS (a well made one anyway) it could be set up in such away where it used compression for much of the data, the problem is that compression takes longer to process than raw data, but raw data takes up more bandwidth. If your operating system is optimized to display compressed data so that it uses a smaller portion of the processing power, you could potentially set up a system where everything was in a compressed format, in SL's case the terrain, avatars, textures, sounds, everything was compressed to a point where it could use less bandwidth, but without having to sacrifice processing power. So it actually would matter if SL was an OS or not, just because you see the same data doesn't mean the way it is the same. In other words, that 100mb, could be cut back to say 70mb, and loaded as fast or faster then a raw tga image file. Can you imagine that bandwidth requirements if the needed bandwidth was cut back by 30%?

Urm, turning SL into an OS doesn't change anything, whether it's a program or an operating system the implications of downloading compressed vs uncompressed data are the same. Currently SL stores textures as JPEG-2000 (an updated form of JPEG which can download progressively, ie you received first a low-res version of the image, then an extra layer of detail, then another and another).

Primitives are all compressed, to about 1kb each, where they're typically around 4kb.

One of the main reasons the SL client can end up performing so poorly is because of decompressing textures causing it to wait till they're finished.


I'm not sure what turning it into an OS over a regular program does, an Operating System is just a very big program, or suite of programs which encompasses all of the base tasks of your computer, such as communicating with hardware (drivers) and the basics of the user-interface. Coding all of that when it's already been done would be a nightmare, only to result in a game which in order to run it you have to restart your machine into "Second Life OS". We have driver issues enough when the driver handling is left mostly to Windows/Linux/Mac OS!

I think that ultimately there isn't much gain from access to 'raw' hardware speed, modern Operating Systems may add overhead, but most do this in order to ensure that programs are being given fair shares of processor time, and aren't stealing each other's memory, and so-on. SL doesn't need MORE processor time, faster machines still struggle with SL, SL needs to better use the processor time it has by spending less of it waiting on various parts within it.

ditto

What a marvellous opportunity for the open source community...

Thing is, these days the hardware is built to the OS anyway. Cards good for OpenGL rendering (where OpenGL is effectively "the OS" for SL) are already out there.