Mailing List
Home
Forum Home
Mac Game - Mac game development
Rivers of MUD - a Diku and Merc based multiuser dungeon
SMAUG
Subjects
Getting UDP through NAT/firewalls/whatever for a game
Getting UDP through NAT/firewalls/whatever for a game
QuickTime errors
Python script as stand alone MUD server
Various sound problems
Fragment Shaders & GL TEXTURE RECTANGLE EXT
Timers and global variables
Re: Language and platform for Text MUD server
Apparent acquisition of Yantis (mysupersales) by IDE
HID keyboard
Getting UDP through NAT/firewalls/whatever for a game
Microsoft Sparkle
Director MX
Congratulations Horizons
Yet more problems fullscreen mode
Apple Dev Kitchen Them 's tasty vittles, Maw!
NSOpenGLContext, Pbuffers, and drawables
More DCR "theft " naughtiness
dynamic sprite creation and imaging lingo
Re: Find stuff in Flash array?
Effects of skill imbalances?
QuickTime errors
Rom 2 4/Quickmud Enhancement/Bug fix
Working with XML files/CFURL
smooth scrolling/subpixel tweening
RE: (Ron help me?) Flash text
Flash Racing
MudDev FAQ 2
Browser based games
Installing GLUT
Special character in Flash XML
 
Slow Path Bugs in OpenGL on Intel and Rosetta

Slow Path Bugs in OpenGL on Intel and Rosetta

2007-05-07       - By zmorris@(protected)

 Back
Reply:     1     2     3     4     5     6     7     8     9     10     >>  

Hi All, I decided to take a couple of days and write a test app to  
show the speed of various paths for uploading an image from a GWorld  
to OpenGL.  It's loosely based on concepts from Apple's OpenGL Image  
example.  You can download the app here:

http://homepage.mac.com/zmorris/.Public/opengltexture.zip

I decided to write it because a lot of games run slowly under Rosetta  
(like 12 fps!), and I think it is mainly caused by bottlenecks  
uploading a 16 bit texture in a 32 bit context.  This is bad because  
people inadvertently run older copies of PowerPC games under Rosetta  
and can get a bad impression of the games.  There are also some  
really bad bottlenecks running as native Intel.

The following functions have serious bugs:

glTexImage2D()   <- slow emulation in Rosetta, slow path in Intel
glDrawPixels()   <- slow emulation in Rosetta

These need to be fixed immediately for Mac OS 10.4 and up on Intel.  
Known Macs that are affected: Mac Mini, MacBook...

Slow path means that something went catastrophically wrong and it is  
running on the order of 10 fps.
This probably means that Apple hasn't optimized the path at all yet,  
meaning it uses something like a for-loop to blit pixels.

Slow emulation means that something is running slower than 30 fps in  
Rosetta.
This probably means that the path is still calling powerpc code  
instead of native intel opengl code.

Please read README.txt in the download for the full explanation.

It would really help a lot if some of you could download the test app  
and run both the PPC and Intel versions, and then email result
(intel).txt, result(ppc).txt, and/or result(rosetta).txt to this  
group so we can get some confirmation.

Here are the results for our dual core Mac Mini, running first the  
powerpc code and then intel code:

######### result(rosetta).txt #########

ProductName:   Mac OS X
ProductVersion:   10.4.9
BuildVersion:   8P2137

readable-model:   not found

hw.model:   PowerMac
hw.machine:   Power Macintosh
hw.ncpu:   2
hw.byteorder:   4321
hw.cpufrequency:   1830000000
hw.busfrequency:   664000000
kern.version:   Darwin Kernel Version 8.9.1: Thu Feb 22 20:55:00 PST  
2007; root:xnu-792 (See http://xnu-792.ora-code.com).18.15~1/RELEASE_I386
kern.osrelease:   8.9.1
kern.osrevision:   199506
sysctl.proc_native:   0

opengl-vendor:   Intel Inc.
opengl-renderer:   Intel GMA 950 OpenGL Engine
opengl-version:   1.2 APPLE-1 (See http://PLE-1.ora-code.com).4.52

width:   640
height:   480

1   flush-window........   13.4881   ms   74.1394   fps
2   CopyBits-window.....   4.60818   ms   217.005   fps
3   16-video-window.....   40.7782   ms   24.5229   fps   (slow-emulation!)
4   32-video-window.....   3.95584   ms   252.791   fps
5   16-system-window....   134.188   ms   7.45221   fps   (slow-path!)
6   32-system-window....   12.288   ms   81.3804   fps
7   16-video-fullscreen.   40.8088   ms   24.5045   fps   (slow-emulation!)
8   32-video-fullscreen.   7.15986   ms   139.667   fps
9   16-system-fullscreen   133.847   ms   7.47123   fps   (slow-path!)
0   32-system-fullscreen   12.5991   ms   79.371   fps

######### result(intel).txt #########

ProductName:   Mac OS X
ProductVersion:   10.4.9
BuildVersion:   8P2137

readable-model:   Mac mini (Core Duo/Solo)

hw.model:   Macmini1,1
hw.machine:   i386
hw.ncpu:   2
hw.byteorder:   1234
hw.cpufrequency:   1830000000
hw.busfrequency:   664000000
kern.version:   Darwin Kernel Version 8.9.1: Thu Feb 22 20:55:00 PST  
2007; root:xnu-792 (See http://xnu-792.ora-code.com).18.15~1/RELEASE_I386
kern.osrelease:   8.9.1
kern.osrevision:   199506
sysctl.proc_native:   1

opengl-vendor:   Intel Inc.
opengl-renderer:   Intel GMA 950 OpenGL Engine
opengl-version:   1.2 APPLE-1 (See http://PLE-1.ora-code.com).4.52

width:   640
height:   480

1   flush-window........   13.4305   ms   74.4575   fps
2   CopyBits-window.....   5.99009   ms   166.942   fps
3   16-video-window.....   2.49084   ms   401.471   fps
4   32-video-window.....   3.51515   ms   284.483   fps
5   16-system-window....   72.747   ms   13.7463   fps   (slow-path!)
6   32-system-window....   10.2054   ms   97.987   fps
7   16-video-fullscreen.   6.13679   ms   162.952   fps
8   32-video-fullscreen.   6.97913   ms   143.284   fps
9   16-system-fullscreen   72.8877   ms   13.7197   fps   (slow-path!)
0   32-system-fullscreen   10.5174   ms   95.0804   fps

####################################

Notice the slow path cases even on native intel that are only getting  
13 fps, while right next to them are nearly identical cases that are  
getting FOUR HUNDRED fps.  Keep in mind that all of these are moving  
pixels from system memory to video memory.  At worst, there should be  
a factor of 2-4 difference but no more.  This is why I had to post  
the code.  It seems unbelievable, but the bugs really are this bad.  
I am tired of people not believing me.  For people googling this, I  
first posted about it here:

http://lists.apple.com/archives/Mac-games-dev/2006/Jan/msg00031.html

There was a lot of code to sift through, but we knew the bottleneck  
would be in a handful of functions.  We thought they were event  
related but it turns out they were mostly in OpenGL, which shouldn't  
really be emulated at all in the first place, when you think about it.

For everyone wondering why we chose this particular method to draw  
our games, it's all explained in the README, so please read that  
first.  We have tried every possible way we could think of, and we  
believe that this is the best method for retro style games that do  
their drawing in system memory.

For anyone still in doubt, does it seem a bit disconcerting that  
these bottlenecks exist?  How many more could there be?  And does  
this help to explain why Mac versions of games often get half the  
frame rate of their PC equivalents?

If worse comes to worse, at least you get some handy opengl texturing  
examples and system profiling code :)

Thank you all for your help,

-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
Zack Morris              Z Sculpt Entertainment               This Space
zmorris@(protected)      http://www.zsculpt.com                 For Rent
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
If the doors of perception were cleansed, everything would appear to man
  as it is, infinite. -William Blake, The Marriage of Heaven and Hell


__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Do not post admin requests to the list. They will be ignored.
Mac-games-dev mailing list      (Mac-games-dev@(protected))
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-games-dev/junlu%405341.com

This email sent to junlu@(protected)