Benchmark user interface:

Liu Ren

Description

Understanding and Improving Performance of 3D Graphics
Card and Applications

Liu Ren ([e-mail])
Hua Zhong ([e-mail])

Computer Science Department
Carnegie Mellon University

1 Introduction
1.1 Importance of Graphics Hardware

In the recent three years, the graphics hardware may be the most active part in computer
hardware market with new generations of chips appeared almost every 3 months. The newest
graphics cards are equipped with a Graphics Process Unit (GPU) and very fast memory with
bandwidth over 8.0GB. Now the GPU has as many as
4 pipelines that can work parallel, and programmable
shaders that can take some workload from CPU. So
the graphics cards now is much more complex than it
is used to be and more advanced functions and
sophistic architectures have been introduced into
graphics cards. Hardware manufacturers such as
Nvidia and ATI have invented many new features to
make their cards run faster and faster. Now buying a
PC, one must consider the importance of graphics card
as much as CPU! Along with the great improvements
of graphics hardware, demands for more realistic 3D
games to exploit the fast speed of graphics chips also
Figure 1 XBox’s game DoA3 make the game market one of the most profitable
markets. The newest games of Microsoft’s Xbox
powered by a Nvidia’s special version of GeForce3 graphics chip exceeds everyone’s imagination
of how realistic current real time 3D games could be (Figure 1).
So ...

Sujets

• Problème de couverture de sommets
• Carte MS
• Bottleneck
• Linternaute.com
• Texture (cristallographie)
• Jeu de tir tactique

Informations

• Publié par: Shael
• Nombre de lectures: 127
• Langue: English
• Poids de l'ouvrage: 1 Mo

Extrait

Understanding and Improving Performance of 3D Graphics Card and Applications   Liu Ren ([e-mail]) Hua Zhong ([e-mail])   Computer Science Department Carnegie Mellon University     1 Introduction 1.1 Importance of Graphics Hardware   In the recent three years, the graphics hardware may be the most active part in computer hardware market with new generations of chips appeared almost every 3 months. The newest graphics cards are equipped with a Graphics Process Unit (GPU) and very fast memory with bandwidth over 8.0GB. Now the GPU has as many as 4 pipelines that can work parallel, and programmable shaders that can take some workload from CPU. So the graphics cards now is much more complex than it is used to be and more advanced functions and sophistic architectures have been introduced into graphics cards. Hardware manufacturers such as Nvidia and ATI have invented many new features to make their cards run faster and faster. Now buying a PC, one must consider the importance of graphics card as much as CPU! Along with the great improvements of graphics hardware, demands for more realistic 3D g m a a m k e e  s  t t h o e     ex g p a l m oi e t    t m he a   r f k a e s t t    s o p n e e e   d o   f o   f t   h g e r   ap m h o ic st s    c p h r i o p f s it   a al b s le o     Figure 1 XBoxs game DoA3 markets. The newest games of Microsofts Xbox powered by a Nvidias special version of GeForce3 graphics chip exceeds everyones imagination of how realistic current real time 3D games could be (Figure 1). So understanding the architecture of some most advanced graphics hardware and what will be the potential bottleneck of the future graphics hardware and applications becomes more meaningful now than before. As more and more new features such as programmable shaders, hardware transform and lighting, hardware skinning have been added [5], it is none-trivial to identify what will be the future bottleneck of graphics chip now. And even we can figure out all the potential bottlenecks of a very complicated graphics card, we still need to have a clear view of what future graphics applications need most before we can determine which bottleneck is the most important one.   1.2 What Future Graphics Applications Need Figure 2 More triangles VS less triangles all 3 M D o   r a e p   p r l e i a c l a i t s i ti o c n   s a   n in d     t m he o   r f e  ut n u a r t e u . r   a S l  i i n s c   e t   h g e  e g o o m al e   tr o y f    of most objects is represented by triangles in computer graphics, to get more realistic geometric

