“When I’m sixty-four”: discussing the 64-bit version(s) of Firestorm

firestorm-logoOn October 18th, Jessica Lyon poked me about an upcoming blog post she was preparing for Firestorm which would make mention of a 64-bit Windows build, offering me the opportunity to talk to her about it ahead of the announcement going public.

At the time, my schedule was such that I couldn’t get back to Jessica immediately, so by the time we did get things worked out, the official blog post announcing both the team’s immediate plans for their next release and the arrival of 64-bit flavour of the viewer had been published. However, this didn’t stop me from taking the opportunity to sit down with Jessica and members of the team at the Cheeky Tiramisu Café late one afternoon in order to find out more about the promised “Firestorm 64”.

Meeting with some of the team: Miro (centre-left), Lassie, Ed, Whirly, and Jessica.
Meeting with some of the team: Miro (centre-left), Lassie, Ed, Whirly, and Jessica.

64-bit versions of SL viewers have been in demand for a considerable period of time. There has been some degree of resistance to them in the past, although there are a number of developers and self-compilers who have produced their own 64-bit versions of one viewer or another. The resistance has been for many reasons; Windows viewers are already Large Address Aware, for example, allowing them to use the additional memory common to computers using the 64-bit version of the operating system, thus helping to negate one of the biggest reasons for developing a 64-bit build.

Given that 64-bit builds have been seen as potentially problematic in the past, I started by asking what had prompted the Firestorm team to decide to go ahead with one.

“Our Windows 64-bit code was developed by Nicky Dasmijn as a sort of side project she wanted to do to scratch an itch she had,” Jessica informed me. Nicky, who started-out contributing code to the project, is now the project’s Lead Developer. Sadly, she’s also a little camera-shy as well, and managed to successfully escape my conversation with the team, hence why her profile picture appears here.

Nicky Dasmijn - Firestorm's Lead Dev and Win 64-bit coder
Nicky Dasmijn – Firestorm’s Lead Dev and Win 64-bit coder

Jessica went on, “None of us were expecting her to drop the code into the repo when she did; but since she did, and since we had already decided to do a public beta, I figured, ‘Why not? Let’s get it out there in alpha form to see public reaction, and to see what the cost versus benefit might be’, neither of which we know for sure yet.”

I noted that when discussing 64-bit viewer builds at a recent Firestorm Q&A, there were concerns from the team about potential issues with maintenance, such as bugs and additional regressions, and for how it might negatively impact support were they ever to try for 64-bit viewer versions. I wondered what else had changed, other than Nicky working on the code herself, to persuade the team to push ahead on the 64-bit front.

“The expectation is that the 64-bit version won’t have different bugs than the 32-bit,” Jessica replied. “In fact the hope is that it may have better performance and fewer crashes, which if true, should actually take some load off our support team. But we don’t know for sure as we’ve only tested it on a dozen or so computers.”

Miro, Lassie and Ed
Miro, Lassie and Ed

I wondered if trying to offer a 64-bit version of a viewer might be the proverbial catch-22 / can of worms situation: the viewer needs to be put to public use in order to see what the response to it is like, but if it is put into public use, it’s going to be awfully hard to prevent it becoming an accepted and expected version of the viewer.

“Well, the feedback will determine whether we move forward with it, but I think chances are good,” Jessica said, before giving me a wry smile, “As for the can of worms; yes, we’ve opened it, and we’re not going to be able to get those worms back in it now. Folks are going to want it, many will want it even if there is no noticeable benefit.

“But other TPV’s are also working on 64-bit windows too, I spoke to Latif [Khalifa] from Singularity and found out he also has coded up Windows 64-bit for them. So to add another metaphor to the mix: the cat is out of the bag, and x64 for Windows is going to happen with or without us, and due to user demand it will likely become a standard presence going forward.”

Whirly, Jessica and Cinder
Whirly, Jessica and Cinder

Which is going to be music to the ears of many, particularly if Mac and Linux 64-bit builds are also on the way.

