Some Doom3 benchmarks are out

[Canis]

Looks like idsoftware hasnt taken advantage of the Mac's capabilities, since it runs rather slow on a dual 2.5GHz G5. They probably didnt use Apple's Xcode and probably have a shitload of PC code in there that doesnt take advantage of the G5's advanced technologies. Oh well, maybe they'll get that stuff in there at a later date, but seeing how it took a while for them to do it with Q3 and even then it was Graeme's little side project, I doubt we'll see much going for the Mac D3 in that respect.

http://www.macworld.com/news/2005/03/02/doom3/index.php

[Geebs]

:/

Thanks for the link; although it's comforting that these are with "High" settings and 8x aniso.

[torq2]

They probably didnt use Apple's Xcode and probably have a shitload of PC code in there that doesnt take advantage of the G5's advanced technologies.

Or probably Apple's OpenGL drivers suck? Apple hasn't put too much work in anything gaming related latey. (other than fixing some annoying shader bugs)

Conclusion: Play Doom3 on next year's Macs.

[NCG_Mike[temp]]

I understand the port was done by Duane Johnson of Aspyr and has nothing to do with ID. He did the BF1942 and Halo ports.

It seems to be an XCode app (GCC 3.3) as it takes a command line. CodeWarrior apps don't, to my knowledge, as they don't use the UNIX libraries but their own libs ported from Classic. You can force it to use the OS libraries but it's a major effort. Besides, CW can't codegen for a G5.

The only thing I like about CW on OSX is that it has a good search in source files facility.

[Canis]

I say get some fool in there that really knows how to optimize for the mac, and let him loose. I'm sick of these programs that are built just so they'll run, regardless of performance. A dual 2.5GHz machine with a 8x AGP Geforce6800 Ultra, gigs of RAM, etc. all running an OS that has OpenGL built into the core should run a program like D3 exceptionally well.

[SplishSplash]

What angered me most was the stupid "CPU cycle"-theory by that obviously retarded author.

We've often heard about the "Megahertz Myth" -- the idea that Macs can perform as well as or better than PCs despite their lower clock speeds, and that's true for some operations. Games don't work that way, though: there's no substitute for CPU cycles when it comes to games like this.

The Athlon64 4000+ clocks slower than his Dual-G5 rig, and still runs Doom3 faster than any Pentium.
I hate it when those Mac guys are so fixated on their Macs that they forget about the rest of the computer world, instead spouting bullshit about Intel AND Macs.

It's rather obvious that Aspyr botched the port, but he is so insecure about his cpu cycles that he prefers to tell us bullshit.

[Canis]

Of course, and it makes naive mac users look like fools when they spout this stuff around without realizing that the hardware is perfectly capable, and the performance is really in the hands of the developers.

[Canis]

Here are some benchmarks by barefeats. They also have a good explanation for the performance hit on the mac: http://www.barefeats.com/doom3.html

Just like the PC version, timedemos should be run twice to get accurate results. The first run the game is caching textures and other data into RAM, so the timedemo will stutter more. Running it immediately a second time and recording that result will give more accurate results.

The performance differences you see between Doom 3 Mac and Windows, especially on high end cards, is due to a lot of factors (in general order from smallest impact to largest):

1. PowerPC architectural differences, including a much higher penalty for float to int conversion on the PPC. This is a penalty on all games ported to the Mac, and can't be easily fixed. It requires re-engineering much of the game's math code to keep data in native formats more often. This isn't 'bad' coding on the PC -- they don't have the performance penalty, and converting results to ints saves memory and can be faster in many algorithms on that platform. It would only be a few percentage points that could be gained on the Mac, so its one of those optimizations that just isn't feasible to do for the speed increase.

2. Compiler differences. gcc, the compiler used on the Mac, currently can't do some of the more complex optimizations that Visual Studio can on the PC. Especially when inlining small functions, the PC has an advantage. Add to this that the PowerPC has a higher overhead for functional calls, and not having as much inlining drops frame rates another few percentage points.

3. More robust and modern OpenGL implementation on OS X. The fact that OpenGL is engineered from the ground up on OS X to be accessible from many applications at once is wonderful for the rest of the world, but does have a performance hit for games. Sharing GL with the rest of the system invokes a small overhead that Windows doesn't have, since Windows can basically assume GL is just in use for one application.

4. OpenGL framework/drivers split on OS X. On Windows, ATI and nVidia are responsible for the OpenGL code all the way from the hardware to the game. On the Mac, Apple handles the top layers of OpenGL and then hands data off to the video card drivers. On Windows this allows the video card manufacturers to do some more direct optimizations that make sure data gets passed to the card as fast as possible. The Mac can't short circuit that process, since there is a fairly well defined boundary between GL and the video card drivers. This is complicated by the more modern GL implementation on OS X as well- Apple can't just put in a bunch of hacks to shove data around the wall and into the cards, just for the game.

5. And the last, but definitely most important factor: Amount of time Apple/ATI/nVidia have had to optimize specifically for Doom 3. On Windows, ATI/NVIDIA spent multiple programmer years tuning their OpenGL implementations for Doom 3, starting back over a year ago while the game was still in development. Apple/ATi/NVIDIA have done an immense amount of work on OS X's GL in the last 3-4 months, but there is no way they could get as much done as the dozens of Windows engineers working on the problem for over a year. 10.3.8 includes a huge number of GL optimizations that make a big difference in Doom 3, and the game wouldn't have been in any shape to ship without these. One of the biggest things ATi & nVidia do on the PC for Doom 3 is have application specific OpenGL optimizations just for the game. They can detect Doom3 is the application using GL, and even which shaders it is downloading -- then they can shift to a mode that is highly optimized just for those cases.