details, we need more triangles, especially for those natural objects such as animals and human beings (Figure 2). Another most important factor to make the 3D applications more realistic is to have more detailed textures. To make viewers feel realistic even in close-up views, we must apply textures with high resolution. Both the requirement for more triangles and high-resolution textures turn out to be the demand for more memory. We can see this trend from the evolution of storage media for games: memory card, CD, to DVD in Xbox and PS2. Besides that, to make the rendered objects more realistic, we need to add more special effects such as fog, bump mapping, reflections and refractions, more sophisticated models of lighting and etc. This means more computations but CPU cant take that much burden while still working for AI and other tasks in a computer game. So using the programmable shader is a good way to take these heavy workloads from CPU. There are other trends of future graphics application such as more natural motion of characters and more realistic expressions. But here we would like to focus on the memory and programmable shaders which are definitely two most important parts for future graphics applications. Next we will identify the corresponding potential bottlenecks by showing the result of some specially designed benchmarks. Then we will provide some analyses based on the results and conclude with some suggestions for both graphics software programmers and hardware designers.   2. Memory Bottleneck 2.1 Potential Bottleneck of Memory 2.1.1 Memory Architecture of Graphics Card   There are three kinds of memories that a graphics application always uses: local video memory (memory on the card), system memory and AGP memory.    Local video memory normally consists of DDR memory or any kind of fastest memory one can get. It is directly integrated on the board, so it can be accessed by GPU at very high speed.  AGP means Accelerated Graphics Port Actually, AGP memory is a portion of main. system memory that can be accessed by CPU and graphics controller through a special AGP bus which is much faster than the standard PCI bus. With current AGP 2.0 specification, an AGP4x bus can maintain a 1GB/sec bandwidth. The goal of AGP is to use cheap system memory to compensate for the lack of high-performance but also expensive video memory. Another advantage of AGP memory is that both graphics controller and the CPU can access it very fast. Some AGP tutorials are available at [2].  System memory can be PC133 SDRAM and accessed by CPU and graphics controller though PCI bus.   These three kinds of memories dont have a hierarchy structure like cache-memory architecture. Instead they are independent and parallel with each other in a graphics application. Basically, there is no restriction on where the data of a graphics application should be put among these three kinds of memories. For most of time, local video memory is the fastest one, but since we only have limited video memory, AGP memory and system memory are also frequently used in most of graphics applications.   2.1.2 Potential Bottlenecks of the Architecture   The three kinds of the memory have different data transfer bandwidths. Here is a list of bandwidths of video memory, AGP memory and system memory:    

 

