Radeon8500 "high poly count" bug?
- Thread starter BenM
- Start date
Joe DeFuria
Legend
Well, I believe the "name" for this "bug" came from the fact that Radeon 8500 performs poorly on one specific synthetic OpenGL test. (The 8500 does worse than the Original Radeon in this particular test I believe.) The test uses lots of polygons, and hence "high polygon bug" has been un-officially dubbed.
Problem is, it seems EVERY TIME someone finds some issue with Radeon performance, it somehow is attributed to this same "high-polygon bug." Some slow-fown issues in Serious Sam, and RTCW come to mind.
The latest is Carmack's .plan, where he states there is one issue he's aware of in certain "high polygon scenes" that still needs to be resolved, that he implies might not be able to be worked around. So now everyone's freaking out of course...this MUST be the very same "high polygon bug" that's the root of every other identified issue on the Radeon....so nothing else is ever going to get fixed. :rollseyes:
For all we know, there are several issues that may or may not be related, may or may not be hardware, driver, or application issues, with any one may or may not ever get satisfactorally resolved.
Most people don't like to consider how complicated the whole "hardware / Driver / OS / Application" relationship is, and prefer to oversimplify and peg their "hopes" (All will be fine once the high polygon bug is fixed), or criticisms (the high polygon bug won't be fixed, so all is doomed) on a singluar target.
Problem is, it seems EVERY TIME someone finds some issue with Radeon performance, it somehow is attributed to this same "high-polygon bug." Some slow-fown issues in Serious Sam, and RTCW come to mind.
The latest is Carmack's .plan, where he states there is one issue he's aware of in certain "high polygon scenes" that still needs to be resolved, that he implies might not be able to be worked around. So now everyone's freaking out of course...this MUST be the very same "high polygon bug" that's the root of every other identified issue on the Radeon....so nothing else is ever going to get fixed. :rollseyes:
For all we know, there are several issues that may or may not be related, may or may not be hardware, driver, or application issues, with any one may or may not ever get satisfactorally resolved.
Most people don't like to consider how complicated the whole "hardware / Driver / OS / Application" relationship is, and prefer to oversimplify and peg their "hopes" (All will be fine once the high polygon bug is fixed), or criticisms (the high polygon bug won't be fixed, so all is doomed) on a singluar target.
Joe is for the most part correct on this one.
Although the issues in the ATI OpenGL drivers effect more than simply one benchmark (they also adversely effect several games), many users are simply categorizing system misconfiguration, general graphics behavior and the like and lumping it under this convenient scape-goat as a catch-all.
I originally reported and coined this problem referring to "Scene 6 - High Polygon" test in GlExcess, where the 8500 was scoring a very lowly 30-35 fps average when compared to 70+ for a Radeon 32DDR and 130+ for a GF3. There is something obviously awry with that result. Hell, even a Matrox board fares better here. :smile:
I could have equally coined it the "Scene 6" issue or "OpenGL performance" issue, but the high-polygon keyword kinda stuck on most folks. Also add the fact that when this problem occurs, disabling TCL actually improves the performance in most cases, provided there is a decent underlying CPU (which a few K6-II and P3-500 Katmai owners are still busily debating, I'm sure..)
Similar conditions can be found in distinct spots of several OpenGL games. Tribes2, RTCW, FAKK2 and others. The condition usually contrasts with 120+ fps behavior suddenly falling off to about 12-22 fps in the spots where it comes about. In the case of some of these games, it's occurance is sporadic and random. Issuing a "vid_restart" will usually cure it totally(i.e. 17 fps instantly pops to stable and everlasting 90+fps, at least until the next level load) and all is well, and some people dont run into it all. It really wreaks of a driver bug just from this angle alone.
The problem is- many more novice end users that fire up MOHAA at 1024x768x32, 2xAA, 16x anisotropy, and notice a drop in framerate in the Omaha level with explosions and insane amounts of bandwidth being gobbled up all around them instantly assumes this must be the infamous "High Poly" bug and cries wolf. Many of them simply dont understand that this is "normal" behavior and there isn't a videocard out today that doesnt show the same trend.
Others have been confusing John Carmack's latest commentary to specifically point to this "High Polygon" issue. John Carmack said he was surprised that polygon performance wasn't quite up to the level of the GF3- he didn't say that the fine folks up in Canada should hang up the videocard business all together because a Matrox Mystique was spanking this card like a red-headed step child.
So in a nutshell, this is the issue. It's likely *several* remaining issues that need to be addressed in the OpenGL drivers. Even in the games it effects, it's only in certain and distinct spots of these games, workarounds exist to help alleviate the problem, and in all cases, even a lowly Radeon 32 DDR doesn't exhibit the same behavior.
To assume that the 8500 can only muster 12-22 fps where a Radeon 32 DDR can muster 3x-4x that due to some "hardware issue" is a wrongful assumption, especially in light of the work-arounds that exist.
Although the issues in the ATI OpenGL drivers effect more than simply one benchmark (they also adversely effect several games), many users are simply categorizing system misconfiguration, general graphics behavior and the like and lumping it under this convenient scape-goat as a catch-all.
I originally reported and coined this problem referring to "Scene 6 - High Polygon" test in GlExcess, where the 8500 was scoring a very lowly 30-35 fps average when compared to 70+ for a Radeon 32DDR and 130+ for a GF3. There is something obviously awry with that result. Hell, even a Matrox board fares better here. :smile:
I could have equally coined it the "Scene 6" issue or "OpenGL performance" issue, but the high-polygon keyword kinda stuck on most folks. Also add the fact that when this problem occurs, disabling TCL actually improves the performance in most cases, provided there is a decent underlying CPU (which a few K6-II and P3-500 Katmai owners are still busily debating, I'm sure..)
Similar conditions can be found in distinct spots of several OpenGL games. Tribes2, RTCW, FAKK2 and others. The condition usually contrasts with 120+ fps behavior suddenly falling off to about 12-22 fps in the spots where it comes about. In the case of some of these games, it's occurance is sporadic and random. Issuing a "vid_restart" will usually cure it totally(i.e. 17 fps instantly pops to stable and everlasting 90+fps, at least until the next level load) and all is well, and some people dont run into it all. It really wreaks of a driver bug just from this angle alone.
The problem is- many more novice end users that fire up MOHAA at 1024x768x32, 2xAA, 16x anisotropy, and notice a drop in framerate in the Omaha level with explosions and insane amounts of bandwidth being gobbled up all around them instantly assumes this must be the infamous "High Poly" bug and cries wolf. Many of them simply dont understand that this is "normal" behavior and there isn't a videocard out today that doesnt show the same trend.
Others have been confusing John Carmack's latest commentary to specifically point to this "High Polygon" issue. John Carmack said he was surprised that polygon performance wasn't quite up to the level of the GF3- he didn't say that the fine folks up in Canada should hang up the videocard business all together because a Matrox Mystique was spanking this card like a red-headed step child.
So in a nutshell, this is the issue. It's likely *several* remaining issues that need to be addressed in the OpenGL drivers. Even in the games it effects, it's only in certain and distinct spots of these games, workarounds exist to help alleviate the problem, and in all cases, even a lowly Radeon 32 DDR doesn't exhibit the same behavior.
To assume that the 8500 can only muster 12-22 fps where a Radeon 32 DDR can muster 3x-4x that due to some "hardware issue" is a wrongful assumption, especially in light of the work-arounds that exist.
Doomtrooper
Veteran
THE BUG HAS BEEN SWATTED :smile:
BirdMadBoy
Newcomer
if the fix is already available, why carmack posted the poly bug info?
it must be a different bug then no?, otherwise he should already have had the fixed icd before updating the .plan, no?
it must be a different bug then no?, otherwise he should already have had the fixed icd before updating the .plan, no?
Doomtrooper
Veteran
This fix just was released today with the latest Dev leak.
BirdMadBoy
Newcomer
that´s what i´m referring to, if ati has a new icd that fixes the bug, why carmack wasn´t aware of it knowing how influyent carmack´s words are. Ati should have tell carmack that the fix was coming before carmack updating the .plan
More than likely the two issues aren't even related. As Joe mentioned, there are so many variables and issues that can crop up with hardware, it's hard to tell if one thing is related to the other.
What I don't seem to understand is why so many people get all upset over some hardware issues with the R8500, when every new generation of a chip will have them. Been the case ever since the birth of the 3D graphics industry, far as I can tell.
What I don't seem to understand is why so many people get all upset over some hardware issues with the R8500, when every new generation of a chip will have them. Been the case ever since the birth of the 3D graphics industry, far as I can tell.
Ok Doomtrooper,tb and Co.
What's curent state of performances with these "St. Valentine" Drivers:
http://support.ati.com/drivers/winxp/winxp_radeon_613106015.html
I'm in process of decision making (GF3Ti200vs8500LE) so I'm eager to find out how are the new drivers progressing (or maybe they do not?)
<font size=-1>[ This Message was edited by: Sunday on 2002-02-15 00:15 ]</font>
What's curent state of performances with these "St. Valentine" Drivers:
http://support.ati.com/drivers/winxp/winxp_radeon_613106015.html
I'm in process of decision making (GF3Ti200vs8500LE) so I'm eager to find out how are the new drivers progressing (or maybe they do not?)
<font size=-1>[ This Message was edited by: Sunday on 2002-02-15 00:15 ]</font>
Doomtrooper
Veteran
Sunday,
Best place is Rage3D,just browse the 8500 section. I have no issues besides the poly bug thats now fixxed, but not in that driver release, next beta release.
Best place is Rage3D,just browse the 8500 section. I have no issues besides the poly bug thats now fixxed, but not in that driver release, next beta release.
Nobody, as in NOBODY cares about the score in scene 6. It is _only_ useful as a diagnostic tool. Whether that particular problem can be solved or not remains to be seen, but has little meaning in and of itself.
A lot more people care about how the 8500 will perform in games based on the new DOOM3 engine. I cannot imagine that if ATI had a fix for this problem, they would inform Carmack, and he would update his .plan.
This hasn't happened.
The way he phrased it made it sound as if ATI had identified a hardware problem, that they didn't think they could create an effective driver workaround for.
The 8500 should still be able to run games based on the new engine, but will perform below expectations (which, on the other hand, were quite high).
Entropy
A lot more people care about how the 8500 will perform in games based on the new DOOM3 engine. I cannot imagine that if ATI had a fix for this problem, they would inform Carmack, and he would update his .plan.
This hasn't happened.
The way he phrased it made it sound as if ATI had identified a hardware problem, that they didn't think they could create an effective driver workaround for.
The 8500 should still be able to run games based on the new engine, but will perform below expectations (which, on the other hand, were quite high).
Entropy
>>"A lot more people care about how the 8500 will perform in games based on the new DOOM3 engine."<<
I'd simply raise that even a lot MORE people care about how the games sitting on their harddrives right now perform. I'd think what they are running now would take a slight preference over something that may not hit the shelf for another 6 to 8 months minimum.
That's the very nature of this issue.
And the drivers posted Feb 14th (today)- they couldn't possibly fix this bug as they are older than the alleged "fix" report. They are simply much older drivers that have been MS WHQL certified.
I also heard these OGL bugs were fixed back in December, January and now. The moderator/report in early January was also accompanied by scores... then shortly thereafter was edited to remove the scores.
Cheers,
-Shark
I'd simply raise that even a lot MORE people care about how the games sitting on their harddrives right now perform. I'd think what they are running now would take a slight preference over something that may not hit the shelf for another 6 to 8 months minimum.
That's the very nature of this issue.
And the drivers posted Feb 14th (today)- they couldn't possibly fix this bug as they are older than the alleged "fix" report. They are simply much older drivers that have been MS WHQL certified.
I also heard these OGL bugs were fixed back in December, January and now. The moderator/report in early January was also accompanied by scores... then shortly thereafter was edited to remove the scores.
Cheers,
-Shark
the bug is gone with the latest drivers (winxp 6043).
I did some benchmarks: http://www.tommti-systems.com/start.html
Thomas
I did some benchmarks: http://www.tommti-systems.com/start.html
Thomas
Doomtrooper
Veteran
Very Nice Thomas..thx for the update...I fail to see a link for those drivers on your webpage though
