Installation was a fairly simple affair - although I only had two different test configurations (Super Socket 7 board and a Socket-A board). There is definitely a correlation between programmers and "techie's" - whilst it won't be universally true, the majority of people reading this review will probably be capable of at least following an instruction manual and getting it to work. 

What I was dreading was installing the drivers. Since my first PC back in 1997/8 I've had 5 different 3D cards (and no, it's not because I'm a big spender). Back in 1999 (I think), I wanted to upgrade to a then top-of-the-line ATI Rage 32mb 3D card - but I never managed to get the drivers to work, and in the end I had to return it to the shop. At the end of that day I had also tried a TNT2 but it had a broken fan (but that's another story!). I'd also, before this review, done some online research into the Radeon drivers - from the opinion I got, they are much improved from previous years but some people still seem to have problems with them.

Luckily for me, both my systems accepted the drivers first time - with no complaints. I was all prepared to get nasty with my older SS7 based computer - the Socket-7 based motherboards have never seemed to like AGP based graphics cards without at least 1 bios patch/upgrade. 

My main development machine is running Windows XP on an Athlon Thunderbird, and for the last 2 years has been absolutely rock-solid as far as driver/hardware stability is concerned. Although, in the 2 days since I installed the Radeon I've had 2 blue-screens (although WinXP just restarts the machine) shortly after startup; I have no idea if (and how) these might be linked to the Radeon, all I know is that they've only started since I put it in.

Having said that, it's not as if it's a huge problem - I've deliberately tried to stress the hardware in the last couple of days just to prove/disprove any comments on driver instability - and I've not had a single problem. I managed to get rock-solid performance from Return To Castle Wolfenstein for over 2 hours. 3DMark2001, when run 5 times back-to-back didn't cause any problems either.

3D Benchmarks

Now we're onto the important things - how exactly does the Radeon fair in real-world tests? This review is aimed squarely at developers, so I don't intend to spend ages discussing the finer points of 1001 different statistics - there are other, better, things to discuss. Should you really want to get to grips with 1000's of statistics and frame-rate scores, you should be able to find a review aimed more towards game-players on the internet.

The Test System

I decided to use my main development machine to do the tests on. I do have a Super-Socket-7/K6-2 based system available, but it is an appallingly slow piece of equipment (I sometimes doubt the 500mhz label it has). The test system:

Gigabyte GA-7ZM Via KT133 motherboard
700mhz AMD Athlon (Thunderbird Variation)
288mb PC100 RAM
15.3gb 7200rpm Maxtor DiamondMax +40 Hard drive
Microsoft Windows XP Professional Edition

Whilst I don't have the luxury of testing the card on an all-singing-all-dancing 2ghz computer, I would have preferred not too anyway. I'm sure there are plenty of you who have a turbo charged PC, but I can guarantee you that there are many more of you with a system closer to that which I have (listed above). Also, any game you develop and release in the next year or two will probably find that a high percentage of end-users will also have a similarly specified PC.

Before running this review, I had a Creative GeForce Annihilator Pro (GeForce 256 DDR chipset). Based on my 3 categories on the first page, it would fit into the 2nd, and the Radeon 8500 will fit into the 3rd. I've used my older card to provide some reference scores to compare with those of the Radeon.

3DMark2001.
The team behind 3DMark have a long history of producing benchmarking programs that really push the limits of the current generations 3D cards. It's pretty much taken to be the standard measure of performance for a 3D card. The following table gives the results for the two cards:

As you can see in the above table, the Radeon almost doubled my systems previous performance in 3D graphics at high resolutions. However, it is notable that there isn't such a performance jump at the lower end, this could be caused by other limiting factors - namely the processor not being able to feed the Radeon with enough data to keep it at top-speed.

The overall score is interesting, but I find the next two tables to be of much more use - the individual test scores:

1024x768x32

640x480x32

There are two important points to be made here relating to the overall score differences. Firstly, the Radeon has a full D3D8.1 feature set - so registers a result for every type of test (picking up points where other cards cant). Secondly, it has a very high triangle and texel throughput - 1.65 giga-texels compared with 0.43 giga-texels is a very formidable increase, combined with the high triangle throughput (upto 36.5 million triangles/s) this means that "normal" rendering (without too many fancy effects) is blisteringly fast.

This doesn't always translate into a substantially higher game score though, which is a bit odd. This is quite likely to be down to the processor not being able to process the non-graphics components (physics, maths, logic) fast enough to keep up with the Radeon. This also seemed to be the case with the overall scores not improving significantly between low and high resolutions; it may well be that in order to truly appreciate the power of a Radeon you need a processor with a fair bit of grunt.