Memory Type Memory Bandwidth Bus Bandwidth Video Memory Up to 8G-10G (GeForce3&Radeon 8500) 8G-10G (128-bit DDR) AGP Memory 1G (PC133)-1.6G (PC800) or higher (PC2700) 528M(AGP2x)1056M(AGP4x) System Memory 1G (PC133)  1.6G (PC800) or higher (PC2700) 133M (PCI33)-512M (PCI66)   Table 1 Different Memory Bandwidths Since AGP has a deep pipeline and uncached mechanisms [3], and PCI has a lot of contentions between memory and other I/O devices, the gap between system and AGP memory is larger than we expected. From table 1, we can expect there may be bottlenecks when a graphics application put data in different memories: Data from faster memory must wait data from slower memory to arrive before the graphics pipeline can continue.   2.1.3 Why this Bottleneck Is Important For Future Graphics Applications   As future graphics applications need more complex geometry model and more detailed textures, the data size will increase dramatically. Then AGP and even system memory may still be a place where these data could reside even with increased video memory on board. And because the dynamic textures and vertices that both video controller and the CPU will update frequently are always put in the AGP memory, we think this memory bottleneck will be more and more salient in the future. So having a clear picture of this memory bottleneck will be helpful for both software programmers and hardware designers. Next we will focus on testing, verifying the existence of the memory bottleneck and showing how serious this bottleneck could be. Finally we will conclude with some suggestions for software programmers and hardware designers based on our testing results.   2.2 Test Environment   Our tests are based on two machines that are equipped with the most advanced graphics cards:    Machine #1 Machine #2 CPU PIII 1GHz PIII 1GHz Graphics Card ATI Radeon 32M DDR Nvida GeForce3 64M DDR System Mem 512M PC133 1G PC133 OS Win2K SP2 Win2K SP2 Table 2 Test Environments Details of the two graphics card are as below:    ATI Radeon 32M DDR Nvida GeForce3 64M DDR Chipclock 183MHz 200MHz Memory Data Path 128-bit 128-bit Memory Speed 366MHz 500MHz Memory Size 32M DDR 64M DDR AGP support 2x, 4x 2x, 4x Table 3 Graphics Cards We Used The software is a specially designed program written by ourselves using Microsoft DirectX 8.1. The drivers of the two cards are:  ATI driver for Radeon ati3dvag.dll, version 5.13.01.3102(English)

 Nvidia driver for GeForce3 nv4_disp.dll, version 21.83(English)   2.3 Design of Benchmark Program To identify the memory bottleneck, we designed and implemented a special benchmark program. To ensure that we correctly identify the memory bottleneck, we must make our program free of other possible bottlenecks of graphics hardware. And it must be able to run upon different hardware and to arbitrarily allocate the data into different parts of the memories.   2.3.1 Other Possible Bottlenecks of Graphics Applications and How to Get Rid of Them Besides the memory bottleneck we mentioned above, there are still some other bottlenecks. These bottlenecks include: CPU bottleneck, GPU bottleneck, video card memory bandwidth bottleneck, and filling rate bottleneck. Some graphics applications need a lot of calculations by CPU, so sometimes the graphics controller and other parts of the application must wait the CPU to finish those calculations before they can continue their jobs. So now more and more computation of the geometry transformation, lighting and others has been moved to GPU to share the heavy load with CPU. Here we must avoid this bottleneck since we only want to identify the memory bottleneck in the test. To do this, first, we choose a machine with a fast CPU(PIII 1GHz CPU). And we make sure that in our benchmark program there are almost no CPU loads: we just render a static textured square and there are no animations that require a lot of CPU work. Also in our application, GPU is not a bottleneck either, for lighting is disabled and there are no special rendering effects that require a lot of GPU work. Filling rate directly depends on rendering resolution. The common resolution 640x480 is made up of 307,200 pixels, while a high-resolution frame buffer, such as 1600x1200 requires 1,920,000 pixels. The 3D-chip has to 'render' each pixel of a frame before the frame can be displayed. The 'frame rate' is defined as the number of frames that can be displayed in a certain amount of time. It's easy to see that it will eat up more video card memory bandwidth to supply a certain frame rate at a high resolution than at a low resolution. This is why typically 3D cards score high frame rates at 640x480 and lower frame rates at 1600x1200. So in our benchmark program, we render at a small resolution of 400x300 that guarantees neither video card memory bandwidth nor filling rate bottleneck affect our final frame rate. Also as the geometry of the object becomes more complex and the texture becomes more detailed, the performance of the applications will drop. This is because the amount of primitive (triangles) data needed to be processed by GPU increases. So the drop of the performance is only determined by the number of triangles rendered. In our test, we compare results with the same primitive number or the normalized frame rate (performance/primitive number).   2.3.2 How To Arbitrarily Put Data into Different Memory Locations We use Microsoft DirectX 8.1[4] to implement our benchmark program. Microsoft DirectX is an advanced suite of multimedia APIs (application programming interfaces) built into Microsoft Windows operating systems. DirectX provides a standard development platform for Windows- based PCs by enabling software developers to access specialized hardware features without having to write hardware-specific code. In DirectX, the location of data can be specified by the two parameters. One is D3DUSAGE, and the other is D3DPOOL. With different combination of these two parameters, we can arbitrarily allocate memory to local video memory, AGP memory or system memory. D3DUSAGE D3DPOOL Location of the memory D3DUSAGE_WRITEONLY D3DPOOL_DEAFULT Local Video Memory D3DUSAGE_DYNAMIC D3DPOOL_DEAFULT AGP memory D3DUSAGE_DEFUALT D3DPO _ MMEM System MemoryOL SYSTE Table 4 DirectX Parameter Combinations

  2.3.3 Implementation Details and User Interface (UI)   The benchmark program is to render a square that is constructed by a lot of triangles. We can change the number of triangles and map a texture to this triangle mesh. Triangles will be put into the rendering pipeline as primitive streams. Each stream is a vertex array. Every three consecutive vertices represent a triangle. Since the hardware always has a limitation of the maximum size of a single primitive stream, when the number of triangles is too large, we have to split the big triangle list into several primitive streams and then fit them into the rendering pipeline one by one. This split usually doesnt incur additional cost with DirectX 8.1(With DirectX 7, too many streams will cause a serious performance loss). Figure 3 UI of benchmark program S ho o  ld it i   n d g  o v e e s r n t  e t  x  a d ff a e ta c   t i   s o  c u a r  ll f e r d a   m ve e  rt r e a x t   e b  r u e f s fe u r l   t ( .  V T B h ) e .     memory  Besides vertex buffer, we also create different sizes of textures from a resolution of 256x256 to 2048x2048. The largest texture size is about 12MB.   2.4 Result and Analysis 2.4.1 Speed of Three Kinds of Memories   In this test we put same data in the video memory, AGP memory and system memory respectively, and record the final frame rate of the application. The goal of this test is to give us a clear view of how much the gap is among these three kinds of memories. The result is shown as following: Triangle # VB Size FPS(Video) FPS(AGP2x) FPS(Sys) FPS(AGP4x) 5000 0.42M 1007.02 728.29 480.53 1027.26 20000 1.68M 308.7 208.8 136.87 313.1 80000 6.72M 81.36 54.52 35.31 81.63 320000 26.88M 20.66 13.71 8.96 20.68 1280000 107.52M 4.24 3.43 2.25 Table 5 VB in Video, AGP and System memory VB size here means the size of the vertex buffer. As we can see, the performance is the best when data is stored in video memory and AGP4x. The bandwidth of AGP4x is above 1GB/sec, and with deep pipeline, the latency of reading data from AGP4x memory can be effectively hided. While in AGP2x, the performance is worse since the bandwidth for AGP2x is half of AGP4x. For system memory, the result is even worse. Here we can clearly identify the gap between different kinds of memories. In this case AGP4x seems no inferior to video memory and even a little bit faster! Does it mean AGP4x is better? The answer is no as we can see from the next test. And one thing we would like to point out is that when running the program in AGP4x, there are a lot of errors. For those 4 slots of AGP4x in table 5, we had to reboot our Machine#2 for 3 times. And the rendering result also has errors. The reason why AGP4x is so unstable is mainly because it transfers too much data within one bus clock. In AGP1x, 4B data are transferred at every falling edge. In AGP2x, 4B data are transferred at each falling and rising edge. In AGP4x, even 4B more data are transferred between any falling and rising edges.  

