Jump to content
  • Advertisement
Sign in to follow this  
jitspoe

OpenGL ATI Fillrate Issue w/OpenGL

This topic is 5433 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've got a game I'm working on based off of the Quake2 engine, and with each new ATI driver it's getting slower and slower. The funny thing is, it seems to be fillrate related. Things like smoke sprites will render fine far away, but when you get close to them, they can drop framerates down to the single digits when you're right on top of them (this is with the 9700pro, and it's NOT very complex data). Also things like menu backgrounds even render slow -- I'm only using 2 passes and getting 100fps. Now out of curiosity, I tried using an opengl->direct3d wrapper. The framerate in the menu shot up to a maxed-out 1000fps, and the smoke didn't even put a dent in the framerate -- I was able to stay at 400-500fps. Something is seriously wrong. There's no way a wrapper should be 10+x's faster. I mean, the hardware should render a polygon about the same way, regardless of which api was used, right? Now it does use a lot of GL_QUADS. I'm wondering if it's trying to do some weird thing with those that's slowing it down. I'm going to try breaking them into triangles and see if it makes a difference. Edit: ok, tried triangles instead, didn't change squat -- still getting 102fps. This is on a 2ghz p4, radeon9700pro at 640x480, rendering a menu. swapinterval (vsync) and other frame limiters are all off. Upping the res to like 1024x768 drops it down to 44fps. Absolutely rediculous. Also, it's only extremely bad with the latest drivers -- previous drivers get like 800fps. Not as good as it should be, but a heck of a lot better. I get like 180-190 fps on my geforce1+400mhz celeron, btw. Just for reference. [Edited by - jitspoe on October 13, 2004 10:53:49 PM]

Share this post


Link to post
Share on other sites
Advertisement
That is very interesting. I've a Radeon 9800xt, and I've noticed that the OpenGL drivers were slower than they should be, too. However, I didn't know they were that poor. Of course, the Quake 2 engine (stock, at least) isn't really optimized for that generation of hardware. The Direct3D wrapper results were odd (and sort of maddening, actually).

Share this post


Link to post
Share on other sites
>>Edit: ok, tried triangles instead, didn't change squat -- still getting 102fps. This is on a 2ghz p4, radeon9700pro at 640x480, rendering a menu. swapinterval (vsync) and other frame limiters are all off. Upping the res to like 1024x768 drops it down to 44fps. Absolutely rediculous. Also, it's only extremely bad with the latest drivers -- previous drivers get like 800fps. Not as good as it should be, but a heck of a lot better. I get like 180-190 fps on my geforce1+400mhz celeron, btw. Just for reference<<

(quads ->tris, shouldt make anydifference in fact quads should be slightly quicker) it sounds like some function is getting thrown down an unoptimized path where in older drivers it was optimized. check the ati performance faq which outlines on how the drivers like there data.
ive ran into stuff like this heaps of times, basically the best method ive found is comment out everything + then start adding functions in until u can narrow down the function/format thats causing the slowdown, i usually find it normally doesnt take longer than 15minutes to fix the problem

Share this post


Link to post
Share on other sites
I was testing my engine yesterday with the stanford bunny model (69451 tris, 1 light source, diffuse color only), and I also noticed that the fillrate was limiting the FPS. I was drawing a GUI system in addition to the model, but it still seemed pretty low (8 fps on a laptop with ATI Radeon, updated latest drivers three months ago, not sure which version).

Share this post


Link to post
Share on other sites
Ok, I logged all the opengl calls from the menu render. Maybe there's something I'm doing wrong?

Here's the log (just 1 frame)

And for reference, here are a couple screenshots of the menu:
800x600
640x480
(note the framerate difference in just a slight resolution change)

So you can make sense of the log, here's the order things are rendered in:
FPS display text shadow
FPS display text
Menu background layer 1
Menu background layer 2
Version text shadow
Version text
Menu items (images, 1 quad each)
"Console" shadow/text
Mouse cursor (2 layers)

Share this post


Link to post
Share on other sites
Quote:
Original post by jitspoe
The funny thing is, it seems to be fillrate related. Things like smoke sprites will render fine far away, but when you get close to them, they can drop framerates down to the single digits when you're right on top of them (this is with the 9700pro, and it's NOT very complex data).


