Far Cry AMD64 Edition - A First Look at 64-bit Gaming
by Anand Lal Shimpi on May 10, 2005 4:51 AM EST- Posted in
- CPUs
For years, AMD has been talking about the positive impact that 64-bit will have on games. Honestly, we never bought it; games are still a couple of years away from breaking the 2GB process limitation under present day 32-bit Windows. Despite our lack of belief, AMD still did their best to convey the message that gamers would be given a better experience in a 64-bit environment.
AMD has been demoing 64-bit versions of the Unreal engine as well as Far Cry for quite some time now, but neither were ever made public. Originally, we heard talk of 20% increases in performance due to decreased register pressure when running in 64-bit mode. We desperately wanted to see a game recompiled with 64-bit support, but alas, we needed a 64-bit OS. Last month's release of Windows XP x64 Edition fulfilled the latter requirement, but we still lacked any games to test the hype.
The Chronicles of Riddick: Escape from Butcher Bay actually shipped with a 64-bit binary out of the box. Unfortunately, we saw absolutely no performance improvement from using the 64-bit binary vs. the 32-bit binary in our extensive evaluation of the x64 edition OS. If performance under Riddick was any indication, 64-bit wasn't going to be much of a performance sell for gamers.
Today, however, AMD and Ubisoft are announcing public availability of the first 64-bit patch and content update to Far Cry. As we just implied, the 64-bit add-ons to Far Cry come in two separate packages. First, there's the actual 64-bit patch that installs and enables a native 64-bit binary to run under x64 edition. The second package is the AMD64 Exclusive Content Update that improves the actual content in the game.
All LevelsAs you can probably already tell, none of the additions or enhancements have anything to do with 64-bit memory addressability. In fact, a fast GPU is all you really need to take advantage of most of these features - not a 64-bit CPU. The patched version of Far Cry doesn't even eat up more than 512MB of memory during normal gameplay, and supporting more insects and birds doesn't really depend on more architecture registers provided by AMD64 either. It's no surprise that none of the enhancements offered by the 64-bit patch have anything to do with a 64-bit CPU at all, but you have to add value somehow and this is how Ubisoft and AMD decided to do it.On the Pier Level
- Improved terrain textures
- Increased view distance
- Offset bump mapping added for rock and stone objects
- More insects and birds
Pier and Boat
- New beach road with additional vehicle
- Barrel storage camp
- Opened more space to explore
Two New 64-bit only Multiplayer levels
- New terrain textures with shader
- Stronghold
- Gorge
Far Cry doesn't use more than 512MB of memory, even with the 64-bit patches.
Despite the wording of the error message, the patches will work on Intel EM64T enabled systems - just not on 32-bit processors.
The Far Cry patch also acts as a no-CD crack, it appears, as we no longer had to have our play disc in the drive to play the game after applying the 64-bit patch.
Facebook
Twitter
RSS
59 Comments
View All Comments
Jynx980 - Thursday, May 12, 2005 - link
More insects and birds? I better hop on the 64 bit wagon!Im surprised to see so many uneeded processes running. qttask, ati2evxx, ipodservice, ituneshelper; these things eat up the ram little by little.
KF - Wednesday, May 11, 2005 - link
There is no way to say for sure that the basic design of Far Cry is sufficiently ambitious to show off AMD64 well, because designers need to design to what is available in mass if they plan to sell games in large quantity. Intel only recently capitulated to doing EMT64, so designers could not design with 64 bit in mind.
It may be that AMD's intent was to show that more abitious game designs are more practical for a 64 bit machine. If AMD wants to demo advantages of AMD64, there needs to be a 32 bit version of the game with the extra content to compare, or else they need to show why the added content is not possible with 32 bits.
Why do more registers speed things up? Keeping things in registers is the fastest way to do things. x86 has 8 general purpose registers, 6 of which are ordinarily available. To do a very simple loop, you are liable to need 2 or 3 registers to hold adresses and at least 2 to hold operands. Since you need to hold onto intermediate results in the process, you are already nearly maxed out. That was fine in the original 386 days. But current CPUs can readily execute 3 ops simulanaeously, so if you attempt to use the CPU to maximum capablity, and do multiple things concurrently, you run out of registers. Therefore the capabilities of present CPUs are vastly underutilized. Adding 8 more general registers, like AMD64 does, helps a lot. Intel says that by actual measuremnent in real programs, currrent CPUs average 1 op per cycle, when they can do a possible 3. Not impressive. I hope that explains the potential of more registers.
OTOH, programs like games obviously use massive amounts of data which is only briefly in registers, so slinging that in and out of memory is going to take up a lot of time. That will limit the average ops per cycle considerably. It is only while you are processing a given chunk of data that you could get the number of ops per cycle up. The more you process a given chunk of data, the more potential speed up possible. If the design was not ambitious enough, there is not going to be much speed up. Older CPUs would be good enough.
thelanx - Wednesday, May 11, 2005 - link
Has anyone compared the enhanced visual quality screenshots with hdr screenshots? I know that enabling hdr makes the colors of the land and the water more vibrant, which seems to occur in the enhanced version as well, most noticably the better water and more vibrant trees. Perhaps crytek used what they learned doing the hdr and implemented similar effects without using hdr?Sheeno - Wednesday, May 11, 2005 - link
I don't get the problem, Anand showed that the difference between the 64bit patch and a normal 32bit farcry was negligible. In fact, the only difference is the graphical enhancements you get from adding the second 'graphics' patch. We can all assume that the quality of your graphics card will run the latter, so why the 64bit? It seems this was nothing more then a marketing stunt, and those of us with 32bit processors, AMD or not, are left without a neat update. Thanks AMD, I'm glad you decided to forsake your 32bit processors.ir0nw0lf - Tuesday, May 10, 2005 - link
As much as I love AT, I feel that the [H]ard|OCP article was much more informative and "meaty." Their article didn't seem to have a rushed feel to it vs. the AT article, which as mentioned above feels a bit rushed and possible incomplete.msva124 - Tuesday, May 10, 2005 - link
Thank you, that makes sense.stephenbrooks - Tuesday, May 10, 2005 - link
^ Compiler doesn't get in knots swapping stuff in and out of main RAM or cache so often. Registers have a 0 cycle access delay :pmsva124 - Tuesday, May 10, 2005 - link
>That's like asking why would more cache, or more RAM increase performance..Then it should be very easy for you to explain why more registers will increase performance.
Concillian - Tuesday, May 10, 2005 - link
I will go along with many of the opinions I'm seeing here and say that I think there is a lot of assumption in the article, and not enough proof.- The reader is assumed to know that 1024x768 high quality is CPU bound
- The article assumed that the performance of 64 bit patch + additional content would show worse performance, but has no demonstration of that in either a CPU bound or GPU bound scenario. (speaking of the comments: "In fact, a fast GPU is all you really need to take advantage of most of these features - not a 64-bit CPU" and "but the fact of the matter is that none of the visual improvements enabled by the Far Cry patches had anything to do with AMD64 or EM64T"
Perhaps those comments assume more knowledge of how all this stuff works than the average reader has, and it's more obvious to someone like Anand with a more extensive knowledge of CPU architecture and how software interacts with specific registers, etc... Maybe the conclusion is more obvious to someone with that kind of knowledge, but I just see conclusions being drawn about one thing (64 bit patch + ehanced content) from a test of a completely different thing (64 bit patch only)
Anand, you talk about apples to apples comparison. To take that analogy and run with it... Why do you do an apples to apples comparison and then make a conclusion about potatoes?
I think it would have been a reasonable comparison to see the performance with and without the additional content to demonstrate which hardware was actually being taxed (video or CPU). Especially with the strong opinion expressed in the article about what hardware the etra content taxes. I don't question the conclusion necessarily, I just think that if you maake such a strong statement you should have real data to back it up.
I only criticize because we have high expectations of AT articles. I hope these comments are seen as constructive, because that's the intent.
xtknight - Tuesday, May 10, 2005 - link
I agree that some additional benchmarks with the 64-bit content pack would have been a good idea, even if it's not apples to apples. I'm not downloading this patch for the 5 FPS increase, I want the extra eye candy. Is the content pack supposed to include only stuff a 64-bit CPU could do efficiently? Then it would be nice to compare it to a 32-bit CPU. Otherwise, I understand your reasoning that this pack really has nothing to do with 64-bit in the first place.