Re: Answers found to some performance/functionality problems
Re: Answers found to some performance/functionality problems
- Subject: Re: Answers found to some performance/functionality problems
- From: John Stauffer <email@hidden>
- Date: Thu, 17 Jul 2003 18:29:17 -0700
Investigating this in another case yielded a couple factors that lead
to this:
1) The 32MB Power Book graphics chip doesn't support two sided
lighting. Using two sided lighting on that config drops you off the
hardware transform/clip/lighting path.
2) The display list optimizer pads an immediate mode sequence of the
form:
glBegin
glColor
glVertex
glVertex
glVertex
glEnd
to look like this:
glBegin
glColor
glVertex
glColor
glVertex
glColor
glVertex
glEnd
This is an attempt to get it to be in a form that is usable for a
vertex array.
The fix for all of this is to not use two sided lighting at a minimum.
And for even better performance you can change your code to to be more
like the following:
glColor
glBegin
glVertex
glVertex
glVertex
glEnd
We're looking at doing a better job in the display list optimizer so
that you at least break even on performance when not going down the
hardware tcl path.
John
On Thursday, July 17, 2003, at 3:53PM, Steven Langer wrote:
I believe I have explanations for some of the performance and
functionality issues I have seen with beta 3 of Apple's X11 server.
For some time I have been unable to get a program running on my Linux
system to correctly display in a window on my Mac using glx (OpenGL
over X11). I upgraded from version 4349 to version 4363 of the Nvidia
drivers today and the problem appears to have gone away.
I often use display lists on my OpenGL programs. They help cross
network OpenGL performance significantly and I had never seen them
hurt performance under Windows or Linux. On several Macs with 32 MB of
graphics memory, I found that display lists were about half as fast as
direct rendering. I borrowed a titanium laptop with 64 MB of graphics
memory. On this laptop, display lists are roughly twice as fast as
direct rendering. All of these Macs had their display set for a
million pixels or more.
I use a double-buffered, z-buffered visual that is typical of most 3D
applications that support rotation of the scene or animation. I
suspect that these buffers take up so much graphics memory that the
driver decides there isn't room for a display list in graphics memory.
The laptop with 64 MB of graphics memory has at least 32 MB free, so I
suspect that this Mac put the display list in memory and got much
higher performance.
This wouldn't be a big issue on PCs where 64 MB or more of graphics
memory has been standard for a while now. However, the graphics memory
on a Mac graphics card is frequently half the amount on the
corresponding PC card. As a result, there are a lot of G4 Macs out
there with 32 MB of graphics memory. I hope to get Mac AGP graphics
cards with 64 and 128 MB of graphics memory and see if this solves the
performance problems on the Macs that currently have 32 MB of graphics
memory.
This is encouraging news because it now looks like we can use an OS X
Mac with at least 64 MB of graphics memory to look at the large data
sets we have on our Unix servers.
_______________________________________________
x11-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/x11-users
X11 for Mac OS X FAQ: http://developer.apple.com/qa/qa2001/qa1232.html
Report issues, request features, feedback: http://developer.apple.com/bugreporter
Do not post admin requests to the list. They will be ignored.