Introduction

In our original article on the dissection of R300 we considered the key elements of the 3D pipeline, including the pixel and vertex shading. We also looked at some of the more advanced features, including HyperZ III and SmoothVision 2.0. In doing that, we came to a better understanding as to how R300 operates.

When we originally planned this article, it was our intent to show how each of the different aspects of HyperZ brought about performance benefits. There was no anticipated problem with this, as a variety of registry strings were made available to allow for enabling and disabling these features.

Unfortunately, sometimes things simply do not work as planned, and this was one such case. While the necessary strings exist in the registry, we have found that ATI has somehow disabled the functionality of those strings in that they seemingly accomplish nothing. The changing of certain values yielded inconsistent results, with generally no performance change at all. Because of this, we decided to take a slightly different approach to this article.

While we were originally going to focus on the performance benefits of the new techniques used by R300, we will instead consider what really matters: real world performance. We’re not talking about regular benchmarks, testing how fast game X is or how fast game Y is, though there is a little of that in our 3DMark tests. Rather, we will break down and closely examine R300’s capabilities in the pixel shader, vertex shader, and other areas. Doing this will allow us to find R300’s strong and weak areas.

Pixel Shading

R300 has, without a doubt, the most powerful pixel shader out there. Though only allowing for a single pixel in each rendering pass, it can write up to 8 pixels per-clock, with 3 operations in each cycle. First, let us consider R300’s peak fill-rate in an optimal environment.



With a theoretical peak of 2480 MPPS, R300 seemingly has no trouble achieving this. Much of this ability can be attributed to providing bandwidth levels capable of sustaining such a fill-rate. We do notice a slight drop-off at 1024x768 however, but this may be attributed to greater driver optimization for higher resolutions.