“We’re hoping we’ll get Linux 64 out at the same time,” Jessica confirmed. “But we’re depending on Techwolf [Lupindo] to do the work and his real life has been very busy lately. We absolutely will have it, just hard to say when. Same goes for Mac. It is in the future; but I couldn’t offer an ETA there at all.”

Does the introduction of 64-bit into the equation make the build process more complex?

“There has been some discussion around the build process,” Jessica admitted, “And folks feel having 64-bit might push us further behind. In truth, Nicky has set up the x64 builds to just require a flag change (setting) during the compile,” she paused a moment, before continuing.

The Cat-herder of Firestorm!
The Cat-herder of Firestorm!

“Let me explain. All of our builds, whether 32-bit or 64-bit, SL or OpenSim, come out of the same code repository. When we want to compile the Second Life version, we set a flag which tells the build process to include the Havok support code and to exclude the OpenSim grid selector. When we want to build the OpenSim version, that flag is replaced with one that tells the build process to include the OpenSim grid selector, but exclude the Havok support.

“Now, with Nicky’s code, we can replace both these flags with one which tells the build process to use Windows 64-bit libraries instead of the 32-bit libraries. Using this process means we can commit a change and it will work on all the different builds we make. It’s just the compiling that takes longer because we have to compile yet another version, but it’s basically building the same viewer but with different libraries.”

So in other words, the 64-bit version will have all of the same functionality as currently found in the 32-bit version, and as new functionality is added, it will appear in both variants as they are updated. The only exception to this is that the 64-bit build won’t include support for the Havok libraries Linden Lab provide for the viewer. This means that when used with Second Life, the 64-bit build will not be able to upload mesh with physics or be able to modify the pathfinding navmesh.

Clockwise from the empty chair: Miro, Lassie, Ed, Whirly, Jessica and Cinder
Clockwise from the empty chair: Miro, Lassie, Ed, Whirly, Jessica and Cinder

Another potential issue with 64-bit flavours of a viewer is that of distribution – ensuring people can get to the version they need for their operating system easily. I asked how the Firestorm team would handle this: an additional download link? A dedicated 64-bit page for those flavours? And how would feedback be invited?

“We’ll host the x64 on our downloads page in its own little spot, slightly separate from our regular download,” Jessica replied. “As for feedback I think I’ll just ask folks to provide feedback and their experiences to my inbox where I’ll likely throw it up on a public Google doc. To be honest we haven’t entirely decided yet on that.

“The main thing we want to be able to do is determine if there really is a tangible benefit in terms of  performance improvement, and what the cons might be, if any. I’m hoping we will be able to sort through placebo versus reality in regards to performance. Stability should be easier to determine, as we’ll be able to measure this through the crash statistics supplied by Linden Lab.”

Enjoying the shade: Jessica and Cinder
Enjoying the shade: Jessica and Cinder

On the subject on Linden Lab, I asked if the Firestorm team had talked to LL about the work and if so, what had been the level of interest.

“No more than giving them the heads up on the planned release of the public beta and 64-bit alpha. There didn’t seem to be any lifting of eyebrows though in regards to x64,” Jessica informed me.

All of which left me with a final question: when would the x64 alpha appear? The end of October, alongside the Public Beta of the next release (as the blog post implies), or later?

“The plan is to get Windows 64-bit out along with our public beta around the end of this month,” Jessica said, before hesitating a moment. “I’m hoping we’ll also be able to get the Linux 64-bit out at the same time, but absolutely no promises on that. If not at the same time, then shortly after.”

So there it is; 64-bit viewers look to be on the horizon, with both Firestorm and Singularity actively working on them, and doubtless others as well. Do keep in mind, however, as Jessica emphasises in the official blog post, the 64-bit Windows version of Firestorm, when it appears, will only be an experimental release, and really should be treated as such when it does see the light of day.

In the meantime, there is also a public beta of the next release of the 32-bit versions of Firestorm coming up. This will have materials, .DAE object export and a lot of other goodies. I’ll be bringing you more on that in my regular Firestorm reports and reviews.