Well... I also try to render a simple particle system, a fire.
And when I am going very close to the fire the my framerate drops from 200-300fps to 20-30fps...
I can not unterstand why...

Share this post


Link to post
Share on other sites
Quote:
Original post by Unreal
Quote:
Original post by jitspoe
The funny thing is, it seems to be fillrate related. Things like smoke sprites will render fine far away, but when you get close to them, they can drop framerates down to the single digits when you're right on top of them (this is with the 9700pro, and it's NOT very complex data).


Well... I also try to render a simple particle system, a fire.
And when I am going very close to the fire the my framerate drops from 200-300fps to 20-30fps...
I can not unterstand why...


First make sure Z Buffer is on - next if you are drawing your particles in no particular order then you might have a problem (z-buffer does not magically solve this). Picture this scenario, you are up close to a particle system:

#1) You draw a particle to the screen it takes up a little spot in the back of the screen. It does a Z-Buffer test and no pixels in front of it so it draws the whole thing.

#2) You draw another particle to the screen, it draws over top of the last one because it is closer. It does a zbuffer check and because the last particle is behind it it draws it.

#3) You draw 200 more particles in the same order (front to back, just happens to be the order) they all use the ZBuffer and do a check but because their are no pixels in front of particle the pixels are always drawn and never discarded.

In this case it would be better to disable z-buffer. Imagine the magnitude of overdraw here, ask yourself how many pixels on the screen have actually been drawn more than once ?

Solution:

#1) You order your particles from Front to Back, Closest to camera to farthest

#2) draw the closest particle, it checks the z-buffer and nothing in front of it so it draws all pixels

#3) draw the second closest particle, it check the z-buffer and voila, their is something in front, it discards drawing the pixels.

#4) continue step 3 until all particles are complete ...

This is not always the case, you will always get overdraw in 3d world but you can minimize it by sorting like objects from front to back, closest to furthest , and then let the z-buffer take over to figure out if pixels need to be drawn.

This is why when you go up close it is far more drastic than far away, you are overdrawing hundred's of thousand's of unneeded pixels (everything is larger, taking up more screen space). Being farther away you can afford to draw over 1 measly pixel 100's times. This is why sorting is important.

Share this post


Link to post
Share on other sites
I think 99% of the time, particles are transparent or blended in some way, so you need to draw all of them regardless of whether or not they overlap. That's not really the issue. The problem is, a 9700pro (or other high-end radeon) should be able to render 5 or 6 polygons covering the entire screen like it's nothing. Using the d3d wrapper, I get 1000 fps (and I think that's as high as it can possibly go)... but with OpenGL, the framerates are terrible.

I tried GL Excess, a little thing like 3DMark for OpenGL, and it had a fillrate test with much more complex things going on and ran fine, like 400 fps. Why is my simple, 2-pass menu getting 40fps at the same resolution? :(

Share this post


Link to post
Share on other sites
Quote:
Original post by jitspoe
I think 99% of the time, particles are transparent or blended in some way, so you need to draw all of them regardless of whether or not they overlap. That's not really the issue. The problem is, a 9700pro (or other high-end radeon) should be able to render 5 or 6 polygons covering the entire screen like it's nothing. Using the d3d wrapper, I get 1000 fps (and I think that's as high as it can possibly go)... but with OpenGL, the framerates are terrible.

I tried GL Excess, a little thing like 3DMark for OpenGL, and it had a fillrate test with much more complex things going on and ran fine, like 400 fps. Why is my simple, 2-pass menu getting 40fps at the same resolution? :(


Hey good point Joe! didn't cross my mind when I was writing it :)

Sounds like driver problem then, or something odd/out of place in your code ... sorry I couldn't help.

Share this post


Link to post
Share on other sites
Quote:
Original post by jitspoe
I tried GL Excess, a little thing like 3DMark for OpenGL, and it had a fillrate test with much more complex things going on and ran fine, like 400 fps. Why is my simple, 2-pass menu getting 40fps at the same resolution? :(


Based on this we can assume there is infact nuffin wrong with the ATI drivers and infact the problem lays with something you are doing, however as we dont have the code we cant tell you what that is.
Maybe you are doing down a sub-optimal path?
Maybe you are doing too many state changes?
Maybe your texture data isnt how the card would like it?
Maybe there is a small squirrel in your computer which eats your code and makes it go slower but doesnt touch others?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!