2.4.2 Vertex Size Test   In this test, we fix the number of triangles but increase the size of each vertex. This increases the total data size but maintain the same number of primitives. Since the graphics pipeline processes geometry data by one primitive by one primitive, so the workload for geometry computation is always the same. As we didnt change the resolution of the frame buffer, the filling rate and texture coordinate interpolation workloads are the same all the time. Here we want to see as the workload of GPU is staying the same, how increased memory load will affect the performance of graphics application. This could happen in future graphics applications when more texture coordinates are supported for each vertex. The result is shown below:   vertex size (byte) Video AGP(2x) AGP(4x) 96 36.62 10.67 17.91 88 36.67 10.7 17.81 80 36.45 10.67 17.9 72 34 10.7636. 17.89 64 36.38 10.78 17.83 56 36.63 12.25 20.38 48 36.68 14.4 23.75 40 28 28.4436.7 17. 36 36.84 19.58 31.57 32 36.84 21.72 35.51 24 36.84 28.93 36.65  

40 35 30 25 20 15 10 5 0

Video Memory AGP2x AGP4x

Vertex Size   Table 6 Different Vertex Sizes   We increased the vertexs size by adding some redundant fields in a vertex structure. Such as normal vector (since we dont have lighting, this field will be redundant), additional texture coordinates (we only apply one texture in our program, so additional texture coordinates will be redundant). These redundant fields ensure that we dont have additional computational workload but only the increased memory size. This enables us to focus on the bottleneck of memory that affects the performance. The triangle number in this test is 180,000. Z depth is 16-bit. Resolution is