Programming the Radeon Way

So it's now been proven that the Radeon 8500 is a very powerful piece of equipment. Playing games is therefore not going to be a huge problem, however, playing games is not even half of the issue! We want to make the games.

As mentioned on the previous page, the Radeon has plenty of powerful components making up the package, here is a run-down of how they work for us developers:

1. TruForm
TruForm is ATI's buzz-word for the high-order surfaces/primitives that were introduced in Direct3D8. It has been known for quite a while that memory bandwidth is more limiting than processor speeds - shifting the huge quantities of data around is a tough job. Therefore they invented a process of making up additional triangles inside the processor - these don't clog up the memory bandwidth, and hence don't really slow things down very much. Direct3D8 implements several forms of high-order surface ("patches") - rectanglular and triangular. TruForm works through the "N Patch" interface - you need only specify a couple of render states and parameters when creating vertex buffers and TruForm will automatically kick-in. It's therefore a very simple way of improving visual quality.

(Click to enlarge)

2. SmoothVision
This is another ATI buzz-word - for Full Screen Anti-Aliasing (FSAA). FSAA has been fairly standard in most chips for a while now, and new driver releases have made it even more uniformly available. It is with no-doubt the way forward for real-time graphics, but currently you need some very powerful hardware to use it - even 2ghz machines will still drop to 30 or 40 frames per second at medium-high resolutions when full FSAA is enabled. 

Direct3D exposes 'SmoothVision' through its "multisampling" techniques. An 8500 based card will now expose the use of either 2 or 4 multi-samples for anti-aliasing. Likewise with TruForm, it is a very simple effect to start using - a case of changing a couple of initialization/setup parameters and then turning on/off a render-state. Once this is done you can ignore it and let it get on with its job.

Newer driver and hardware revisions introduce even cleverer algorithms for using FSAA, but it really does still kill performance - using 4-sample AA 3DMark2001 registered anything from 870 to 1150 for the 1024x768x32 level tests (1/4 of normal at best). I also experienced a few intermittent crashes while experimenting with 3DMark2001 and SmoothVision - whether this is limited to just 3DMark2001 and the SmoothVision implementation is unknown, but quite likely.

Take a look at the two following screenshots from 3DMark2001's nature scene:

(Click to enlarge)

3. SmartShader and Vertex Shaders
SmartShader - Another ATI Buzzword, this one for pixel shaders. Shader technology is really the main reason why you'd be buying one of these cards - it is such a revolutionary new way of rendering graphics that even your "old" GeForce2 level cards will very quickly be left behind.

Vertex shaders can be implemented in software, whereas pixel shaders can ONLY be implemented through dedicated hardware support - so unless you have the hardware (such as this Radeon 8500) then you really won't be seeing them.

Basically, a "Shader" is a short and simple assembly-like script that the GPU applies to every vertex or pixel it processes, for those of you with plenty of D3D experience it's pretty much an extension of the traditional texture-cascade. They are pretty complicated to learn and even more complicated to master - luckily, given that they are the new "big thing" in computer graphics there is no shortage of examples and whitepapers covering their use. Real-Time Rendering Tricks and Techniques in DirectX by Kelly Dempski (reviewed here) does a good job of covering the world of shader-based rendering.

As with all things Microsoft, there are several versions of pixel and vertex shader - each one (so far) is pretty similar, with the only difference being added instructions. Vertex shaders have remained fairly constant at version 1.1 (for DirectX 8.1), but pixel shaders are already upto version 1.4. It is with pixel shaders that ATI have really been able to shine - the GeForce 4, NVidia's rival chipset only supports upto version 1.3 in pixel shader assembly. For those of you after features at the top-level, the 8500 chipset wins hands-down over the best NVidia have to offer. 1.4 is actually a considerable jump from version 1.3, and is heading much more towards the 2.0 specification due to be introduced with DirectX9; which may well put this chipset in good stead for those wishing to get a little future-proofing from their purchase.

There are very few games on the market that actually make good use of shaders - but expect the majority of the next run of AAA titles to use them a-plenty. Also, if you're the proud owner of an 8500, you too can be "playing with the big-boys" of the graphics world, the only consideration being that you'll still need to program in legacy support for older hardware - at least until pixel/vertex shaders become standard.

The 3DMark2001 Nature scene is a good example of just how impressive shaders can be. You can see screenshots of it (and other similarly good scenes) online, as you can also look at the following shots; but until you see it running fluidly on a monitor in front of you...! 

