ATI Radeon 9500/9700 demo compatibility
category: general [glöplog]
I've been in the Nvidia camp for a few years since they seem to be the best in terms of drivers and performance. But tomorrow I will have a Radeon 9500 on my doorstep and plan on running tons of demos on it to beat the living hell out of the drivers, since it seems not much has been said about the compatibility of said manufacturer's drivers on PC demos/intros.
If I'm bored enough I plan on writing down the results of every demo I have archived on CD here (not as much as it sounds, they easily fit on a single disc but anyway, they're the cream of the crop IMO).
I'll post them up here after I get tired of running them or my computer explodes.
If I'm bored enough I plan on writing down the results of every demo I have archived on CD here (not as much as it sounds, they easily fit on a single disc but anyway, they're the cream of the crop IMO).
I'll post them up here after I get tired of running them or my computer explodes.
we dont care, demos not working on a r9500 or a r9700 obviously sucks ass
On the R9700 I've only encountered problems with planet loop. (On the R8500 things are a little worse, a few demos doesn't look quite right there)
out of my small collection of 35 recent demos, only 2 dont work on my 9700. (which used pixel and vertex shaders)
I had an nvidia Riva TNT2 Ultra, i uninstalled the card, installed DX9, installed the Catalyst 3 drivers, and it just worked, simple. I was amazed. And this is on a revision A dual AMD board. in AGP4x.
I guess, when you read the messageboards, you only ever hear from people who have problems, very rarely does anyone post to say, 'wow, its great!'
So, for me, it works fine, no issues really.
I had an nvidia Riva TNT2 Ultra, i uninstalled the card, installed DX9, installed the Catalyst 3 drivers, and it just worked, simple. I was amazed. And this is on a revision A dual AMD board. in AGP4x.
I guess, when you read the messageboards, you only ever hear from people who have problems, very rarely does anyone post to say, 'wow, its great!'
So, for me, it works fine, no issues really.
I'm getting a r9500 as well, for the sole purpose of watching DXM intros.(*) I don't really expect any problems, since NVidia-cards like gf3 actually have more undocumented 'features' than the r9500 family.
(*) One of the two statements in this sentence is a lie.
(*) One of the two statements in this sentence is a lie.
I didn't try any of the below demos on DirectX 8.1. The artifacts and crashing might be
due to DirectX 9.0 or the ATI Catalyst 3.0 drivers. Either way, the world is moving toward
9.0 so I chose to test them under this configuration.
AND squish works
buenzli11 music influence works
mfx a deepness in the sky crashes on load
farbrausch poem to a horse works
farbrausch the product works
farbraush ein.schlag works, very minor artifacts? (4)
frogwize pandalization works
haujobb elements works
haujobb liquid wen works, very minor artifacts? (3)
haujobb mosaik works
kewlers variform works
mfx a fire upon the deep works
moppi productions gerbera works
moppi productions halla works, minor artifacts (1)
orange the nonstop ibiza experience works
orion purple works
popsy team vip2 works
smash designs arenalin works
threepixels nature v2.0 works, minor artifacts (2)
t-rex your scientists invented electricity works
tpolm moral hard candy works
1) Some clipping / lighting errors. Certain polygons are lit when they shouldn't be,
other's aren't lit when they should be.
2) Scene with waterlillies has a mesh of semi-translucent parallelograms overlayed on the screen,
they should be transparent.
3) Lines where polygons seams don't meet up in the screen warping in last scene. Actually don't
remember if this intentional or not. Been a long time since I ran it on my GeForce 2.
4) Texture pallette on a few textures are wrong. Textures look silver when they shouldn't.
due to DirectX 9.0 or the ATI Catalyst 3.0 drivers. Either way, the world is moving toward
9.0 so I chose to test them under this configuration.
AND squish works
buenzli11 music influence works
mfx a deepness in the sky crashes on load
farbrausch poem to a horse works
farbrausch the product works
farbraush ein.schlag works, very minor artifacts? (4)
frogwize pandalization works
haujobb elements works
haujobb liquid wen works, very minor artifacts? (3)
haujobb mosaik works
kewlers variform works
mfx a fire upon the deep works
moppi productions gerbera works
moppi productions halla works, minor artifacts (1)
orange the nonstop ibiza experience works
orion purple works
popsy team vip2 works
smash designs arenalin works
threepixels nature v2.0 works, minor artifacts (2)
t-rex your scientists invented electricity works
tpolm moral hard candy works
1) Some clipping / lighting errors. Certain polygons are lit when they shouldn't be,
other's aren't lit when they should be.
2) Scene with waterlillies has a mesh of semi-translucent parallelograms overlayed on the screen,
they should be transparent.
3) Lines where polygons seams don't meet up in the screen warping in last scene. Actually don't
remember if this intentional or not. Been a long time since I ran it on my GeForce 2.
4) Texture pallette on a few textures are wrong. Textures look silver when they shouldn't.
PS- front243, that is exactly why I bought this card in particular :)
If I'm not mistaken, all productions that you mentioned above, that had problems, were OpenGL.
I'm starting to see a pattern here.
Theory #1:
ATi drivers are buggy as hell.
Argument against that theory is that the above list contains a lot of OpenGL productions that DID work.
Theory #2:
OpenGL coders are generally less experienced than their D3D-colleagues, when it comes to writing reliable code.
Not sure how you can either prove or disprove this theory.
Theory #3:
OpenGL coders are often nVidia fanboys and code only for nVidia-extensions, and don't care about people with other display cards at all, because they're not l33t anyway.
Theory #4:
OpenGL coders are often linux fanboys and code only for linux, and don't care about people with other OSes at all, because they're not l33t anyway. They do however hack icky ports together with their lack of Windows-experience.
Theory #5:
I'm just bored, so I do what every other scener would do in my situation: write nonsense and/or start a flamewar
:)
I'm starting to see a pattern here.
Theory #1:
ATi drivers are buggy as hell.
Argument against that theory is that the above list contains a lot of OpenGL productions that DID work.
Theory #2:
OpenGL coders are generally less experienced than their D3D-colleagues, when it comes to writing reliable code.
Not sure how you can either prove or disprove this theory.
Theory #3:
OpenGL coders are often nVidia fanboys and code only for nVidia-extensions, and don't care about people with other display cards at all, because they're not l33t anyway.
Theory #4:
OpenGL coders are often linux fanboys and code only for linux, and don't care about people with other OSes at all, because they're not l33t anyway. They do however hack icky ports together with their lack of Windows-experience.
Theory #5:
I'm just bored, so I do what every other scener would do in my situation: write nonsense and/or start a flamewar
:)
ein.schlag was D3D
nature v2.0 is also D3D
It could be the fact I am using DirectX 9, and its associated drivers. If someone would care to run some demos on a 9500/9700 with DirectX 8.1 and compare results, that would be pretty interesting. Unfortunately, it's kind of a pain to revert back to 8.1 and 9.0 isn't all that bad anyway. :)
I was just fumbling through the Catalyst 3.0 driver control panel and noticed I accidentally had 16x Anisotropic filtering enabled. I moved the setting to "Application Preference" and re-ran all the demos that previously contained graphics bugs.
threepixels nature v2.0 works (bug is gone)
As for the others...
moppi productions halla - Obviously a bug. Grandma's face and the girl's toys flicker yellow
farbrausch ein.schlag (fr-022) - On second thought, I don't know if this is a bug or the demo is just ugly :). Could someone tell me if the object pounding the ground at the beginning has a silver textured shape wrapped around it? Also are there grey spots on the floor where it is being pummeled? If so, then there is no bug. If not, then there is.
haujobb liquid wen - No change. Although I would like someone to confirm the previously mentioned bug by running the demo on an Nvidia card. Almost at the very end of the demo, there is some wavy melting effects applied to the screen. At the boundaries of the effects are thin black seams/lines. The wavy effects at the beginning of the demo work just fine, which is why I want to doublecheck. It's been a while since I ran this on my GeForce2 so I forgot how that part goes but for now I'm chalking it up as a bug.
mfx a deepness in the sky - No longer crashes, but it is completely unwatchable. Your screen becomes a 10 pixel horizontal combing effect between your desktop and the demo. It's definitely running though, I can hear the music, and see stuff happening. It exits out to the desktop fine and doesn't lock up the machine.
Well, that's about all there is to say. The Radeon 9500 is a lot more compatible than I thought it would be and really fast. It sure makes my GeForce2 look pretty old and crusty.
Here's the final tally:
Total demos: 21
Working: 17
Working w/ very slight bugs: 2
Working w/ unconfirmed slight bugs: 1
Not working: 1
threepixels nature v2.0 works (bug is gone)
As for the others...
moppi productions halla - Obviously a bug. Grandma's face and the girl's toys flicker yellow
farbrausch ein.schlag (fr-022) - On second thought, I don't know if this is a bug or the demo is just ugly :). Could someone tell me if the object pounding the ground at the beginning has a silver textured shape wrapped around it? Also are there grey spots on the floor where it is being pummeled? If so, then there is no bug. If not, then there is.
haujobb liquid wen - No change. Although I would like someone to confirm the previously mentioned bug by running the demo on an Nvidia card. Almost at the very end of the demo, there is some wavy melting effects applied to the screen. At the boundaries of the effects are thin black seams/lines. The wavy effects at the beginning of the demo work just fine, which is why I want to doublecheck. It's been a while since I ran this on my GeForce2 so I forgot how that part goes but for now I'm chalking it up as a bug.
mfx a deepness in the sky - No longer crashes, but it is completely unwatchable. Your screen becomes a 10 pixel horizontal combing effect between your desktop and the demo. It's definitely running though, I can hear the music, and see stuff happening. It exits out to the desktop fine and doesn't lock up the machine.
Well, that's about all there is to say. The Radeon 9500 is a lot more compatible than I thought it would be and really fast. It sure makes my GeForce2 look pretty old and crusty.
Here's the final tally:
Total demos: 21
Working: 17
Working w/ very slight bugs: 2
Working w/ unconfirmed slight bugs: 1
Not working: 1
I have a 9700 pro and haven't built an extensive list of demos that don't work properly, but there is one consistent thing I've seen across many demos. With the 9700 pro its possible to have the desktop extend across multiple monitors. When I do this, things get wierd. If I restrict the desktop to a single monitor, then things generally go as expected.
I upgraded a friend's computer to a GF3. Some demos have problems there as well, so the problem of demos not running properly is not limited to a particular HW vendor.
The amount of available memory can also make a demo behave very strangely, regardless of HW. One example is Adrenalin by Smash Designs, which is quite the memory pig. The display of this demo will be erratic on machines without enough memory.
Back to the Radeon9700... if you encounter any problems with demos, please use the Problem Report Wizard (can be launched from the Help docs for the system tray ATI applet) and send a description of the problem to devrel@ati.com.
They certainly can't make things better if noone reports the problem.
I upgraded a friend's computer to a GF3. Some demos have problems there as well, so the problem of demos not running properly is not limited to a particular HW vendor.
The amount of available memory can also make a demo behave very strangely, regardless of HW. One example is Adrenalin by Smash Designs, which is quite the memory pig. The display of this demo will be erratic on machines without enough memory.
Back to the Radeon9700... if you encounter any problems with demos, please use the Problem Report Wizard (can be launched from the Help docs for the system tray ATI applet) and send a description of the problem to devrel@ati.com.
They certainly can't make things better if noone reports the problem.
Almost forgot... aside from the extended desktop thing, the vast majority of demos work fine, AFAICT.
Re: the yellow flicker, are you running the debug D3D runtime? If so, try switching to the retail runtime. I've seen a number of demos that "flash" when the debug runtime is selected because IT IS A BUG IN THE DEMO.
You are supposed to touch every pixel of the back buffer before you call Present. The ugly colors flickering indicates that the demo didn't touch every pixel and the debug runtime puts an obnoxious color in there to alert you to this problem.
You are supposed to touch every pixel of the back buffer before you call Present. The ugly colors flickering indicates that the demo didn't touch every pixel and the debug runtime puts an obnoxious color in there to alert you to this problem.
thats not a bug, thats nicely optimized code >P
the flicker is just a warning
the flicker is just a warning
As a matter of fact, I have the "Catalyst Crew" website open right now to report these demo bugs to the driver developers.
About DX9, I am using the retail version.
I'm starting to really like this 9500 card BTW.
About DX9, I am using the retail version.
I'm starting to really like this 9500 card BTW.
stefan: no, its a bug. You must touch every pixel in the back buffer before you call Present if you use the discard swap effect. Failing to do that is a bug. Its like using an uninitialized variable. It may work by accident if you're lucky enough that the memory assigned to the variable happened to be zero, but that doesn't mean its not a bug.
http://www.xbitlabs.com/news/story.html?id=1042058170
Lepper: it would be nice to have some screenshots about the 'bugs'.
I agree with legalize, and so does the D3D SDK ;)
Use D3DSWAPEFFECT_FLIP or D3DSWAPEFFECT_COPY if you don't draw the entire screen.
D3DSWAPEFFECT_DISCARD does NOT, I repeat NOT guarantee that your new backbuffer is a previous frontbuffer, so you can make NO assumptions about its contents.
Which does make it a SEVERE bug, even though on common hardware DISCARD is effectively the same as FLIP.
So well, rtfm :)
Use D3DSWAPEFFECT_FLIP or D3DSWAPEFFECT_COPY if you don't draw the entire screen.
D3DSWAPEFFECT_DISCARD does NOT, I repeat NOT guarantee that your new backbuffer is a previous frontbuffer, so you can make NO assumptions about its contents.
Which does make it a SEVERE bug, even though on common hardware DISCARD is effectively the same as FLIP.
So well, rtfm :)
you can surely know whats there if you count before, since you know yourself how many backbuffers you create.
And afaik, you get this "bug" even if you dont use multiply backbuffers, and then even a dane could calculate whats in there...
And afaik, you get this "bug" even if you dont use multiply backbuffers, and then even a dane could calculate whats in there...
I quote from the DX SDK docs:
An application that uses this swap effect cannot make any assumptions about the contents of a discarded back buffer and should therefore update an entire back buffer before invoking a Present operation that would display it. Although this is not enforced, the debug version of the runtime will overwrite the contents of discarded back buffers with random data to enable developers to verify that their applications are updating the entire back buffer surfaces correctly.
That's more or less what I said above... You can NOT assume anything about the backbuffer when using DISCARD. The driver may well allocate a new backbuffer instead of giving you the next one in the chain (discarding the used backbuffers). When you use DISCARD, you say "Okay, that's what I want. I don't need the old contents anyway, so cut out the extra overhead". If you DO want a real swap chain, use FLIP...
Else the debug runtime will fill the backbuffer with some nice RGB (I wonder if there's Dutch guys on the DX team) to tell you "But you discard your backbuffers, you can't assume that you get an old backbuffer, of which you know the contents! Look, this is what can happen!".
So, yes it is a bug, and yes it is a case of RTFM.
If you want to count your backbuffers and want to know what is in them, use FLIP, not DISCARD, as the docs so clearly tell you.
An application that uses this swap effect cannot make any assumptions about the contents of a discarded back buffer and should therefore update an entire back buffer before invoking a Present operation that would display it. Although this is not enforced, the debug version of the runtime will overwrite the contents of discarded back buffers with random data to enable developers to verify that their applications are updating the entire back buffer surfaces correctly.
That's more or less what I said above... You can NOT assume anything about the backbuffer when using DISCARD. The driver may well allocate a new backbuffer instead of giving you the next one in the chain (discarding the used backbuffers). When you use DISCARD, you say "Okay, that's what I want. I don't need the old contents anyway, so cut out the extra overhead". If you DO want a real swap chain, use FLIP...
Else the debug runtime will fill the backbuffer with some nice RGB (I wonder if there's Dutch guys on the DX team) to tell you "But you discard your backbuffers, you can't assume that you get an old backbuffer, of which you know the contents! Look, this is what can happen!".
So, yes it is a bug, and yes it is a case of RTFM.
If you want to count your backbuffers and want to know what is in them, use FLIP, not DISCARD, as the docs so clearly tell you.
i thought it occoured everytime (random data) even if you used flip.. perhaps not.. =)