With thanks to the members of the Firestorm team who took time-out to meet with me, and to Yasyn Azemus, proprietor of the Cheeky Tiramisu Cafe, for providing a venue in which we could meet and for providing invaluable assistance.

Related Links

Advertisements

20 thoughts on ““When I’m sixty-four”: discussing the 64-bit version(s) of Firestorm

      1. I found a comment from Havok support on a forum: “We do support X64 but not in our free SDKs of Havok Physics and Animation.” So in order to use Havok in FS64 they would have to purchase it like they did the 32bit version.

        Like

        1. We didn’t purchase any Havok library. The library is provided as special package under special licensing terms from Linden Lab. And because it’s that special, bying the SDK from Havok itself won’t work. LL will have to make a 64bit version of their package in order to use them in a 64bit viewer.

          Like

  1. … only exception to this is that the 64-bit builds cannot include support for the Havok libraries Linden Lab provide for the viewer. This means that when used with Second Life, the 64-bit builds will not be able to upload mesh physics or be able to modify the pathfinding navmesh.

    that is pretty experimental. or not for use in SL ? (she asked carefully).

    assuming that “not be able to upload mesh physics” merely refers to the actual process of uploading the model intended for use as a physics shape for a mesh, not being able to do so is inconvenient for mesh builders. but if “not be able to upload mesh physics” means the viewer can’t recognize or use mesh physics shapes, then what happens? we have some people unable to get through doorways or prone to falling from skyboxes or what? that would be so insane, i must have misunderstood, right?

    Like

  2. Singularity has always been offering 64 bit Linux version, and as Jessica mentioned, we have now add Windows 64 to the mix. That brings number of builds to 5: Windows 32 and 64 bit, same for Linux and a Mac version For those wishing to play with it you can download it from Singularity’s automated build site: http://alpha.singularityviewer.org/

    The problem with the 3rd party libraries is very real, as you cannot mix different architectures into a single application. For Singularity 64 bit on Windows means that we cannot use Quicktime, since Apple never made their SDK available for that platform. It means that this viewer is currently unable to display old-style parcel media. Media on a prim and streaming music work fine.

    There are 3 ways to approach the problem with parcel media: Firestorm opted to build a mixed architecture where viewer plugins are compiled 32 bit, and the rest of the viewer is 64 bit. Singularity currently builds it all 64 bit, but lacks Quicktime support. Or we could try to find another 3rd party library that would provide that functionality and also supports 64 bit architecture. Singularity could end up using any one of these 3.

    But who uses old style parcel media anyway, right? 😉

    Like

  3. Might be nice but Firestorm seemed to have stopped doing up dates for the released Firestorm viewer and users are having to live with the bugs in it.
    Your reporting regularly that updates to other TPV are out.

    Like

    1. Firestorm are still working on updates.

      As noted at the end of this piece, there’s a public beta coming of the next release. They’ve had some set-backs due to the way CHUI came out (if you notice, most v3 TPVs opted to take CHUI more-or-less “as-is”, but Firestorm already had a more unique way of handling text communications compared to the LL viewer/ CHUI), but that doesn’t mean they’ve stopped working on updates.

      Also, if you look at the release schedules across the full range of viewers, you’ll see they are pretty-well spread; some are running updates weekly, some every couple of months, some longer than that; it all comes down to the time the various developers have available to put-in on their projects after taking care of things like work and real life.

      Like

  4. begging for years for 64bit version. But linden labs need to take the step first. and the still are to lazy and stay with 32bit. result. the 64bit firestorm is getting useless if you cannot upload mesh (physics) So right now i got a bit happy for a dead fly. TYPV developers need to push LL to 64bit library’s

    Sad. that 64bit is maby close , but useless, unless the find a way to make 4bit the same functinality as with the 32bit.

    Like

  5. The performance may depend a lot on what kind of computer you have.

    I remember seeing benchmarks in the early days of the AMD64 architecture that showed 64 bit Linux being about 20% faster than 32 bit Linux on the same Athlon 64 system. Then Intel came out with the Pentium D, a Pentium 4 variant that included 64 bit capability, and the performance benefit was zero. Basically, the Athlon was execution-unit bound, so it benefited from the larger number of registers and thus fewer instructions being executed. The Pentium D was memory-bandwidth bound and the 64 bit code offered no reduction in code size, because although there were fewer instructions they were larger on average.

    I haven’t seen similar comparisons of performance on current architectures (Intel Core i3,5,7 series vs. AMD Bulldozer and Piledriver) or even the previous one (Intel Core 2 vs Athlon/Phenom II) so I don’t know how performance will compare on those. But it wouldn’t surprise me to see an improvement for at least some users.

    Like

  6. As for the purported lack of physics-mesh upload functionality, the impression I get, while somewhat hazy, is that that primarily means that the viewer won’t examine the mesh object you’re uploading, and then try to generate on the fly at upload time its best guess as to what the physics model should be, and save that to the SL servers. But then, I’m also told by some that that generated-on-upload physics model is probably inferior to what a mesh modeller would generate in advance, being able to hand-optimize it in the 3D editing program. I’m also told that that generated-on-upload physics model will come out different each time you go to upload the same mesh object, sometimes bringing a higher land-impact than at other times, or even sometimes generating a mangled physics model that doesn’t do what you need it to do. But I’ve only ever once uploaded a mesh object, before the can’t-use-the-Havoc-routines-on-OpenSim-grids rule was inflicted upon us, and that mesh was just a small object I’d made while poking Blender with a stick, and didn’t need or use a physics model. (I was following a “Make your own monster” tutorial by Loki Elliot, and that one in fact told us that mesh physics models would be dealt with in a later tutorial, so just link the object to a couple of regular prims made 100% transparent if you needed a physics model for your created monster.) But someone also once told me in passing that it WAS possible to provide a physics model with your mesh upload, in (she seemed to assume) Firestorm-OS, you just had to premake the mesh model in your 3D program, and select that one to upload at the same time as you’re selecting to upload the main mesh object, but she didn’t elaborate on details, and I don’t think she’s using Firestorm-OS for her mesh uploads. I’ve been trying to find out details from people on this, but haven’t found anyone who actually HAS uploaded a mesh object WITH physics model ONTO SL USING Firestorm-OS, most I’ve talked to have said “Well, I’ve uploaded mesh things to XYZ OpenSim grid, and it generates a nice physics model for that uploaded mesh server-side without you having to make one specially yourself, but OpenSim handles mesh way differently than SL anyway, and at that, the uploading of mesh objects is handled differently there than for SL.” But that was NOT what I was ASKING! oO **Facedesks**

    Like

  7. Course, to come back to the main subject at hand…. the fact they’ve started making 64bit versions of the various TPVs, Its likely sooner or later the 64bit version will become the norm, largely because we’re moving towards 64bit operating systems being the norm. At some point soon you likely won’t be able to *get* a new computer that doesn’t have the 64bit version of Windows or MacOS in it… and around the same time we’ll probably see less and less usage of, or development of, 32bit versions of these TPVs. There’ll still be some 32bit TPVs being made, as a niche thing, but the vast majority of ppl will be on the 64bit versions only, and likely the main TPVs will stop actively developing 32bit versions.

    Like

    1. Before Windows 95 the standard was 16bit. It was only a few years before everything went 32bit, we adjusted. Now the transition to 64bit is repeating the process. Some day we will transition to 128bit and life will still go on 🙂

      Like

  8. My perceptions:

    LL – “If it doesn’t save / make US (Screw the Users) money (ROI), don’t enhance it.”
    FS – What’s ROI?

    At this point, I hope Facebook’s recent acquisition of Oculus and the amazing speed of development and innovation being seen in the High Fidelity Alpha community, result in a Next/Current generation X64 alternative to SL becoming available in 2015!

    Like

Leave a Reply to Tali Rosca Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.