Halo (XBox), for those that have had the luxury of playing it, is one of the first good examples of using pixel and vertex shaders. Almost every texture is properly lit with realistic materials and bump-maps; all of which have been possible in one form or another without shaders, but they were usually limited to specific places - in Halo (and future titles) we will be seeing these effects on every surface in a game environment.

Probably the best graphics the Radeon has produced

Albeit an OpenGL demo, but it shows the
potential of shader usage. 

4. Point Sprites

Point sprites are the last of the new DirectX8 features that really make any difference. I wrote a tutorial on point sprites a while back, you can find it here. Basically, point sprites allow you to render fairly complex particle systems very easily. You only really need to calculate the position of the particle, place it in a vertex buffer and render it. Before point sprites you'd either of had to transform it to 2D/Screen space and render a TL quad, or mess around with billboards in 3D.

With the Radeon capable of rendering anything from 25 million to 34 million point sprites per second, it is now realistic to consider a particle system with 20,000 dynamic sprites (as long as the processor can keep up with the physics). A system with 20,000 particles could theoretically be rendered 1250 times a second - given that your average game will only hit around 60fps, it is now very unlikely that your particle system will be causing any major slow-down.

5. Traditional 3D rendering

I've now discussed the 4 main advances in Direct3D8 graphics - but that's not the only area to be interested in. You may now be able to cram as many special effects into your game as Hollywood was 5 years ago, but you still need some raw triangle rasterizing power to back all this up.

This was never going to be a problem for the Radeon - a 2nd generation Transform and Lighting engine is a considerable piece of work, and the now improved memory management allows for some very high fill rates (read: number of pixels drawn to the frame buffer).

The GeForce 256 used as a reference card in the above statistics was the first card available that implemented a hardware transform and lighting engine (the first GPU). So in comparing the fill rate and polygon throughput of the GeForce 256 with the Radeon 8500 we are in fact comparing the first ever TnL engine with one of the latest.

At high resolution, the difference is pretty incredible:
Triangle throughput has gone from 1,700,000 triangles to 8,800,000 triangles - a 5.2x increase.
Fill Rate has gone from 427,600,000 texels to 1,652,400,000 texels - a 3.8x increase
(I chose the 8 lights and multi-texturing values respectively because they are more representative of a gaming environment).

What these numbers mean to me and you is that we can yet again push the polygon budget - more detailed worlds, more detailed characters. Instead of trying to stick to the 10,000 triangle rendering limit we can now push for a 50,000 triangle limit - more room to render more objects in more detail.

6. Capability run-down

As well as all the fancy numbers exposed through various benchmarks, it is also wise to examine the feature list. Even if the card doesn't support it very well, if it has it, you can program for/with it. The following is a list taken from the "DxCaps" program supplied with the DirectX 8.1 SDK:

Max. Texture Size: 2048x2048 (with 128mb of memory, you could fit in 8 of these in 32bit mode)
Max. Simultaneous Textures: 6
Max. Active Lights: 8
Vertex Shader Version: 1.1
Pixel Shader Version: 1.4
Quintic Patches: No
RT Patches: No
N-Patches: Yes (See TruForm)
Fog: Supports all D3D8.1 types, including volumetric fog through volume textures
Z, Stencil and Alpha Tests: Supports all test values
Source Blend factors: Supports all
Dest. Blend factors: Supports all except 'D3DPBLENDCAPS_SRCALPHASAT'
Cube Maps: Supported
Volume Maps: Supported
FVF Supported Texture Coordinates: up to 6 coordinates per vertex (matches max. simultaneous tex.)
Texture Op Caps (SetTextureStageStage constants): All Supported
Compressed Textures: Supports DXT1 though to 5
Multi-Sampling: none, 2 or 4 samples
Depth Buffers: 16,24 and 32bit; 8 Bit Stencil Buffer
Texture Formats: All main 16 and 32 bit formats supported (with Alpha where appropriate)

All things considered, it's a pretty complete feature-set and can definitely call itself a DirectX8.1 graphics card. The only anomaly that caught my attention was the lack of support for Quintic and RT patches - given the trumped-up support for N-Patches/TruForm it is surprising that they didn't also implement support for these two. Not a major issue really.

I've uploaded a complete output of the DxCaps program should I have missed something you particularly wanted to check. You can find it here, bare in mind that some fields (such as supported resolutions) are limited by the monitor attached to my system.

Click here to go straight to the next page...

Or select a page from the list:
• Introduction
• Installation, Benchmarks and Programming
• ATI's Developer Resources, Conclusion