|The following information provides a brief explanation as to what the terms used to specify graphics cards mean.|
|DX6 or earlier||DX7 (TnL)||DX8 (SM1.1)||DX9 (SM2.0)||DX9 (SM3.0)||DX10 (SM4.0)||DX11 (SM5.0)||DX12 (SM6.0)|
|3D Graphics Card Specifications - Terminology|
|Core process scale||
This value refers to the size of the general components, such as a transistor, inside the chip core. Other components, such as interconnects, may be larger or even smaller than this. The units of nm are nanometres or 0.000000001 metres.
|Core transistor count||
This value, given by the manufacturer, refers to the approximate number of transistors within the processing core and does not include those found within the memory chips or other components on the circuit board. Vendors often count up the transistors via different methods, so directly comparing one product to another is not always possible.
|Core clock speed||
This is the main operating clock speed of the processing chip, when in full 3D mode. Certain models have different speeds for 2D mode only, as well as separate clock speeds for the vertex pipelines or the raster operation pipelines (ROPs). Different AIBs (add-in board) vendors may often produce models that have higher or lower clock speeds than the ones listed here.
|Vertex processing pipelines||
This is the number of discrete vertex processing pipelines within the graphics chip. Some models have arrays of arithmetic logic units (ALUs) instead of separate ones though and hence, cannot be given a "pipeline count" so easily. Unlike pixel pipelines, one cannot directly calculate the theoretical vertex throughput of a chip by multiplying the vertex pipeline count and the clock speed - however, more pipelines = more performance.
|Vertex shader version||
There are various ways of processing vertices but they can be initially grouped into two categories - software and hardware. Some older graphics chips do all vertex processing via the CPU (software) but the drivers will report that the "hardware" might capable of doing vertex shaders; this is because a modern CPU can do vertex processing to a reasonable degree of speed (although true hardware is still better). DirectX (and similarly, OpenGL) has offered a range of vertex processing models over the years. DirectX 7 first gave us what is now called hardware T & L - transform and lighting. DirectX 8 gave us vertex shaders 1.0 and 1.1, and DirectX 9 has vertex shaders 2.0, 2.0 Extended (2.x) and 3.0.; DirectX 10 offers geometry and vertex shaders 4.0. DirectX 11 introduced VS (vertex shaders) 5.0 and 5.1; DirectX 12 provides VS 6.0 and 6.1
The difference between the models mostly involves levels of programmability and flexibility, but not always greater performance. Vertex shaders perform movement and lighting calculations on individual vertices; geometry shaders do likewise but on groups of vertices - they also have the ability to add or remove vertices from a group. Graphics cards that offer hardware support of one vertex processing model will always support models of a lower level (i.e. if it offers VS2.0 it can do VS1.1, VS1.0 and hardware TnL).
|Pixel processing pipelines||
This is the number of discrete pixel processing pipelines within the graphics chip. One can directly calculate the theoretical pixel processing throughput of a chip by multiplying the pixel pipeline count and the clock speed - more pipelines = more performance. Do note that these pipelines are not responsible for writing the final pixel value to memory, so the actual fill rate of the graphics card can differ from the above calculation.
|Total effective no. of texture units||
Texture samplers (sometimes called TMUs) are units within the pixel processing stage of a graphics chip that are responsible for fetching values from texture maps (either in cache or memory) and then blending them together in a process called filtering. Some sampler units are also responsible for processing texturing operations and address calculations, whereas other models use ALUs in the pixel pipelines to do this. Having more texture samplers allows a graphics chip to fetch and blend more texels per clock cycle but this may always result in greater performance, as the chip may be spending lots of cycles processing a shader anyway.
|Max pixels output per clock||
This value refers to the maximum number of pixels the graphics chip can write, per clock cycle, into either a colour buffer or depth buffer in the local memory. The figure is decided by the number and architecture of the ROPs (raster operation pipelines); these units handle processed pixels from the pixel pipelines, reading and writing them to memory, blending values and compressing them.
Some chip designs may have ROPs that have separate and dedicated units for handling colour and depth pixels - these chips will have the same value for colour and depth, e.g. 12 / 12. Other models have colour units that can double as depth units, when no colour operations are taking place, and therefore have values such as 12 / 24.
|Pixel shader version (best)||
Unlike with vertex processing, pixel processing needs to be done in hardware due to the demands of modern games. In the early days of 3D games, most of them offered a software rendering option but today, one needs to have a 3D graphics hardware acceleration chip - aka, a graphics card. This is because the calculations involved are not particularly suited to a general purpose processor, such as a CPU. DirectX (and similarly, OpenGL) has offered a range of pixel processing models over the years. DirectX 1 to 7 first gave us what is now called fixed function pixel processing. DirectX 8 gave us pixel shaders 1.0 and 1.1, DirectX 8.1 offered pixel shaders 1.2, 1.3 and 1.4 and DirectX 9 has pixel shaders 2.0, 2.0 Extended (2.x) and 3.0. DirectX 10 supports PS (pixel shaders) 4.0 and 4.1; DirectX 11 offers PS 5.0 and 5.1; DirectX 12 provides PS 6.0 and 6.1.
The difference between the models mostly involves levels of programmability and flexibility, as well as higher degrees of colour precision, but not always greater performance. Pixel shaders perform calculations that determine the final colour of a pixel - some operations require the use of textures, others run equations that model how light reflects or refracts from a material. Pixel processing is an important part of most modern 3D games and a GPU will spend more time running pixel shaders than most other operations.Graphics cards that offer hardware support of one pixel processing model will always support models of a lower level (ie. if it offers PS2.0 it can do PS1.4, PS1.3, PS1.2, PS1.1, PS1.0 and FF).
|Overall DirectX level||
This value refers to the overall level of compliancy to a certain DirectX revision. For example, to be counted as DirectX 7 level the hardware must offer hardware TnL (as well as many other things); for DirectX 8.1 the hardware must support shader models 1.0 through to at least 1.2 and higher. Some models support an insufficient range of features to be classed at a certain level even though they do have some higher level items.
|Memory interface width||
This value refers to the maximum number of data bits that can be transferred across the external memory bus (ie. between the graphics chip and RAM) per clock cycle. Some models use system memory for local memory, so the interface width refers to the size of system memory bus, and not the graphics interface (such as AGP).
|Memory interface type||
The type of memory chip, and hence memory interface, used for the onboard RAM is given by this value. In all cases, the memory used is a form of DRAM. In terms of what is best, a rough order of hierarchy (starting with the slowest first) is EDO, SDR, GDDR, GDDR2 and finally GDDR3.
|Memory clock speed||
This is the operating clock speed of the main timing line for the memory interface (i.e. the CLK strobe). The memory chips themselves may actually operate slower or faster than this speed; some types of memory such as DDR-SDRAM can transfer two batches of data for one cycle of the CLK line - this happens because another timing mechanism, linked to the CLK line, runs at a higher clock speed (in the case of DDR, twice as fast).
|Vertex processing rate||
This value, given by the manufacturers, refers to the maximum number of vertices that can be processed by the vertex stage of the graphics chip in one second - the units are millions of vertices (Mverts) per second. Such figures are almost certainly not going to be achieved in real situations because each vertex will receive a considerable amount of processing before being passed on to the pixel pipelines; hence the genuine vertex or polygon throughput will be much lower. The higher this number is, the better the graphics card will be at handling games with lots of complex scenes, models and detail. The figure is given in millions or billions of vertices processed per second - Mverts/sec or Gverts/sec.
|Pixel processing rate||
This value tells you how many pixels the pixel processing stage of the GPU can throughput to the ROPs as a maximum value. Such figures are almost certainly not going to be achieved in real situations hence the genuine pixel throughput will be much lower. The higher this number is, the better the graphics card will be at handling games with lots of complex visual effects; it also means that it will be able to handle higher resolutions. The figure is given in millions or billions of pixels processed per second - Mpixels/sec or Gpixels/sec.
|Texel applied rate||
This value is the maximum number of texture map elements (texels) that can be applied, in total, per second - the units are millions of texels per second. This figure is calculated by multiplying the total effective number of texture units by the core clock speed of the chip. Some graphics chips work differently compared to whether they are applying multiple texture layers on different pixels, multiple texture layers on the same pixel or just one texture layer. The higher this number is, the better the graphics card will be at handling texture filtering, such as anisotropic filtering (AF). The figure is given in millions or billions of texels applied per second - Mtexels/sec or Gtexels/sec.
|Pixel output rate||
This value is the maximum number of pixels that the graphics chip could possibly write to the local memory in one second - the units are millions of pixels per second. The figure is calculated by multiplying the number of colour ROPs by the clock speed of the chip (or ROPs, if they have a difference speed to the rest of the chip). Some graphics chips may have more pixel pipelines than they do ROPs, so they can process more pixels than they can write to memory but since the former normally takes quite a few cycles in a modern game, there is no hurry to write pixels.
The actual pixel fill rate is also dependent on many other factors, most notably being the memory bandwidth - as that value gets lower, so the potential to reach the maximum fill rate is reduced. The higher this number is, the better the graphics card will be at handling higher resolutions and anti-aliasing (AA). The figure is given in millions or billions of pixels completed per second - Mpixels/sec or Gpixels/sec.
This value tells you the maximum amount of data that can be possibly transferred across the external memory interface in one second - the units of gigabytes per second (billions of bytes). The figure is calculated by multiplying the interface width by the memory clock speed; in the case of DDR-type memory, the equation needs an additional multiplying factor of 2. Memory bandwidth is crucial for processes such as anti-aliasing, anisotropic filtering and HDR (higher dynamic range rendering).
In general, most graphics cards just don't have enough bandwidth and nearly any card can be in a bandwidth-limited situation, such as high level AA applied at high resolutions. The higher this number is, the better the graphics card will be in general - most graphics card operations need to use the local memory, but a high bandwidth will help out with higher resolutions and high level AA. The figure is given in millions or billions of bytes per second - MB/sec or GB/sec (note that M and B refer to the SI prefixes).
|3D Graphics Card Specifications Terminology - Copyright © - N D Evanson|