400x300. We can see when the data is stored in video memory, as the vertex size increases, the performance keeps the same, even when the vertex buffers size is four times larger. This means video memorys high bandwidth isnt the bottleneck. Both in AGP4x and AGP2x, as the vertex size increases, the performance drops linearly. After 66 bytes per vertex, the performance stays the same. This because after 66 bytes, the 5th to 8th set of texture coordinates are the only added components for each vertex. Since current GeForce3 hardware only supports blending 4 textures within one pass, even when we add more texture coordinates, the graphics controller will just ignore them. So the actual data transferred is still 66 bytes per vertex even when the vertex size is bigger than 66 bytes. From this test, we can tell that AGP4xs speed still cant compare to video memory. As the memory data size increases, the performance of AGP4x becomes worse than the local video memory. So if some of the data are stored in video memory and some of the data are stored in AGP memory, the speed difference between these two kinds of memories will enforce the application to wait the slower one. Then the overall performance of the application will be deteriorated. From the test result, we can see the performance of AGP4x is almost half of that of the video memory.   2.4.3 Texture size test   In this test, we combine different sizes of vertex buffers and textures, and record the performance of each combination. Since textures and vertices are two main types of graphics data that may eat up a large portion of the memory, and these two types of data are processed by GPU quite differently, it is interesting to see when one of these two kinds of data is the major source of memory bottleneck. The result is shown below: Texture Size/Triangle # 720000 320000 80000 20000 5000 1250 288 256x256 5.19 20.67 81.76 310.98 1025.62 2196.73 2396.71 512x512 5.19 20.73 81.75 310.55 1025.52 1901.07 1967.28 1024x1024 5.18 20.68 81.68 310.58 979.28 1015.88 1050.49 2048x20485.19 20.64 81.63 310.73 986.04 1002.76 1020.63 NAxNA 6.05 25.04 98.41 364.24 1167.71 2460.8 2764.99 Table 7 Textures & Vertices in GeForce3 Texture Size/Triangle # 720000 320000 80000 20000 5000 1250 288 256x2562.92 15.57 60.06 210.59 563.9 768.5 805.43 512x512 2.92 15.57 60.06 210.59 545.93 553.92 579.87 1024x1024 2.9 15.57 60.06 210.59 278.91 282.89 293.85 2048x2048 2.88 15.57 60.06 107.37 111.91 93.27 104.8 NAxNA 2.93 15.34 59.42 207.59 560.9 798.44 825.39 Table 8 Textures & Vertices in Radeon From the above results, we can see the source of memory bottleneck changes from texture to vertex buffer. 1) When the triangle number is small (vertex buffer is small), the performance decreases as the texture size increases. 2) When the triangle number is large (vertex buffer is large), the performance is only determined by the number of triangles and is independent of the size of the texture. Within one rendering step, normally GPU will access the vertex buffer more to do transformation

and lighting, clipping, and Z-test. But for textures, only once is enough when mapping the texture color to each pixel since nearest neighbor texture filtering is the scheme we used for texture mapping here. So as we can see the performance decrease caused by texture data and vertex data is not proportional to the memory size they take. Those tests will give us some useful hints for graphics programming which will be described in next section.   2.5 Suggestions for Software Programmer and Hardware Designers 2.5.1 Try to put important data in Video Memory   This is what the first two tests tell us. The speed gap between AGP memory and video memory is salient. So when a programmer has enough video memory, try to make fully use of it. But the problem is many cheap cards with small video memories are still being used by many users even when more advanced graphics cards are available now. Then game developers must make sure that their applications can run smoothly in most cards. (This wont be a problem for game console since all users have the same hardware) They must be careful about which part of graphics data should be put in video card memory and which part can be put in AGP memory but still maintain a pretty good performance. As we have discussed in the final test result, vertex buffer always has more data transfers with GPU, so it is not wise to put it in AGP memory. But texture data seem more suitable to be put in AGP memory. And with faster AGP standard available, the speed gap for texture data in different kinds of memory will be less and less noticeable.   2.5.2 Increase the AGP speed   This is for hardware designer. Since we cant increase the video memory size unlimitedly, it is quite reasonable to improve the AGP memory bandwidth to minimize the speed gap between video card memory and AGP memory. With the faster memories (PC2700, PC800) are available now, faster AGP bus is also needed to make fully use of these faster main memories. As we can see, in the newest AGP specification 3.0 (5/2001), AGP8x standard has been included. Thats good news because the bandwidth of AGP bus can reach 2GB with AGP8x. But stability of high-speed AGP is another problem. As we have discussed before, even with AGP4x, the transfer of data is not stable. This greatly impedes use of high-speed AGP memory. The stability is determined by many factors: motherboard manufacturer, chipset designer, video card manufacturer, driver writers and standard designers. Especially a good driver is always what a user mostly wanted. In our test, we found new drivers always boost the performance greatly even with the same hardware. ATIs driver is more stable but seems more conservative. Nvidias driver is smarter but generates more errors.   2.5.3 32byte alignment is not necessary In some graphics seminars, people said a programmer should make their vertex size 32byte aligned. That will increase the speed of your program. But in our test of Vertex Size, we can see this really doesnt help improve the performance. So we dont need to pay attention to the issue of 32byte alignment based on our test result.    2.5.4 Complex Geometry or detailed texture From our last test of vertex buffer and texture, we can get some really useful hints. Many graphics programmer will choose less detailed geometry model with vivid textures in their programs. They claim that this will improve the performance and only make small visual defections. But in our test result we find this is not always true. For example, in Radeon: 288 triangles with 2048x2048 texture, the rendering speed is 104.8, but 20000 triangles with a 1024x1024 texture, the rendering speed is 210.59, almost two times faster. That because when geometry memory is not large, texture memory becomes the source of the memory bottleneck. So for programmers, before they want to reduce the number of triangles in the models, they need to