The good news on all of these fronts, especially the last one, is that Doom 3 is such a highly visible benchmarking application, Apple/ATI/NVIDIA/Aspyr are all going to be continuing to work on increasing performance over the coming months/years. Just like what happened with Quake 3, the Mac OS matured, video card drivers got more optimized, and the game was tweaked so that eventually Mac performance is now as good or better than comparable PC hardware (I'd be really interested to see benchmarks with Quake 3 with the original shipping Mac app & version of OS X versus the latest app & current OS on the same hardware). Games drive hardware and the OS, and Doom 3 will likely push Apple to upgrade consumer video cards and continue to spend engineering time in the future to speed up OpenGL.

[dzjepp]

So what happened with the marketing hype that Doom 3 would ship at the same exact moment on both PC and Mac?

[Canis]

That was John Carmack's hope a while ago, and at Macworld he was invited on stage to demonstrate the D3 engine running on a Mac. iD software then went and cranked out the PC version with all its optimizations, and left the mac version for Aspyr to finish up.

[NCG_Mike]

My guess is that when Mr. Devine left, there wasn't anyone who could use a mouse.

[NCG_Mike]

Well, I just ordered it at amazon.co.uk.

[torq]

My guess is that when Mr. Devine left, there wasn't anyone who could use a mouse.

:lol:


by the way: A good article on arstechnica regarding the problem http://arstechnica.com/news.ars/post/20050315-4704.html

Title: Doom 3's performance on Mac OS X is disappointing, and there's no easy fix

Conclusion: The biggest remaining optimization is below the surface of OpenGL

Read it!

[SplishSplash]

If you read on, you'll realize that the real problem is that PowerPC and x86 are completely different architectures and ports are very difficult to do, especially when you're on a budget.

I'd say fuck Doom3 and hope for the PowerPC-driven XBox2/PS3 to bring games to the Mac.
Or use your Mac for work and buy yourself an XBox instead.

[NCG_Mike]

Having got an xbox, I can confirm they're crap :-D

[NCG_Mike]

Well, I have Doom 3 and it runs. I can get about 47fps if I turn shadows off and run it at 640x480 (the default).

My rig is a dual 2Ghz G5/1.5Gb RAM and a 64MB ATI 9600.

Edit: If you have it installed, run "strip" on the binary as it has *all* the symbol information in it. It'll reduce the size of it and, obviously, the memory footprint.

Code: Select all

G5:~ mdavis$ ls -l /Users/mdavis/Applications/Doom\ 3/Doom\ 3.app/Contents/MacOS/Doom\ 3 
-rwxr-xr-x  1 mdavis  mdavis  16495416 17 Feb 17:06 /Users/mdavis/Applications/Doom 3/Doom 3.app/Contents/MacOS/Doom 3
G5:~ mdavis$ strip /Users/mdavis/Applications/Doom\ 3/Doom\ 3.app/Contents/MacOS/Doom\ 3 
G5:~ mdavis$ ls -l /Users/mdavis/Applications/Doom\ 3/Doom\ 3.app/Contents/MacOS/Doom\ 3 
-rwxr-xr-x  1 mdavis  mdavis  15699208 20 Mar 21:26 /Users/mdavis/Applications/Doom 3/Doom 3.app/Contents/MacOS/Doom 3
G5:~ mdavis$ 

[Canis]

There've got to be some tweaks for it, but I'm surprised they couldnt have done more with the code to get it optimized instead of just running.

[NCG_Mike]

Well, like I say, it runs but it's not smooth unless you turn the shadows off.

I suspect it's a combination of factors, other than poor driver performance.

FWIW, on a G5, it's faster to do a for loop with floats rather than integers. I suspect the guys at ID used doubles for calculations which wouldn't help the Mac side of things.

Having seen the Quake 1 code and bits of the Quake 3 code, I'd say it was simply crap programming by ID. As a rule, games programmers aren't the best, in my experience.

I should put the unstripped binary back and run shark on it, then I can tell you where and *why* it's slow. That'll end all the speculation...

[Canis]

Yeah, it seems they're just relying on advancements in hardware to grind through crap code instead of using their minds to create optimizations. I bet they could get a game that's double the complexity of D3 up and running on OS X if they just spent time making the code more efficient. Heck, they got D3 running on the Xbox, which is a shitload slower than a dual 2.5GHz G5 with a Geforce6800/RadeonX800 video card.

[NCG_Mike]

Well, as they're developing, they should *never* optimize. It's totally incorrect to do so. Optimization is a post build effort.

Of course, this can mean some of the code has to be trashed so that it runs on the required hardware but you *cannot* tell which function is the real bottleneck until you build the whole thing.

Personally, I run Shark on my apps when I'm hitting beta and often re-write a few functions to gain a bit of speed. Mostly, my code is C++ ported from Windows and I see the frequent problems PC guys cause for us Mac guys - loading a variable and using it immediately is a common problem which can be resolved by reordering code. Int to float conversions are another which can often be pre-calculated *or* held in duplicate variables which might appear bad but in reality can work out for the best.

Let me profile Doom 3 and get back to you.

Edit: performing a strip on the binary removes about a meg off its size.

[NCG_Mike]

Here're two screen shots of the Doom 3 profiling...

http://homepage.mac.com/only_mortal/scr ... rofile.jpg

http://homepage.mac.com/only_mortal/scr ... leneck.jpg

They imply that the slowest point is in the Doom 3 code and not the driver.

[dinnerdogTemp]

Was waiting on the release of Doom 3 before purchasing a new G5.

Seeing these poor benchmarks mean that I'm going to be waiting a little longer.

I might as well hold out for PCI-Express and 3ghz dual core quads.

[NCG_Mike]

Tried it on 8A414. No change in speed as far as I could tell. Not surprising really.

[SplishSplash]

I might as well hold out for PCI-Express and 3ghz dual core quads.

I wish Apple would switch to cell processors right away. Those seem to be insanely powerful and shouldn't be too expensive.

Oh well.