Terribly slow :-(

Post: #1
On my RagePro OpenGL is slower of a terrible magnitude when Im using a 32bits context :-(
No textures, no lights, just a couple of quads (48) using colors.
There's also 32 lines, the alpha buffer and the depth buffer are enabled.

In 16 bits there's no difference if it's 48 or more. But in 32 bits I get a slowdown if I use more than one tenth of the number of quads I use in 16 bits.

My code is not optimised, but it's strange anyway so see such a bad performance. And the window is 512*512 (it's a small modeler).

Anyone has some tricks, infos about that? I know Apple recommend 16 bits for the old computer of mine, but 23 bits makes my desktop picture looking better, which for me is important.

If I make my context 16 bits even if the screen is 32 bits, can it help?
Quote this message in a reply
Post: #2
I can see two possible problems.

First, the RagePro is stressed when rendering to a 32-bit surface due to the bandwidth required.

Second, OpenGL standardization requires that you implement all features of the interface, even if your card can't do it in hardware. For instance, if you asked your RagePro to do antialiased lines it's going to draw them but it's going to draw them using software renderer in the driver.

Why is the second part important? If you ask a graphics card to do something it can't do in OpenGL, the driver makes up for it in software. Since the driver doesn't know what you're going to ask for it can get ludicrous. Imagine (hypothetical case):
1) Draw a bunch of untextured, unlit triangles with z compare.
2) Draw one antialiased line with z-compare.

Image our hypothetical card can draw the polygons at amazing speed but it can't draw the antialiased line at all. You send all the polygons to OpenGL, the driver forwards them off to the card - no problems. Then you ask for the antialiased line. Just one. The driver gets it and it has to deal with it, it can't just ignore the request. So the driver draws it in software. Wait...there's more. Since it's z-compared the driver has to wait for the hardware to flush all the queued triangles before it can begin drawing so the z-buffer is up to date.

Let's go even further and say our card doesn't allow access to the z-buffer due to some technicality. The driver has to disgard all of the previously drawn triangles, draw them all in software and then draw the anti-aliased line in software (as well as anything else you ask for this frame).

This hypothetical case got completely out of hand and the driver ended up drawing everything in software just because you asked for one antialiased line. In most cases this isn't going to happen. With modern cards, it will probably never even draw anything in software. In older cards, though, it can happen (the extreme case may never happen).

The moral of this is: know thy graphics card and what it's capable of. It could be the case that the RagePro can do everything you're asking for in 16-bit but can't do something you're asking for in 32-bit so it's defaulting to software.
Quote this message in a reply
Posts: 5,143
Joined: 2002.04
Post: #3
The Rage Pro isn't hardware accelerated at all on MacOSX (mostly because it doesn't really support OpenGL).
Quote this message in a reply
Post: #4
I don't use antialiasing or things I think my card can't handle. I use transparencies to see my plane through the polygons. Im not sure if it's a context problem. When I create my context and I go in the monitors & Sound control panel (it's 8.6) to switch to 16bits and I make a rotation in my view it is fast, but when I switch again to 32bits it rebecome ( a word?) very slow. And the fact that im at 1024x768 probably doesnt help either since my vram is at 6mb, not expandable :-(.
As for MacosX I don't have it for now (a bit expensive and my disk is full), my programing is done in 8.6. I heard the RagePro is supported now, with 10.1.5.

Another weird thing Ive found, last year.
When I bought ST:Racer, it was great but something was weird : the dithering.
It was a matrix type of dithering, it's probably not big deal since in 16bits it's normal.
But the games that use RAVE instead has an error-diffusion kind of dithering, and feels a bit faster too. I don't remember well, but I think the matrix-type came when I upgraded to OpenGL 1.2.

Ive found that replacing the 1.2.1 version of the 'OpenGLRendererATI' file with an older version (the 1.0 I think) makes the dithering normal (the diffusion one) and the game feel a bit faster too.

Two question.
First, I reinstalled my system six months ago so now I don't have the old RendererATI file.
Where I can find it?
Secondly, do you recommend this recommendation? After all, the OpenGL package has been make by a team of professionnals and there's probably a good reason why they done that how they done it, what should I do?
Quote this message in a reply
Posts: 5,143
Joined: 2002.04
Post: #5
* Blending is one of the things that the Rage Pro doesn't do properly.
* The Rage Pro is 2D accelerated in 10.1.5, but there is still no OpenGL acceleration.
Quote this message in a reply
Post: #6
No OpenGL support for the poor RagePro on OS X?
Eek, what did they think?

Is it possible to use RAVE in OS X? I read QD3D is not supported in Carbon.

For the blending, Ive heard about some bugs into the Rage chips our dear ATI made.
My RagePro_C in my imac cant draw a textured polygon with bilinear filtering if the texture is 16 bits and has an alpha mask and the multitexturing is ugly. I tried the Quake3 demo, and it's faster and better-looking when the OGL extensions are off.

Im suffering, anyone want to buy me a new computer? ;-)

I think I know what was the problem, about the speed crash, but I cant check it now because I messed the code becasue of a design switch I decided to make.
I think that the allocated depth buffer is bigger when it's in 32bits, so it's slower because ATI took too much time to make the radeon. something like that
Quote this message in a reply
Posts: 5,143
Joined: 2002.04
Post: #7
Quote:No OpenGL support for the poor RagePro on OS X?
Eek, what did they think?

They thought it was better to provide no acceleration and a good software renderer than spend their time providing partial, buggy, slow hardware support for an outdated 3D "accelerator".

Personally, I don't blame them.

AFAIK, RAVE is not available on MacOSX. There is a free library called Quesa which implements QD3D on top of OpenGL, though.
Quote this message in a reply
Post: #8

Well, I need a new computer, but my budget is tight (I am such a liar, I don't have any budget for anything).

Well, my 3D stuff will not be OS X native for a long time.

My computer feel depressed, now.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Terribly odd display when using shader and glDrawRangeElements on a Powerbook G4 applmak 4 5,425 Mar 15, 2007 06:13 AM
Last Post: applmak
  Occlusion queries... SLOW. TomorrowPlusX 8 7,421 Aug 19, 2005 07:05 AM
Last Post: TomorrowPlusX
  Are SDL events slow? Skorche 3 6,553 Jul 25, 2005 11:08 AM
Last Post: Skorche
  SDL got pretty slow on Tiger? Zeeke 17 13,605 Jun 5, 2005 12:29 AM
Last Post: Kevin Lindeman
  Slow first time draw of textures rzilibowitz 4 5,396 Jan 17, 2005 01:46 AM
Last Post: rzilibowitz