make sure to find a good balance of performance and visual quality.   3 Graphics Processing Unit(GPU) and video card driver impact on performance In the section, the impact of GPU on performance will be examined in detail. It is not easy to detect that GPU is an incoming bottleneck for graphics applications that demand much more computation power than before until programmable shaders [4] (a programmable part in the graphics pipeline) become available recently. Thus first, programmable shaders in the state-of-art graphics pipeline will be introduced in 3.1. Based on the programmable shaders, specific benchmarks could be made to identify bottlenecks caused by GPU. These issues will be addressed in 3.2 and 3.3. Further testing results in 3.4 will expose some amazing facts and thus give game developers and graphics programmers some good suggestions. In 3.5, we will also expose some weakness of current video card drivers.   3.1 Graphics pipeline and programmable shaders  

3D graphics rendering involves numerous steps that are performed one after another. These steps can be thought of like an assembly line, or a pipeline (Figure 4). The pipeline can be broken down into two main stages: the geometry processing stage, and the rendering stage. When using a graphics chip that supports hardware accelerated transform and lighting (T&L), the geometry processing stage takes place in the GPU. Geometry processing involves calculations that modify or, in some cases, create new data for vertices. At this point, previous graphics card use fixed function pipeline (FFP) to perform transformation and lighting operations. Recently, vertex shader, a kind of programmable shaders, is introduced and can be used to replace FFP to perform a specified set of operations including T&L on every incoming vertex. In the rendering stage of this pipeline, Figure 4 Pipeline c a a n l o l t e h d e   r p   ix k e i l  n s d h   ad o e f  r,  p c r a o n  gr b a e  m us m e a d b   l t e o    r s e h pl a a d c e e r     previous fixed function texturing, filtering and blending. So from the programmers point of view, the programmable shader is a piece of code to perform different kinds of operations in GPU including T&L, texturing and etc. Compared with FFP, the programmable shaders provide more flexibility. On the other hand, those programmable shaders can also provide a new type of benchmark to evaluate GPU performance. In our experiment, all the benchmarks are different types of vertex shaders. By changing the number, the types or arrangement of instructions in those shaders, we can expose more GPU performance on different applications. Figure 6 is the program model for vertex shaders. In this model, the vertex shader architecture streams vertex data into the shader from the graphics pipeline, performs operations on the data using an arithmetic logic unit (ALU), and outputs the transformed vertex data to the graphics pipeline for further processing. Registers are used for inputting data, outputting

