Two gfx Cards Stress Programs for the OC lovers.

As title stated I have just came across two programs that was designed to stress your card which makes them good for checking stability of OC'ed cards.
This is of course for those who does not know about these amazing programs.

First up: rthdribl
from rthdribl website

Screenshots:







LINK:

Second Up: Fur Test from Ozone3D.NET

Screenshot: Only 1.

Link:

I found the fur test to be more stressing to the GPU. However, the first benchmark tool looks alot nicer.

P.S. I am in a hurry at the moment will add more info when I get back.

 

Except that both only test very specific and limited parts of the GPU.
Primarily, the fragment shaders.

Vertex shaders and geometry shaders (if you have support for those) will stay pretty much unused, so you won't know if they can handle being stressed.
You also won't see much bus traffic, the rasterizer *may* not be put to good use as you probably won't be fillrate limited in either of those demos, and so on.

It certainly won't hurt to try these demos, but don't assume that they actually test whether your GPU is stable. For that you need a wide range of different tests. 3dMark is probably a better all-round test for this, especially when combined with a handful of different games. (Not just the fragment-shader heavy ones with HDR and motion blur plastered all over them, but also ones with huge numbers of polygons being thrown around. Even something like a RTS (or another game that doesn't scream "next-gen graphics" may be a good test of some parts of the GPU.
In short, advanced lighting and HDR and such is not enough to test the stability of your GPU. On the contrary, it's a very lopsided test that leaves large parts of the GPU almost unused.

I also find it amusing that the first demo seems to be ripped almost straight from the Direct3D SDK... The font is different, but that's about the only difference I can see...

 

Agreed with Jalf, you need something like i.e 3D Mark 06 that should do everything.

I have not used Direct3D SDK in a long time, heh.

 

Thanks for the info Jalf, I really learned something new today.
Just a few questions:
1. Both demos allowed the use of AA doesn't that push bus bandwidth as AA is very memory intensive?
2. What is a rasterizer and what is it's function?
3. In what scenario would vertex and geometry shaders being used?
4. Since the new 8-series cards use unify shaders, as long as all shaders were push to task it would still "test" the stability of the card. Is the above statement correct?

I only thought these were good gfx stressers because other forums and member of this forum had mentioned using these programs at one time to test out their OC'ed cards. Also from Personal experience running the fur test for just 10 minutes had resulted in a higher temperature for my card than any other recently released game I have played. I am sorry for any misunderstanding that my post could have caused but that's why I am here, I am here to learn.

 

Hard to say for sure. You could be right as far as the GPU memory bandwidth is concerned, but I was thinking of the system RAM <-> GPU bus.
It also depends on how much you need to antialias. Of course, the lower the framerate, the less antialiasing is necessary (because it's done for each frame)

The bit that goes in between the vertex shader and fragment/pixel shaders.
Basically, it takes a triangle, and figure out which pixels (or, technically speaking, fragments) should be rendered as part of it. This is where fill rate comes into the picture. It's basically how many pixels the rasterizer has time to spit out. Now, the screen only contains a couple of million pixels, so that in itself is no big deal. The problem is when you have a lot of overdraw. If you first render the sky, say (that's a full screen's worth of pixels), and then after that, you render the terrain over it. And then the buildings. And so on. You end up layering the same pixels multiple times, so the number of fragments that have to be processed is far greater than the ~2,000,000 that are shown on the screen, which may stress the rasterizer. On the other hand, the scenes you showed have little overdraw (because they're basically just showing a single object), but instead each pixel has a hugely expensive pixel shader. But the total number of fragments rendered is fairly small.

Geometry shaders are DX10 only, so they don't get used much. They're basically for generating new geometry on the fly. The only example I can think of is a NVidia demo I saw which generated icicles by taking a small circle, and extruding that downwards, creating new vertices clustered closer and closer together the further down it went.

More important is the vertex shader. That's used on each vertex in the scene. Each polygon is made up of 3 vertices (the corners), so when you have few polygons, you have few vertices. So if you want to stress this, you need something with a really high polygon count. (And preferably very simple pixel shader effects, because those easily become the bottleneck instead)

Partly.
True, all the shader units would get utilized, but they wouldn't get to use all their functionality. Vertex and pixel shaders tend to emphasize different instructions, and the ones that are (mostly) used for vertex shaders wouldn't get tested as heavily. Still, you're right it should test all shader units to *some* extent at least.

Well, they look pretty, which is always an advantage in tests you're going to run for extended periods.
And since the pixel shader is usually the one that carries the greatest load, they certainly will test large chunks of the CPU.
Don't get me wrong, these tests definitely do stress the GPU. They just don't stress every single part of it. And some of those other parts may be the ones that get unstable when you overclock. You never know.

Remember when Doom 3 came out? A lot of people complained of instability. It turned out, after a lot of testing, that it was simply that Doom 3 stressed different parts of the GPU in their shaders than most games. So it highlighted instabilities that people hadn't detected otherwise.

The bottom line isn't that these demos are bad, just that to really test the GPU, you need to feed it a varied diet. Something with big expensive per-pixel effects like these demos, something with a ton of triangles, something with billions of different models and so on. And even some tests that look less complex (because that way they won't be held back by the pixel shaders, so they'll be better able to fully test other parts of the GPU)
Even a semi-old game like Half-life 2 may be worth running, because it'll be able to reach much higher framerates, so it'll have to process a lot of geometry in a lot of scenes very quickly.