Here are the symptoms: I sign on, and within minutes the SL client allocates all available RAM, the frame rate plummets, and the client crashes.
This has happened to me on several 2.x based SL clients, including some from Linden Lab. It may have also happened to others as well; see this thread in the Kirsten client forum. I seriously hope that the message from Steffi Honi in that thread is not accurate.
It makes no sense not to create a 64-bit Linux build (or a 64-bit Windows or Mac build, for that matter). It can be done; Imprudence has done it for some time. It's just about impossible to buy a computer these days that doesn't contain a 64-bit x86 flavored CPU, unless you're buying a netbook, which can barely run SL anyway, or a tablet (which probably has an ARM processor that LL doesn't target). The 64-bit extensions correct infamous drawbacks of the x86 architecture, namely its poverty of registers and the extreme register pressure caused by the horrid non-orthogonality of the instruction set. (Translated to English: a whole lot of the instructions executed in any 32-bit x86 program are moves in and out of registers, and in particular moves in and out of a special set of registers that are the only ones that can be used for certain operations like shifts, multiplies, and divides. That in turn is caused by the x86 being the result of decades of backwards compatibility with ancient 8-bit and 16-bit processors.) If you look at Ubuntu Community documentation, they recommend running 64-bit if you can.
People should have learned their lesson when Microsoft C compilers moved from 16-bit int to 32-bit int. The ISO C standard requires standard header files that make it easier to avoid assumptions that trip one up when moving from 16-bit to 32-bit, or 32-bit to 64-bit.
Can I be sure that this particular problem is caused by problems with running a 32-bit SL client on 64-bit Linux? Not yet; since Imprudence goes to the trouble of doing 64-bit Linux builds, I think that running a 64-bit version of Kokua will tell the tale.
UPDATE: I do have to say that the new Firestorm's orange-brown smoke is nicer than the stock Casper, especially at night, and they do give one the option of pie menus, which are really nice for doing things quickly and accurately via muscle memory. But never mind the results of ergonomics research, surely the people who gave us 2.x know what is best for us... [slap] Thanks, I needed that. Sorry about the sarcasm.
UPDATE: New Firestorm is usable for me if I turn off "global illumination". Alas, that doesn't suffice for Kirsten's client--it still grabs all the RAM and crashes in minutes. I hate to lose global illumination, though I guess I should tell myself at least I can take high-resolution pictures again (vide VWR-24178).
UPDATE: Um, maybe not on the high-resolution photos. They're not blatantly ruined as they are with the VWR-24178 bug, but there's a pesky vertical line over to the right... here's an example.
UPDATE: I don't know what changed, but Firestorm is once again sucking down RAM and dying. I had the System Monitor up and watched it grab 100 MB of RAM about every ten seconds.
UPDATE: OK. The SL 2.7.something beta client ran for hours for me today, and then I signed back on only to find it allocating all RAM and crashing very quickly--no settings changed. Is it the cache? I don't know. I do know that the SL client is very much still subject to the VWR-24178 bug; it ruined the high-res pictures I took in the grand old style, no piddly black line for it.
I also noticed something else... if you ever go to the Boobie Tops main store, it's set in an enclosed region that is permanently a rainy urban environment. I would teleport there and then notice that as I moved, there would be flashes of light--possibly the light from the outside day cycle flashing through; I don't know. When I stopped, they would stop. Today, with LL's 2.7 beta client, I saw that effect a lot in several places I went.
No comments:
Post a Comment