data, and holding temporary results. Each register holds four fixed-point numbers. The vertex shader architecture defines several types of registers, each operating on a different type of data.  v0v15. Vertex registers are used to stream vertex data into the shader ALU. Vertex data is defined by an application and can contain any data. Those registers are only readable.  r0r11. Temporary registers are used to hold intermediate results. There are no read /write limitations on these registers.  c0c95. Constant value registers are designed to input constant values to the shader. These registers are only readable too.  a0. The address register can be used to provide an integer offset during the lookup of any constant value register.  oDn, oFog, oPos, oPts, oTn. Output registers output data from the vertex shader to the graphics pipeline for further processing. The registers contain transformed position data, texture coordinates, diffuse color, and specular color. These registers are write-only. To simplify hardware design, there is no branching in vertex shaders. Read/write limitation is also applied on those different types of registers. The vertex shader can at most contain 128 instructions. 3.2 Benchmark tools and experiment setting.   We build a benchmark tool (Figure 5) to render the same checkerboard image by read different kinds of shader benchmarks. The coding is done using VC++. The latest DirectX8.1 driver is used for rendering, MFC is used to generate user interface. All the application are run on a P4 (1.9GHz) PC with Windows XP, 512M RDRAM (PC800) and AGP 4X mode. Two state-of-art video cards are tested by our benchmarks. One is Nvidias Geforce3 (64M DDR) and the other one is ATIs Radoen 8500 (64M DDR). Both cards are only available this year. For each benchmark, a small number of diffuse colored triangles (8192) are rendered for the checkerboard image. The vertex buffer size and index buffer size for those triangles are only 0.589824Mb and 0.049152Mb. During rendering, we use 16 bit Z buffer and 32-bit color. The frame buffer resolution is limited to 428*382. In our benchmark, the 1.9GHz P4 Processor is not a bottleneck for rendering those triangles. Further more, since the vertex data size is quite small and no texture mapping is used, only a small portion of video card memory is used. Thus no AGP memory is used in our testing. Also considering the low resolution of the frame buffer, the video card memory bandwidth will not be a bottleneck in our testing. However, in each of those vertex shaders, instruction type, number and arrangement of those instructions are different. Although the final rendering image are the same, the rendering speed characterized by FPS (Frames Per Second) varies and exposes the details about the computation power of different GPUs.

 

Figure 6 Program Model  

   Figure 5 UI of benchmark for shaders 3.3 Detecting GPU clock rate as a bottleneck   dp4 oPos.x, v0, c0 17 o B p e e n ra c t h io m n a s. r   k T s: h   e     T h h a e r   d in w s a t r r e u   c i ti m o p n l   e s m et e   n o t f a   t v i e o r n t   e o x  f  sh G a e d f e o r r   c c e o 3 n   s c i a s r ts d     o i f s     dp4 oPos.y, v0, c1 assumed to issue one instruction per clock and execute all dp4 oPos.z, v0, c2   dp4 oPos.w, v0, c3 instructions with the same latency. However, we know simple mov oD0, v2 i v n e s c t t r o u r c   t u io ni n t s     i l n i   k F e l   o  at M in O g V -p , o   i  nt M  C U o L re    ,  (   F  P A C D )  D of     a G r e e f   o p r e c r e f 3 o   r w m h e i d l   e b  c y o  S m I p M le D x       instructions like RCP and RSQ are performed by its ci l spe a function unit within about 1.5bits of IEEE precision using two-pass Ra hson iteration fr Figure 7 be N l e ie w v t e o d n   - to  p have different  o h m ar   d a  w s a e r e e  d  i t m ab p l l e e .  m A en T t I a   ti R o a n d   e f o o n r     8 s 5 i 0 m 0  pl is e     instructions and complex instructions. Based on these facts, each of our benchmark will have the basic block, shown in Figure 7. The major task of this basic block is to perform transformation for each vertex vector stored in v0. c0, c1, c2 and c3 are the column vectors of the transformation matrix. The mov instruction will assign diffuse color of each vertex stored in v2 to the write-only output register oD0. Besides these instructions, each vertex shader benchmark either contains a set of simple instructions or a set of complex instructions. Thus, we have two types of shader benchmarks here, one is called simple shader and the other is called complex shader. We call this set of instructions additional instructions. The number of those additional instructions is 0,5,25,45,65,85, or 105 in each shader benchmark. In addition, each shader benchmark contains one more instruction:mov oD1, r5.x.All the additional instructions will be used to compute the specular color for the vertex. The result (in our case, it can be of any value, and we dont apply specular effects in our rendering, for the value in register oD1 doesnt have any physical meaning here but for testing.) is hold in r5.x. The above mov instruction is used to put the value into the write only register oD1 for specular color of each vertex. During the rendering process, the lighting is disabled, so the specular effects wont be seen. However, the computation is still performed.   Testing Results: