holy cow! i was never expecting a real answer FROM ATI!!! I am
impressed! very very highly impressed.
I fully understand you. I can see that happening. It just seems
like 32 _should_ be enough. I underestimated the amount of GPU RAM
that the Finder takes by a lot. I ran initial calculations when I
added the feature and it seemed to work. sheesh.
It would have been good to have some of that information available in
researching the apparent "bug." The mac mini being so important for
consumers and Apple, having this tied specifically to the 9200 could
be good. I'm going to add your email to the apple list for opengl.
This way it is at least cataloged somewhere searchable.
I will have to write a little FAQ for it.
Another solution to the problem is set everything up. render the
first frame as black or white. Then grab the frame buffer and run a
simple edge detection algorithm. Something like this: sum of abs
(pixel minus the next pixel) + abs(this pixel minus the next y
pixel). Add these values together for a 64 by 64 or 128 by 128 of
the screen and see if the value is not zero. If the value isn't what
it should be, stop the process and tell the user that they don't have
enough vram.
This is the only solution that I had come up with to detect the problem.
It seems like this is a glaring hole in opengl. I guess there should
be a way of asking the card if it can allocate a screen based on the
pixel attributes before creating the context. if you could put that
feature in to the queue as something that should be coded, I think
there would be a lot of happy coders. errr.... campers.
I don't know where i'd be without the state of graphics cards today.
Thank you Adrian! ATI ROCKS!
Brad
On May 10, 2005, at 7:08 PM, Adrian Cheng wrote:
Hi Brad,
This is Adrian Cheng from Chris Bentley's (chrisb) group at ATI. I
was working on the bug you mentioned with your software on Mac
Mini. I found out it's a out of VRAM issue with the 32MB of VRAM
that poor Mac Mini has (same bug didn't happen to 64MB 9200
cards)...... I found out that terrible "bug" doesn't happen when
display size is 800x600 and below, so I will use 1024x768 as my
example. Here is the math:
First, let's see how many pixels there are in 1024x768. 1024*768 =
786,432. That's 0.8M pixels. Mac displays has 3 color modes you
can set, Millions (32-bit), Thousands (16-bit), and 256 Color (8-
bits). The default for Mac is at 32 bits, so that's 4 bytes on
each pixel, so 0.8x4 = 3.2 MB. Now, let's see how many buffers
there are. First, there is at least the Front and Back that are
always present, so that's 2*3.2MB = 6.4MB. Now, the interesting
part comes, with multisampling on, it's going to consume 4x that
amount on the multisample buffer (2x on x and 2x on y) because R200
uses supersampling when multisample calls are received. There's no
particular reason, just the hardware at that time for 9200 couldn't
support true multisampling. Now, there are (2 + 4)*3.2 = 19.2 MB.
That's not counting the RightBack, RightFront, Depth, several Aux
buffers, and all the possible textures you can have that will eat
up the precious VRAM, plus there could be other 3D apps running and
there is also the memory fragmentation problem with Apple's
resource management, so I wasn't surprised to see this.
Now, let's talk about the solution. I realized your App does
detect the screen resolution and disable the "Sharp Edge
Eliminator" checkbox when the resolution is high (forgot how high
is high). However, if you start up at a low resolution and then
user uses a mode switch to change the resolution of the display to
something high, the FSAA option checkbox stays enabled. The bug
occurred when I tried to switch from 800x600 to 1024x768. There is
some limit where you should turn the multisampling off, but that
depends on whether other 3D apps are running at the same time so
that's a hard problem. Another solution that I found was to
manually change the color mode from Millions to Thousands. That
would immediately solve the problem. Maybe you can play around
with these things and find out what flavor you like the most.
I am sorry I couldn't help you from the driver side and hope you
understand my interpretation of what exactly happened.....
Sometimes my teammates have problem understanding me too. Good luck!
- Adrian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden