Introduction

3D geometric models are common in computer graphics—for example, in computer games, scientific simulations, or architectural design. These models are usually built as a collection of vertices connected together to form a polygon mesh. Complex models can contain tens of millions of polygons. For example, the power plant and DoubleEagle Tanker models (http://www.cs.unc.edu/~walk/models) available from the University of North Carolina at Chapel Hill contain 13 million and 82 million polygons, respectively.

As you can imagine, managing large polygonal models within an application presents numerous challenges for developers—the most pressing of which is how quickly the mesh can be rendered. Interactive applications need to render at least 30 frames a second. A number of clever approaches like view culling, point-based rendering, and geometry caching have been designed to help with this. Another example involves global illumination algorithms like radiosity. The speed of these algorithms depends in large part on the size of the polygon mesh they take as input. Reducing the mesh's size can produce significant speed-ups in the algorithm.

This article describes a collection of mesh simplification algorithms. Mesh simplification reduces the number of polygons in the mesh—often dramatically—while remaining faithful to the topology (that is, the shape) of the original mesh.   In this article, you’ll learn how to simplify your own meshes. You can apply this in any situation where smaller models would help, for example, to improve character models in a game for better rendering speeds, or to simplify a complicated terrain model so it can be held entirely in memory.

Basic Simplification Operations

Any differences between the original and the simplified mesh are called geometric error. You use geometric error to control a simplification algorithm. One option is to define an error threshold, then ask the algorithm to reduce the number of polygons as much as possible without producing geometric error above the set threshold. Another approach is to pick a desired polygon count, then ask the algorithm to reduce the mesh to this size while minimizing the amount of geometric error being produced.

Different algorithms reduce the number of polygons in a mesh in different ways. Two common simplification operations are the edge collapse and vertex collapse.

Edge Collapse

An edge collapse (see Figure 1) takes an edge (v1, v2) in the mesh and collapses it to a single vertex vnew. The edge and any triangles that use the edge are removed. Common locations for vnew include either of the collapsed edge's endpoints (vnew=v1 or vnew=v2) or a position somewhere along the collapsed edge (vnew= v1+w(v2- v1), 0 < w < 1).

Vertex Collapse

A vertex collapse (see Figure 2) combines two vertices (v1, v2) into a single vertex vnew. Unlike an edge collapse, v1 and v2 do not need to be connected. Triangles connected to either v1 or v2 are updated to connect to vnew. You can place vnew somewhere along the line connecting v1 and v1, or in any other position that does not introduce inconsistency like the mesh folding over or polygons interpenetrating one another. Notice that an edge collapse is a special case of a vertex collapse. It's a vertex collapse where v1 and v2 are connected and vnew is somewhere along the edge between v1 and v2.

Progressive Meshes

Edge collapses seem like a promising way to reduce a mesh's size. Collapsing an edge removes the triangles it shares, making the model smaller. The key question is: Which edges should we remove, and in what order? Progressive meshes (PM) solve exactly this problem. The PM algorithm simplifies or refines a mesh using three mesh modification operators: an edge collapse to simplify and reduce the size of the mesh, a vertex split to add detail and increase the size of the mesh, and an edge swap to improve the shape of the mesh [Hoppe 1993]. This article focuses on mesh simplification, so let’s concentrate on the edge collapse operator.

The PM algorithm simplifies an initial mesh Mⁿ with n vertices into a progressive sequence of meshes (Mⁿ⁻¹, Mⁿ⁻²,  . . . M¹), each with one less vertex. This makes it easy to select a mesh with a desired number of vertices. If you want a mesh with m vertices, simply choose M^m from the sequence. It’s also easy to locate a mesh with a maximum geometric error.  Walk down the sequence of meshes until you find the mesh M^m-1 with more error than you want. The previous mesh M^m will be the smallest mesh with an error below your threshold. You can also use the sequence to animate the simplification or refinement of the mesh—a technique known as geomorphing.

Simplification is controlled by an energy function that measures two competing quality measures: how tightly a simplified mesh fits the original (Edist) and the number of vertices the simplified mesh contains (Erep). Improving one measure will normally make the other worse (for example, fewer vertices will reduce the fit to the original mesh). A spring measure Espring is also included in the energy function. Its job is to keep the mesh tight along its edges. Adding these three measures together produces the final energy function:

E = Edist + Erep + Espring

Given a mesh M^m with V = { v1, …, vm } vertices and edges between the vertices defined by K, Edist(V,K) measures tightness as the squared distance from V to the original mesh. Erep (K) is simply a weighted vertex count crep m. crep allows you to control how aggressively to simplify the mesh. A larger crep means the energy function will favor reducing vertices over maintaining a tight fit to the original mesh. Each edge collapse replaces an edge’s endpoints (v1, v2) with a single vertex vnew, as Figure 3 shows.

To optimize vnew, all other vertices are held constant. You derive a vnew position that minimizes the squared distance to the original mesh through conjugate gradient iteration. You can localize distance calculations to triangles incident on either v1 or v2. To reduce the number of iterations performed, you have three possible starting positions: v1, v2, and ½(v1+v2). The best overall position is then assigned to vnew.

Figure 4 shows a simple pseudocode overview of the progressive mesh (PM) algorithm.

start with initial K, V for mesh Mn
repeat {
	choose an edge collapse producing new connectivity K’
	optimize vnew position producing new vertices V’
	calculate E(K’,V’)
	if E(K’,V’) < E(K,V)
		set K=K’, V=V’
}
until convergence

Figure 4. Simple pseudocode of the PM algorithm

This code produces a sequence of edge collapses that continues until no improvements to the energy function can be found.

You can extend the PM algorithm to consider both geometric error and errors in surface attributes like color and texture patterns [Hoppe 1996]. You do this by updating the energy function to include penalties for collapsing edges that straddle different surface colors or different textures. Now, a simplified model maintains its shape and any color and texture patterns on its surface.

Figure 3a–c shows a geographic mesh of North America with frost coverage and rainfall measured at each vertex position. A modified PM algorithm that respects frost and rainfall values was used to reduce the mesh to 10% of its original vertices (Figure 3d–f) [Walter 2001]. Although 90% of the original vertices and their corresponding weather values have been removed, the simplified frost and rainfall patterns (Figure 3e–f) remain faithful to the full-resolution versions (Figure 3b–c).

Simplification Using Quadric Errors

An alternative to collapsing an edge is to connect two vertices (a vertex collapse), then remove any triangles that reduce to lines or points. The quadric simplification approach uses this exact strategy [Garland 1997]. The algorithm chooses a set of vertex collapses^** that reduce an initial mesh (Mⁿ) into a sequence of meshes (Mⁿ⁻¹, Mⁿ⁻², . . . M¹). A quadric error metric (QEM) selects which vertices to collapse.

Unlike an edge collapse, a vertex collapse can replace two vertices that are not connected (Figure 2). This means disconnected regions of the mesh can be joined together. Whether this is what you want depends on your models’ domain.

The main problem is to decide which pairs of vertices to collapse to produce simplified meshes that closely approximate the original mesh. To do so, perform these steps:

1. Identify all vertex pairs that could be collapsed.
2. Assign a cost to each of these collapses.
3. Place the collapses on a heap that is ordered by minimum cost. This means the collapse with the lowest cost will always be at the front of the heap.

Once this is done, you can remove the vertex pair (v1, v2) with the minimum cost from the top of the heap and perform the collapse. Vertex pairs still on the heap that contain either v1 or v2 need to have their costs updated. This re-orders the heap, so the next best collapse is at the front. Continue retrieving, collapsing, and updating until your desired mesh size or error threshold is reached.

A quadric error matrix Qi at each vertex vi defines the cost of a collapse. Qi is built by examining each triangle that includes vi. Once you have QEMs Q1 and Q2 for vertex pair (v1, v2), you can approximate an error matrix for the collapsed vertex vnew as Q = Q1 + Q2. The algorithm first tries to find a position for vnew that minimizes error. If the search fails, it looks for an optimal position along the edge v1 v2. As a fallback, the algorithm chooses the position with the smallest error from among v1, v2, and ½(v1+v2).

^**In his paper, Garland refers to the vertex collapse operation as a pair contraction.

compute Qi for all vi in Mn
select as valid pairs
	all edges (v1,v2)
	any pair (v1,v2) where v1−v2 < t for threshold value t
compute optimal vnew, cost of vnew for each valid pair
place all pairs on a heap ordered by minimum cost
repeat {
	remove (v1,v2) from the top of the heap
	contract to position vnew by setting v1=vnew
	replace all occurrences of v2 in heap with v1
	update costs of valid pairs involving v1
}
until target vertex size of error threshold is achieved

Figure 5. Pseudocode for Garland’s QEM

As with PM, you can extend quadric error meshes to respect surface attributes—in particular, colors, texture coordinates, and normal directions [Garland 1998].

Simplification Envelopes

When you simplify a mesh, how can you make sure the shape stays true to the original model? Simplification envelopes offer a simple and elegant way to do this [Cohen 1993]. A mesh is bounded on both sides by two envelopes, two offset surfaces guaranteed to be no more than a maximum distance ε from any point on the original model. You then simplify the mesh by removing vertices, which creates holes in the mesh. If you can fill a hole without falling outside of the simplification envelopes, the removal is allowed. Vertices are removed until no holes can be filled.

By varying ε, a sequence of simplified models can be constructed. Small ε produces a close match to the original model but with limited simplification. Large ε produces a significant reduction in vertex and polygon count but with a less accurate fit to the original model.

You build the simplification envelopes by constructing envelopes for each triangle in the mesh, then combining them. For an edge (v1, v2) and normals to the vertices (n1, n2), find the plane passing through the edge in the direction n1 at v1 and n2 at v2. Every triangle will have three such planes—one for each of its three edges. Extending the triangle’s edges a distance +ε and −ε along each plane produces two simplification envelopes—one above the triangle and one below it (see Figure 6). Envelopes for individual polygons are combined. Any intersections between polygon envelopes are corrected, producing a smooth surface bounding the object.

After you build the two envelopes, simplification can begin. You can use two different approaches to control simplification: a local method that uses vertex removal and a global method that uses overlap.

The local approach simplifies large models by minimizing preprocessing and considering only local changes to the mesh. Here, each vertex in the mesh is placed on a queue. A vertex is selected from the queue and removed from the mesh, producing a “hole.” The algorithm uses triangulation to try to fill the hole. Each new triangle is tested to ensure that it lies within the mesh’s envelopes. If the hole is filled successfully, the new triangles' vertices are saved in the queue. If the hole cannot be filled, the mesh is left unchanged. You continue until the queue is empty. At this point, no additional simplification is possible.

The global approach tries to remove as many vertices as possible at each step in the algorithm. To do this, the vertices of the original mesh are combined into all possible triangles that do not intersect the boundary envelopes. Count the number of mesh vertices each candidate triangle overlaps, place them on a heap in descending order of vertex overlap, then retrieve them one by one. For each candidate, remove all the triangles in the mesh that overlap the candidate, forming a large hole. As before, you use triangulation to try to fill the hole. Holes that you successfully fill are kept. This process continues until the heap is empty.

Figure 7 and figure 8 show the pseudocode for both the local and global algorithms, respectively.

build simplification envelopes
assign all vi in Mn to a queue
repeat {
	retrieve vi from queue
	remove vi from mesh
	if resulting hole can be filled
		add new vj to queue
}
until queue is empty

Figure 7. The local algorithm

build simplification envelopes
for all vi in Mn {
	build all triangles tj within
	  envelopes
	calculate vertex overlap
	add tj to heap
}
repeat {
	remove tj from heap
	remove triangles tj overlaps
	if resulting hole can be filled
		keep filled hole
}
until heap is empty

Figure 8. The global algorithm

Parallel Mesh Simplification

Mesh simplifications—especially methods that perform local modifications to a mesh—seem like ideal candidates for parallelization. Various approaches have been suggested to divide simplification into independent subtasks that can be run in parallel. The potential advantages of parallel mesh simplification are two-fold.

• By dividing the problem across several independent processes, the time needed to complete the simplification is the time needed by the slowest process, plus the time needed to subdivide the mesh and combine the processes’ results.
• The amount of memory required by each process is reduced, because it operates on a subset of the original mesh. So, when a mesh does not fit in main memory, you can split it into subsets that do, eliminating the need to swap data to and from disk.

Both advantages can provide significant speed-ups, particularly for very large meshes.

Parallel simplification algorithms follow a common pattern for producing their final results (Figure 9):
      A parent processor partitions the original mesh into p sub-meshes Si.
      Each Si is sent to one of p child processors.
      Each child simplifies Si and returns it to the parent.
      The parent combines the results to produce a final, simplified mesh.

Parallel Simplification

A good example of the split-simplify-combine technique is a method that uses vertex decimation to simplify a mesh. Vertex decimation is directly compatible with both the PM and QEM simplification algorithms. Other local approaches (for example, the local simplification envelope technique) should also work with only minor modifications.

One recent algorithm that follows the standard pattern of partitioning the original mesh into sub-meshes [Rasch 2000] distributes each sub-mesh to a child processor for parallel simplification. A child processor can create its own “worker” processes. These workers will themselves simplify in parallel, further improving performance.

The parent and child processes are usually run on separate machines. This means the processes have separate memory spaces. Rather than passing mesh information back and forth, you can use an external library (for example, the Adsmith-Library) to simulate a shared-memory environment. The library distributes the mesh data to all the processes, but presents it to each process as a single, large memory block.

The basic algorithm still leaves certain issues open. For example, if multiple workers are simplifying a sub-mesh in parallel, it’s important to make sure that two workers don't suggest different changes to the same area of the mesh. You could do this by asking each worker to lock the triangles that use the vertices it is trying to simplify. Similarly, simplifying boundary triangles can create cracks in the mesh if separate child processors make incompatible changes to edges shared across the boundary. Again, you can manage this by locking boundary triangles or by “re-connecting” mismatched boundaries in the master processor—for example, using a zippering algorithm to “sew” the edges back together [Turk 1994].

This algorithm was evaluated on a variety of models ranging from 15,000 to 922,000 polygons. Small models show linear speed-up for up to four processors. For more than four processors, proper load balancing becomes difficult. Complex models that do not fit in the main memory show super-linear speed-ups, because most of the time spent in the non-parallel case involves swapping data to and from disk. Given an estimate of how long a single processor would need if it had enough memory to store the entire model, you see a 26× improvement for a 36-processor environment.

Distributed Simplification

Partition and reconstruction approaches that use different communication strategies also exist. One example uses a portable message-passing interface (Local Area Multicomputer-Message Passing Interface, or LAM-MPI) to communicate between processes, rather than assuming a large shared memory space [Dehne 2000]. A master process partitions the original mesh into sub-meshes of roughly equal size, then sends them to child processors for simplification. A child processor may create additional children to further distribute the simplification tasks. Results are sent back to the master to be combined into a final result.

Simplification times with 1, 2, 4, 8, and 16 processors have been measured, together with the time to transfer data between the master and the children and the difference in time ΔS between the slowest and fastest child processes. Simplification times show a near linear speed-up as the number of processors increases. As with the shared memory algorithm, speed-ups also improve as the size of the model increases. Transfer times, even for 16 processors, do not exceed 5% of the total execution time. However, ΔS can be as high as 50% for certain tests. This shows a significant load imbalance. In spite of this, partitioning the original mesh to produce perfect load balancing is extremely difficult, and the time needed to do it may be more than the time saved during the improved simplification.

A recent re-evaluation of the message passing algorithm confirms the speed-up in execution times. Geometric error and execution times for 1, 8, and 16 processors was recorded and compared to the QEM algorithm [Tang 2007, Yongquan 2009]. Parallel results are similar to QEM, although in all cases QEM produces smaller absolute errors than the binary space-partitioning simplification used by the message passing algorithm. Execution times show a speed-up of approximately 7× for the 8-processor environment and approximately 11× for 16 processors, reaffirming the effectiveness of a parallel implementation.

Parallel Hierarchical Level-of-Detail

Another way to simplify a model before rendering is by creating hierarchical level-of-detail trees (HLODs) in parallel. HLODs are like any other tree structure. They have a root, internal nodes, and leaf nodes. The original, full-detail model is stored at the root. You simplify by performing the following steps:

1. Simplify the original model stored at the root.
2. At the same time, subdivide the original model into multiple sub-model parts.
3. Create a child node to hold each sub-model.
4. Ask the child nodes to simplify their sub-model.

Simplification in the child nodes is more aggressive than the simplification at the root node. This means the child nodes will be a more simplified version of the model.

You perform exactly the same "subdivide and simplify" strategy on internal nodes to further simplify the model. When finished, you have an HLOD tree [Cozzi 2008]. Nodes farther down the tree are more simplified. If you take all the leaf nodes and combine their sub-models, you recreate the original model at the highest level of simplification.

Vertex clustering is used to perform simplification. Vertex clustering subdivides a mesh into cells. You choose a single vertex vnew to replace all the vertices {v1, ..., vm} in each cell. Triangles attached to {v1, ..., vm} are updated to use vnew. Triangles that are do not degenerate into lines or points are kept. This strategy works well, since you don't need vertices that are outside the sub-model you are simplifying.

Building HLODs offers not just one, but two opportunities to parallelize. First, the simplification in different nodes can be run in parallel. Second, the recursive steps in the HLOD can also be run in parallel. That is, whenever a subtree is created, you can assign it to a separate thread for further processing.

You can use a hybrid approach that combines both of these advantages (Figure 10) by subdividing the model into eight sub-models (an octree), then processing pairs of subtrees in parallel. The root and each subtree create a separate thread to perform simplification so that subdividing and simplifying can run in parallel. Although you might expect more threads to produce even better results, runtime examination shows that the cost of thread management begins to outweigh the savings from parallel execution, particularly when all the cores in the CPU are busy with other tasks.

An example scenario simplified a city model with 5,646,041 triangles into HLODs of height six. Using separate threads for either simplification or subtree processing produced improvements of around 15-20%. Combining these steps using a hybrid parallel approach sped up the algorithm, generating a savings of approximately 40%. By increasing the number of cores in the CPU and optimizing thread management, you should see even larger improvements.

Parallel View-dependent Mesh Refinement

Parallel methods are not used only for simplifying a mesh. For instance, it is possible to refine a PM in parallel based on where a viewer is looking. The goal is to dynamically reduce detail in areas of the mesh that are small or hidden and maintain detail in areas that are in sight. You can do this by building a “vertex hierarchy” of all possible mesh refinements for Mn. You then use the view frustum, surface orientation, and screen-space size (in pixels) to choose an appropriate level of detail for different regions in the mesh [Hu 2009].

The vertex hierarchy contains the positions of the n vertices in the original mesh, plus their new positions as they are moved during edge collapses. A “vertex frontier” within the hierarchy contains the vertices that are currently being used to render the mesh. At each timestep, you process the frontier's vertices in parallel, searching for locations where new edge collapses or vertex splits are needed because of changes in where a viewer is located and where he is looking. Updates are sent to a triangle buffer that keeps a list of triangles to render.

You can perform load balancing by measuring how long it took to complete each algorithm step during previous passes. Given a fixed time budget (for example, a minimum frames-per-second rendering requirement), you complete as many steps as is possible. Partial steps are held and finished during the next timestep.

Results show that very large models can be simplified and rendered at interactive speeds, even for an error threshold of at most 1 pixel. For example, a 10,000,000-triangle model is simplified to approximately 390,000 triangles and rendered in 22 ms. As the number of cores increases, so too should the performance of the algorithm, because more vertices on the vertex frontier can be updated during each processing step.

Code Resources

Numerous source code implementations exist for each of the three simplification algorithms. Here are a few examples:

• Progressive meshes
• Quadric simplification
• Simplification envelopes

Summary

Polygon meshes have long been a standard method for representing the shape and surface properties of three-dimensional models. You can use simplification algorithms to set the number of polygons in your models to just the right number to both maintain a desired level of detail and to minimize the number of polygons you need to render.

Numerous simplification algorithms have been proposed that apply basic operations like edge and vertex collapses. Each algorithm reduces the size of a mesh using cost and objective functions to search for a simplified result with a specific polygon count or a guaranteed error tolerance.

More recent work has described ways to parallelize the simplification algorithms. The parallel algorithms community uses a partition, simplify, and recombine approach to process subsets of the original mesh simultaneously. Computer graphics researchers have suggested other uses of parallel processing—for example, to dynamically update a simplified mesh based on a changing view location. Results from both areas show that parallel implementations can provide dramatic improvements, both in execution time and in the number of resources needed to complete the simplification task.

About the Author

Christopher G. Healey received a Bachelor’s degree in Math from the University of Waterloo in Waterloo, Canada, and an M.Sc. and Ph.D. from the University of British Columbia in Vancouver, Canada. Following a postdoctoral fellowship at the University of California at Berkeley, he joined the Department of Computer Science at North Carolina State University, where he is currently an Associate Professor. His research interests include visualization, graphics, visual perception, and areas of applied mathematics, databases, artificial intelligence, and aesthetics related to visual analysis and data management.

References

Cohen, Varshney, Manocha, Turk, Weber, Agarwal, Brooks, and Wright (1996). Simplification envelopes. In: ACM SIGGRAPH ’93 Conference Proceedings. New Orleans, Louisiana; pp. 119–28.

Cozzi, P. and Loo, B. T. (2008). Parallel Processing City Models for Real-Time Visualization. http://www.seas.upenn.edu/~pcozzi/PreprocessingCityModels.pdf.

Dehne, Langis, and Roth (2000). Mesh simplification in parallel. In: Proceedings 4th International Conference on Algorithms and Architectures for Parallel Processing. Hong Kong; pp. 281–90.

Garland and Heckbert (1997). Surface simplification using quadric error metrics. In: ACM SIGGRAPH ’97 Conference Proceedings. Los Angeles, Cal.; pp. 209–16.

Garland and Heckbert (1998). “Simplifying surfaces with color and texture using quadric error metrics. In: Proceedings IEEE Visualization ’98, Research Triangle Park, NC; pp. 263–9.

Hoppe, DeRose, Duchamp, McDonald, and Stuetzle (1993). Mesh optimization. In: ACM SIGGRAPH ’93 Conference Proceedings, Anaheim, Cal.; pp. 19–26.

Hoppe (1996). Progressive meshes. In: ACM SIGGRAPH ’96 Conference Proceedings, New Orleans, Louisiana; pp. 99–108.

Hu, Sander, and Hoppe (2009). Parallel view-dependent refinement of progressive meshes. In: Proceedings of the 2009 Symposium on Interactive 3D Graphics. Boston, Mass.; pp. 169–76.

Rasch and Schmidt (2000). Parallel mesh simplification. In: Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Algorithms (PDPTA 2000). Las Vegas, Nev.

Tang, Jia, and Li (2007). Simplification algorithm for large polygon model in distributed environment. In: Lecture Notes in Computer Science: Advanced Intelligent Computing Theories and Applications with Aspects of Theoretical and Methodological Issues. Heidelberg, Germany: Springer-Verlag; pp. 960–9.

Turk and Levoy (1994). Zippered polygon meshes from range images. In: ACM SIGGRAPH ’94 Conference Proceedings. Orlando, Flo.; pp. 311–8.

Walter and Healey (2001). Attribute preserving dataset simplification. In: Proceedings IEEE Visualization 2001, San Diego, Cal.; pp. 113–20.

Yongquan, Nan, Pengdong, Chu, Jintao, and Rui (2009). A parallel memory efficient framework for out-of-core mesh simplification. In: Proceedings 11th International Conference on High Performance Computing and Communications (HPCC-09). Seoul, Korea; pp. 666–71.

Techniques for Optimizing and Tuning Video Applications

The collaborative relationship between Sonic Solutions and Intel extends back several years and has yielded significant benefits in numerous areas and on multiple platforms. Among the recent platforms from Intel that have been targeted for upcoming software releases from Sonic are:

• Intel® X58 Express chipset
• Intel® Core™2 Duo processor
• Intel® Centrino®2 processor technology
• Intel® Core™ 2 Extreme processor
• Intel® Core™ i7 processor
• Intel® Core™ i7 mobile processor

Sonic Solutions’ integration of the Intel® Media Software Development Kit (Intel® Media SDK) into Roxio CinePlayer* and Roxio Creator* 2010 provides the advantages of hardware acceleration on today’s graphics platforms with support for future graphics platforms, as well. The video copy-and-conversion feature in Creator 2010 was also optimized to enhance performance and responsiveness through the use of multi-threading. Intel provided assistance in this engineering effort, and Sonic Solutions used a number of tools from the Intel® Software Development Products offering, including the Intel Media SDK, Intel® Threading Building Blocks, Intel® VTune™ Performance Analyzer, Intel® Thread Profiler, and others. The Intel Media SDK, in particular, delivered a productivity boost and the reliability of proven, refined codec performance to the Sonic development team.

Roxio CinePlayer* Enhancements

Providing a cost-effective way to decode and play back DVDs on PCs, Roxio CinePlayer has built a solid customer base in the consumer market for its high-quality video and crisp audio delivery. The Windows Vista*-compatible player provides full support for Dolby Digital 5.1 Surround Sound and handles InterActual* content embedded on DVDs. During the engagement with Intel, engineers focused on enhancing playback of high-definition (HD) video content when running on computers equipped with the Intel® G45 Express chipset. To this end, the Intel Media SDK proved useful in providing developers streamlined access to the hardware acceleration features offered by a key component of the Intel G45 Express chipset: the Intel® Graphics Media Accelerator X4500HD (Intel® GMA X4500HD) with built-in support for 1080p HD video playback.

The hardware acceleration helps provide an enhanced end-user experience through faster decoding of MPEG-2, AVC, and VC1 video content—whether from DVD or streamed from the Internet.

Download Full PDF (428kb)

In this article, Anatoliy Kuznetsov answers the questions and tells us about the open BitMagic C++ Library.

Introduction

In my regular browsing through 64-bit programming related websites, I often came across references to BitMagic C++ Library and realized that it had benefited a lot from using 64-bits. I decided to contact the author asking him to give us an interview about his research and developments.

Questions are asked by: Andrey Karpov - in-house developer at OOO "Program Verification Systems currently" working on PVS-Studio tool designed for verification modern C++ applications.

The answers are given by: Anatoliy Kuznetsov - chief software engineer at NCBI; developer of the open source BitMagic C++ Library.

Anatoliy, please tell us a few words about yourself. What projects are you involved in?

I am a chief software engineer, at present I am working for the bio-molecular data discovery and visualization team at NCBI (National Center for Biotechnology Information). Apart from my primary job, I am the chief developer and architect of the open-source BitMagic C++ Library.

I am a planning engineer by education, a graduate of the Lobachevskiy University of Nizhniy Novgorod.

What is BitMagic?

BitMagic has been developed as a universal template library for processing compressed bit vectors. The library solves several tasks:

It provides a bit container which is really compatible with STL in terms of ideology. It means that such container must support iterators, memory allocators and interact with algorithms and other STL containers.

The library can efficiently operate on very long and sparse vectors.

It enables the serialization vectors for further writing to a database or sending them over a network.

A developer is provided with a set of algorithms to implement set-theory operations and calculate distances and similarity metrics in multidimensional binary spaces.

Much consideration is given to optimization for popular fast calculation systems such as SSE.

What tasks addressed by BitMagic make it so attractive for developers?

The library turned out to be fairly a one-stop solution and apparently it won’t be easy to list all its possible applications. At present, the library offers more compelling results in the following spheres:

Bit and inverted indexes building for full-text search systems, acceleration of relational algebra operations (AND, OR, JOIN etc).

Development of non-standard extensions and indexes for existing databases (Oracle Cartridges, MS SQL extended stored procedures). Generally, such extensions help integrate scientific, geographic and other non-standard data into the database.

Data mining algorithms development.

In-memory indexes and databases development.

Development of precise access isolation systems with a large number of objects (security enhanced databases with the isolation of access to specific fields and columns).

Task management systems (for the computation cluster), real-time task state tracking systems, and the storage of task states described as Finite State Machines.

Tasks related to the representation and storage of strongly connected graphs.

What can you tell about the history of BitMagic development? What motivated you to create it?

For a long time my colleagues and I had worked on tasks related to large databases, analysis and visualization systems. The initial working version demonstrating bit-vector capabilities was produced by Maxim Shemanaryov (he is the developer of Antigrain Geometry, a wonderful 2D vector graphics library: http://www.antigrain.com). Then, some ideas for an equivalent representation of data sets were described by Koen Van Damm, an engineer from Europe, who worked on programming language parsers for the verification of complex systems. There were other sources as well. I decided to bring them all together in the form of a library suitable for repeated use in various projects.

What license BitMagic is distributed under? Where I can download it?

The library is free for commercial and non-commercial use and is available in the form of source texts. The only limitation is the the requirement to give credit to the library and its authors if you are using it in a released product.

You can check out all the materials here: http://bmagic.sourceforge.net.

Am I right saying that BitMagic has significant advantage if compiled as a 64-bit version?

Yes indeed, the library uses a series of optimization methods to accelerate processing in 64-bit systems or SIMD-enabled systems (128-bit SSE2).

Here are some factors leading to a faster execution of algorithms:

a wide machine word (logical operations are performed over a wide word);

the programmer (and the compiler) has access to additional registers and the lack of registers is not so critical (this an inherited disadvantage of x86 architecture);

memory alignment often makes the operation faster (128-bit alignment of addresses provides good results);

and of course it’s possible to place more objects and data for processing in a program’s memory. That’s a great benefit of the 64-bit version, which is clear to everyone.

At the moment the fastest method is to use 128-bit SSE2 optimizations with a 64-bit program. This mode combines the double number of x86 registers with a wide machine word to perform logical operations.

64-bit systems and programs are going through a real Renaissance. The migration to 64-bits will be faster than the move from 16 to 32. The launch of 64-bit Windows versions in the mainstream market and the availability of related tools (like the one your company is developing) will stimulate this process. In the environment of increasingly complex systems and larger amounts of code, such tools as PVS-Studio will be of great practical utility as they help reduce labor costs and the time to market.

Please tell us about the compression methods used in BitMagic.

The current 3.6.0 version of the library uses several compression methods.

"Bitvectors" in memory are split into blocks. When a block is not occupied or is occupied fully, it won’t be allocated. That is, the programmer can set bits in a wide range very far from zero. Thus setting a 100,000,000 bit won’t result in an exploded memory use which is often common to vectors with a two-dimensional linear model.

Blocks in memory can have an equivalent representation in the form of areas – the so-called gaps. Actually that’s a sort of RLE coding. Unlike RLE, our library doesn't lose the capability to execute logical operations or access random bits.

When serializing "bitvectors", a set of different methods is used: conversion to lists of integer numbers (representing nulls or ones) and list coding by the Elias Gamma Coding method. When implementing these methods, we do lose the random bit access capability but it is not so critical for disk writes if compared with reduced storage and input-output overheads.

Could you give some code examples demonstrating possible uses of BitMagic?

The first example simply creates 2 vectors, initializes them and performs the logical operation AND. Further, the enumerator class is used for the iteration and printing of values saved in the vector.

#include <iostream>
#include "bm.h"
using namespace std;
int main(void)
{
    bm::bvector<>   bv;    
    bv[10] = true; bv[100] = true; bv[10000] = true;
    bm::bvector<>   bv2(bv);    
    bv2[10000] = false;
    bv &= bv2;
    bm::bvector<>::enumerator en = bv.first();
    bm::bvector<>::enumerator en_end = bv.end();
    for (; en < en_end; ++en) {
        cout << *en << endl;
    }
    return 0;
}

The next example demonstrates vector serialization and the use of compression.

#include <stdlib.h>
#include <iostream>
#include "bm.h"
#include "bmserial.h"
using namespace std;
// This procedure creates very dense bitvector.
// The resulting set will consists mostly from ON (1) bits
// interrupted with small gaps of 0 bits.
//
void fill_bvector(bm::bvector<>* bv)
{
    for (unsigned i = 0; i < MAX_VALUE; ++i) {
        if (rand() % 2500) {
            bv->set_bit(i);
        }
    }
}
void print_statistics(const bm::bvector<>& bv)
{
    bm::bvector<>::statistics st;
    bv.calc_stat(&st);
    cout << "Bits count:" << bv.count() << endl;
    cout << "Bit blocks:" << st.bit_blocks << endl;
    cout << "GAP blocks:" << st.gap_blocks << endl;
    cout << "Memory used:"<< st.memory_used << endl;
    cout << "Max.serialize mem.:" << 
            st.max_serialize_mem << endl << endl;;
}
unsigned char* serialize_bvector(
  bm::serializer<bm::bvector<> >& bvs, 
  bm::bvector<>& bv)
{
    // It is reccomended to optimize 
    // vector before serialization.
    bv.optimize();  
    bm::bvector<>::statistics st;
    bv.calc_stat(&st);
    cout << "Bits count:" << bv.count() << endl;
    cout << "Bit blocks:" << st.bit_blocks << endl;
    cout << "GAP blocks:" << st.gap_blocks << endl;
    cout << "Memory used:"<< st.memory_used << endl;
    cout << "Max.serialize mem.:" << 
             st.max_serialize_mem << endl;
    // Allocate serialization buffer.
    unsigned char*  buf = 
        new unsigned char[st.max_serialize_mem];
    // Serialization to memory.
    unsigned len = bvs.serialize(bv, buf, 0);
    cout << "Serialized size:" << len << endl << endl;
    return buf;
}
int main(void)
{
    bm::bvector<>   bv1;    
    bm::bvector<>   bv2;
   //  set DGAP compression mode ON
    bv2.set_new_blocks_strat(bm::BM_GAP);  
    fill_bvector(&bv1);
    fill_bvector(&bv2);
    // Prepare a serializer class 
    // for best performance it is best 
    // to create serilizer once and reuse it
    // (saves a lot of memory allocations)
    //
    bm::serializer<bm::bvector<> > bvs;
    // next settings provide lowest serilized size 
    bvs.byte_order_serialization(false);
    bvs.gap_length_serialization(false);
    bvs.set_compression_level(4);
    unsigned char* buf1 = serialize_bvector(bvs, bv1);
    unsigned char* buf2 = serialize_bvector(bvs, bv2);
    // Serialized bvectors (buf1 and buf2) now ready to be
    // saved to a database, file or send over a network.
    // ...
    // Deserialization.
    bm::bvector<>  bv3;
    // As a result of desrialization bv3 
    // will contain all bits from
    // bv1 and bv3:
    //   bv3 = bv1 OR bv2
    bm::deserialize(bv3, buf1);
    bm::deserialize(bv3, buf2);
    print_statistics(bv3);
    // After a complex operation 
    // we can try to optimize bv3.
    bv3.optimize();
    print_statistics(bv3);
    delete [] buf1;
    delete [] buf2;
    return 0;
}

What are your plans for BitMagic further development?

We want to implement some new vector compression methods with parallel data procession capability.

In view of the mass expansion of Intel Core i5-i7-i9, it would be reasonable to release a SSE 4.2 version of the library. Intel has added some interesting features that can be used very efficiently. The most promising feature is hardware support for bit number calculation (Population Count).

We are experimenting with nVidia CUDA and other GPGPUs. Today graphic cards enable you to perform integer and logical operations - and their resources can be harnessed for algorithms working on data sets and compression.

References

1. Elias Gamma encoding of bit-vector Delta gaps (D-Gaps). http://bmagic.sourceforge.net/dGap-gamma.html
2. Hierarchical Compression. http://bmagic.sourceforge.net/hCompression.html
3. D-Gap Compression. http://bmagic.sourceforge.net/dGap.html
4. 64-bit Programming And Optimization. http://bmagic.sourceforge.net/bm64opt.html
5. Optimization of memory allocations. http://bmagic.sourceforge.net/memalloc.html
6. Bitvector as a container. http://bmagic.sourceforge.net/enum.html
7. 128-bit SSE2 optimization. http://bmagic.sourceforge.net/bmsse2opt.html
8. Using BM library in memory saving mode. http://bmagic.sourceforge.net/memsave.html
9. Efficient distance metrics. http://bmagic.sourceforge.net/distopt.html

Q15: How can I use my own SW library for encoding or decoding instead of using the Intel supplied library?
A15: Replace libmfxsw32.dll or libmfxsw64.dll with your own SW library DLL. Use the same naming, and place into your unique install directory.

Download PDF

Get Into the Game Faster

Gauging Reactions

Balancing Performance Across the Whole System

Comparing Memory Cell Technologies

Mobile Computing Perks

• Improved system performance-up to 50 percent improvement of system-level benchmarks
• Improved battery life (systems ran about 50 to 70 minutes longer between charges)
• Decreased support costs
• Quicker installation times for operating systems and applications
• No need for disk fragmentation software

Enterprise Advantages

The Last Word

*Other names and brands may be claimed as the property of others.

Building the Moblin Media Player Gui with the Intel Compiler

Introduction

The media player project is know as Hornsey and depends on clutter, clutter-gst, bickley, nbtk, bognor-regis, libunique, libstartup-notification and gtk+-2.0.

For the build enironment I am using the Moblin2 development image installed on a dualcore laptop. 

In this paper, I am only building the top level of the player, and not the underlying library dependencies.

Setting up the build environment 

Download and install the moblin dev image from here

http://moblin.org/documentation/moblin-sdk/download-development-images6

Create a USB or CD and install. Instructions here:

http://moblin.org/documentation/test-drive-moblin/using-moblin-live-image

Building the media player gui

Downloading the sources

Boot up Mobln2

In directory of your choice get the Hornsey code

    git clone git://git.moblin.org/hornsey

Directory structure should look similar to this:

    <dev dir>/hornsey

Go into the hornsey directory and change the branch to match  the moblin dev image
e.g.  

         cd hornsey
         git checkout –b origin/moblin-2.0

 FYI you can get a list of branches by doing
      
        git  branch –a
 

Building the sources

Choosing which compiler

Building with GCC

For our installation, we'll use the environment variable  $PREFIX custom directory so as not to override any existing installation

     export PREFIX=~/dv/hornsey/gcc
    ./autogen.sh --prefix=$PREFIX

Building with ICC

To build the library with the Intel compiler use the following commands

    export CC=icc
    export CXX=icc
    export CFLAGS="-02 -g"
 

   export PREFIX=~/dv/hornsey/icc
  ./autogen.sh --prefix=$PREFIX

Continuing the build

When autogen has completed you should get a message similar to the display below 

      config.status: config.h is unchanged
      config.status: executing depfiles commands
      config.status: executing default-1 commands
      config.status: executing po/stamp-it commands
      Now type `make' to compile hornsey

Now build the source by calling make

       
        make clean

        make

The progress of the make will be reported, the last few lines looking similar to this:

          CC    hrn-controls.o
          CC    nbtk-im-label.o
          CC    hornsey
        Making all in data
        Making all in po

Installing the media player

To install the new new media player call:

      make install

Checking the contents of the install dir :

ls -R  $PREFIX

    /home/sblairch/dv/hornsey/gcc:
                bin  share

    /home/sblairch/dv/hornsey/gcc/bin:
                hornsey

    /home/sblairch/dv/hornsey/gcc/share:
                applications  dbus-1  hornsey  icons  locale

Running the Media Player

The media player can be invoked by simple calling the executable  <install dir>/bin/hornsey

Introduction

Background/Workloads measured

• Free faces (Figure 1) are the internal and external faces of the model's finite elements where a fringe plot is rendered.
• The clustering of the finite element IDs for the elements whose free faces are being rendered directly affects the result data retrieval time.
• The dimensionality of the data (i.e. scalar, vector, tensor data type) directly affects the number of data values that are retrieved for post-processing.
• The complexity of the engineering derivation that is applied to the initial analysis data to transform it from either a vector or tensor data type to a scalar data type for fringe plot rendering also plays a roll.

Threading SimXpert - Phase One

  for (size_t i=0; i<Size;++i) { 
         deriveFunc(ptr_inArray,ptr_outArray); 
         ptr_inArray += inStride);
         ptr_outArray += outStride); 
  }

for (size_t i=0;i<Size; ++i) {
     deriveFunc(ptr_inArray[k* inStride],
			ptr_outArray[k * outStride]);
}

Threading SimXpert - Phase Two

• 3D solid finite element simulation model representing the casting of a V6 engine block (modelsec.xdb) with 98,814 free faces and a 358.7MB file size achieved a 28% performance improvement
• 3D solid finite element simulation model representing a turbine blade (xx0kst0.xdb) with 65,416 free faces and 513.3MB file size achieved between 3 and 10% performance improvement for various plots
• 3D solid finite element simulation model representing a casting of kitchen appliance housing (xx0ust0.xdb) with 90,460 free faces and a 281.7MB file size achieved between 6 and 26% performance improvement for various plots
• 2D and 3D finite element simulation model representing a car chassis (xx0o.xdb) with 1,209,323 free faces and a 438.8MB file size achieved between 19 and 27% performance improvement for various plots
• 3D solid finite element simulation model representing the central hub of an aircraft propeller (xx0fst0.xdb) with 89, 935 free faces and a 165.2MB file size achieved between 10 and 30% performance improvement for various plots
• 3D solid finite element simulation model representing the casting of a straight 6 engine block (xx0jst0.xdb) with 461,808 free faces and a 1028.5MB file size achieved between 15 and 44% performance improvement for various plots

MSC.Software Testimonial

Next Steps

Conclusion

MSC.Software SimXpert

About the Authors

Consolidation Opportunities

At yearend 2004, the typical U.S. Fortune 500 corporation contained fewer than 300 server database instances. By the end of 2009, the number will have increased to more than 2,000. Similar trends have occurred in midsize business, in the public sector and in other types of organization worldwide. The fastest rates of growth have been among databases deployed on small x86 servers.

Multiplication of server databases has contributed to “server sprawl,” resulting in low levels of utilization, unnecessary duplication of resources, and inflation of system administration and facilities costs.

Although server consolidation has become pervasive, to date it has been more commonly applied to application and infrastructure servers, rather than database servers. Database consolidation has often raised complex performance issues, making it more difficult to plan for and prepare for initiatives.

One implication is that, in many organizations, the potential for database server consolidation has been little exploited. At a time of economic pressures, it is an obvious area of potential cost savings. Key technology shifts have made consolidation increasingly viable. More powerful multicore processors, along with the growing sophistication of server and database platforms are creating new opportunities.

This report examines the cost savings that may be realized by upgrading and consolidating IBM DB2 databases. Three-year costs are compared for the following:

• 2005 technologies: DB2 Version 8.2 is deployed on xSeries 335 two-socket servers with singlecore Intel Xeon processors and the Windows Server 2003 operating system.
• Current technologies: DB2 Version 9.7 is deployed on (1) IBM System x3550 M2 two-socket servers with quad-core Intel Xeon 5500 processors, and (2) IBM System x3850 M2 four-socket servers with six-core Intel Xeon 7400 processors. The Windows 2008 operating system is employed on both System x platforms.

Savings are realized in a number of areas, including hardware maintenance, support for DB2 databases and Windows operating systems, and system administration and energy costs.

Calculations for DB2 9.7 deployed on System x3550 M2 and x3850 M2 servers allow for transition costs. These include acquisition and installation of new servers, along with database consolidation, staff retraining and related costs.

Cost Comparisons

Comparisons are based on six installations with between 25 and 231 DB2 instances employed for a variety of applications in manufacturing, aerospace, government, IT services, insurance and financial services organizations.

Numbers of instances, servers and full time equivalent (FTE) system administration (sysadmin) personnel for use of 2005 technologies are based on user-supplied data. Although organizations employed a variety of two-socket x86 servers, installed bases were normalized to use of DB2 8.2 and IBM xSeries 335 server
models for calculation purposes.

Scenarios were then developed for migration of DB2 instances to the latest DB2 Version 9.7 and consolidation of these to System x3550 M2 and x3850 M2 servers. Scenarios draw upon the experiences of more than 30 organizations that have conducted DB2 consolidation initiatives. They are consistent with “best practice” norms for the numbers of instances and workloads that may run on these platforms.

DB2 instances include mixes of DB2 Enterprise Edition and Workgroup Edition, while servers are configured with Enterprise and Standard Editions of Windows Server 2003 and (for Current Technologies scenarios) Windows Server 2008.

Software support costs include IBM Software Maintenance (SWMA) and Microsoft Software Assurance for DB2 and Windows Server licenses respectively. Hardware, maintenance and software support costs are calculated based on “street” prices; i.e., discounted prices paid by the organizations upon which
installations are based.

Current Technologies scenarios do not include use of virtualization tools such as VMware and Microsoft Hyper-V. Although these may be employed to support multiple database instances, organizations that contributed to this report were able to achieve high levels of database consolidation without them.

Download the rest of the PDF here.

Admit it. For the past 25 years, you ain’t been afraid of no ghosts. Thanks to a certain movie about four intrepid heroes, we all know a well-aimed proton stream and a handy trap can bag any ghoul within range. The venerable Ghostbusters* franchise has spun out at least eight different video games since 1984, each taking advantage of the movie’s supernatural feel and sci-fi effects. The newest version Ghostbusters: The Video Game has received good reviews since its release earlier in 2009, thanks in no small part to its updated effects.

As Mark Randel, president and chief technology officer of Terminal Reality, Inc. described it in his blog, “The results of having a massively parallel game engine were stunning. When we finally got rendering and simulation of the game in parallel in the last weeks of Ghostbusters, the game became solely render-bound. Jobs were totally asynchronous, and we were able to fully utilize three to four cores. When there wasn’t any action in the game, the game was waiting on the vertical blank. With a lot of action, the job model allowed the heavy lifting to be absorbed over as many processors as the system had.”

The game is published by Atari, who wanted a great mainstream game to reach the largest possible target market. Atari pushed the team to make sure the game was optimized for integrated graphics systems, in order to maximize their investment and ensure good performance.The developers at Terminal Velocity took extensive advantage of Intel® Graphics Performance Analyzers (Intel® GPA) and their membership in the Intel® Software Partner Program to bring out the best special effects required to chase down vapors, slimers, and poltergeists. Intel’s tools helped identify a performance bottleneck so the game could be optimized for desktops and laptops that use Intel® Graphics processors. And once performance problems are solved for the Intel® Graphics world, they are essentially solved for the rest of the graphics universe.

Thanks to fine-tuning for multi-core and extensive testing for bottlenecks, Ghostbusters: The Video Game really shines, especially on the newest Intel-based systems. What follows is a step-by-step analysis performed on an exceptionally low-performing scene in Ghostbusters: The Video Game by a team consisting of both Intel and Terminal Reality developers. The team’s comprehensive work is a model for anyone who wants to troubleshoot similar game-performance issues.

Optimizing a Slow Game Scene
Jeff LaFlam and Shankar Swamy, application engineers with the Intel® Visual Computing Enabling Team, worked with Mark Randel, president and chief technology officer of Terminal Reality, Inc., to detect and analyze a serious bottleneck in a specific scene in Ghostbusters. This scene was running so slowly, and with a barely acceptable frame rate, that the gameplay was visually stuttering. This scene had stymied progress in optimizing the game’s overall performance.

The troublesome scene contains about 200,000 books in a library where two human characters and a “ghost” character might interact. When the characters are fully outside the library they cannot see the books; hence, there is no need for the game to render the books. However, as a character enters the library, the books are gradually exposed to the viewer and displayed in the gameplay scene.

The team of LaFlam, Swamy, and Randel analyzed this scene to determine solutions for increasing the frame rate.

Step 1: Visually Analyze the Scene
The team began by visually analyzing the entire scene sequence in order to determine a direction for further investigation.

The team observed that when a character was staring at the wall and the books were partially exposed, the frame rate was very low and the scene stuttered (Fig. 1). When they then advanced the scene and moved a character closer to the wall but with no books visible in the scene, the frame rate did not change noticeably. This indicated to the team that the books were being rendered in the scene even when they were not visible.

Step 2: Render with Z-Test Disabled
The goal of the second step in the analysis was to determine how many occluded objects were being rendered in the library scene. This was done by rendering all the objects in the scene with the Z-test disabled.

In Figure 2, notice that the character is standing very close to the wall and staring directly at it. Prior to optimizing this scene, during normal gameplay (with the Z-test enabled), the books shown would not be visible because of the direction the character is looking. However, because the team disabled the Z-test for Figure 2, all the books being rendered by the game are also now visible.

This confirmed that books are being rendered all the time—even when they are completely occluded during normal gameplay. Of course, only the books that are visible to the characters at any point in the game play need to be rendered.

Step 3: Conduct a Single-Frame Analysis

The team wanted to investigate other possible hot spots in the scene by using the Intel® GPA Frame Analyzer.

According to the Intel® GPA Frame Analyzer, the Library scene had 12,564 Draw() calls (Fig. 3). However, other scenes in the game typically had about 3,000 Draw() calls, and those scenes had higher frame rates. The conclusion was that there were too many Draw() calls in the Library scene, indicating to the team that further testing should be aimed at reducing the number of Draw() calls in the troublesome scene. The team also wanted to investigate how many of these calls were coming from the rendering of the books.

Step 4: Estimate the Cost of Rendering the Books
The team placed the camera in front of a wall that had no objects behind it. Because this is a third-person view game, the characters in the Library scene are still rendered—as they should be. However, the books, which are now behind the camera, are invisible and should not be submitted for rendering due to the game’s culling algorithm.

The team wanted a reliable estimate of the cost of rendering the books. By submitting the scene to the Intel GPA Frame Analyzer (Fig.4), the team discovered the scene had 14,731 Draw() calls, confirming that the books were quite expensive to render. In fact, the overhead of rendering the books is significant enough that it negatively affected the frame rate when the books were occluded yet still rendered.

Step 5: Verify the Potential Gains
Next, the team included a software switch in the graphical user interface (GUI) that allowed them to completely turn off rendering for all the books (whether visible or occluded). They then rendered the scene by dynamically turning this switch on and off, allowing them to determine the change in frame rate when books were rendered versus when they weren’t.

When book rendering was turned off, the frame rate increased by approximately 2.5 times, as shown by the data from the Intel® GPA System Analyzer within the red oval in Figure 5. this indicated that the cost of rendering the books in the scene was quite high.

At this point in the analysis, the obvious options for increasing the performance of this scene were either:
  •  Don’t render the books that aren’t visible in the scene, or 
  •  Reduce the number of books in the scene.

Step 6: A Third Solution is Created

When the Intel team shared their findings with the developers at Terminal Reality, Mark Randel suggested—and implemented—a third solution: a “pixel height test.”

Figure 6 shows the idea behind the pixel height test.  The bounding sphere of an object is shown as circles in Figure 6 and indicates the pixel coverage on the screen required for that object either when the object is close to the camera or when it is farther away.

Using the pixel height test on the objects in a scene, the test can determine which objects contribute less than one full pixel to the displayed frame. To approximate the pixel coverage, the test determines the object height in screen space in pixels. This testing code is executed on the processor. As a result of the pixel height test, if the pixel height of an object is less than a pixel, the object is not submitted for rendering.

In the troublesome Library scene, the fact that the objects (books) all had identical dimensions—because they are instantiations of a single object—made the test easier and faster to run because the bounding spheres for all tested objects (books) were identical.

Step 7: The Results of the Pixel Height Test
Figure 7 shows the result of implementing the pixel height test on the Library scene in Ghostbusters. Using the software switch created by Randel, developers were able to turn the test on and off. When the pixel height test is running, objects (books) that are less than one pixel in height in the scene, are not rendered. As shown by the data in the green oval in Figure 7, where the test was turned on, the frame rate of this scene doubled when the books less than one pixel in height were not rendered.

The data in Figure 7 also shows that the overall usage of the graphics resources went up, with the test indicating that the game was now using resources more optimally.

Figures 8 and 9 are the screen captures of the scene before and after the test was enabled. There is no visual difference between the two renderings, because no visible object was affected by the change.

When the team first started this analysis, the scene was rendering so slowly that it was considered the major issue preventing the game from being highly playable. Based on a thorough analysis and the implementation of the pixel height test that followed, the scene ended up rendering at double the original frame rate. Other scenes in the game enjoy even higher frame rates.

New Features for Intel® GPA, Version 2.1
As good as the Intel® GPA tool was for the development of the latest Ghostbusters game, several new features have been added subsequent to that project. Randel reports that he is finally enjoying a little downtime after working since 2006 on Ghostbusters, but he’s already looking forward to the next project. “It will be really nice to have the new Intel GPA tools,” he said recently. “There are still a few more things we can do to add those key details to a highly believable, fully destructible environment.”

Here are some of the key new features that have been added to the Intel GPA to make it even easier to find and quickly address performance issues in games, as well as debug rendering problems:

• Pixel History
Pixel history is a great new feature in Intel GPA that provides a wealth of information on any pixel in any render target. A zoom feature (using the mouse wheel) was also added for a more exact selection of a particular pixel of interest. To select a pixel, simply left-click a pixel in any render target. After a pixel is selected, the history of all GPU operations (draw calls, clears, and so on) that affected that pixel is displayed in the pixel history tab, which is automatically opened. This lets you see exactly which draw calls affected that pixel location for the render target from which it was selected. For each draw call in the list, the number of times the pixel was touched and the final pixel
color are also displayed. If the pixel was rejected, for example if Z-test was enabled, the reason for the rejection is noted as well.

Pixel history enables two key use cases: visual debug and overdraw analysis. The visual debug workflow allows you to diagnose why a pixel was rendered incorrectly. It also shows which draw call in the history caused the selected pixel to be the color that it is. The overdraw analysis workflow depicts how much overdraw exists at any pixel location and specifically which draw calls contribute to it.

• Overdraw Visualization per Render Target
The Intel GPA render target viewer has a new overdraw visualization mode. When enabled, each render target is visualized in gray scale. Overdraw corresponds to lighter pixels in the gray-scale visualization. By enabling this mode, you can immediately see which portions of the render target are being written to most often.

Intel GPA also allows you to combine the usage of both pixel history and overdraw visualization. This allows you to seamlessly find overdraw hotspots with the visualization and then immediately select any of the hot pixels to understand which draw calls are contributing to overdraw at that location.

• Vertex Shader and Pixel Shader Durations
Shader durations are now enabled as metrics for all DirectX* devices. These metrics are available in three places: the bar chart graph at the top of the user interface, the scene overview spreadsheet view on the left, and the details tab on the right.

With the bar chart, you can now select any metric in the x- and y-axis. For example, you can configure vertex shader duration in the x-axis and pixel shader duration in the y-axis. By looking at the shape of each rectangle in the bar chart you now can compare two metrics at the same time. Within the scene overview, you can view these new metrics in spreadsheet form by clicking the Customize button, and then selecting any metrics of your choice. Finally, the details tab always lists all possible metrics and enables you to view their values summed across the current draw call selection set.

• Single Step Frame
Intel GPA has a new single step feature that enables better control over the frame to be captured and analyzed. When using the System Analyzer, simply press the pause button to pause the game in real time, then press the single step button as many times as needed to reach a frame of interest. The capture button can be pressed at any time.

• In-Game Hot Key
The new hot-key feature allows easy frame captures on a single computer while playing the game. Simply launch the game using Intel GPA, run it full screen, and then press CTRL+SHIFT+C (or configure any keys you want to use) for each frame you want to capture. When you are ready to analyze, close the game, and then open the Frame Analyzer on the same computer or a remote system for analysis.

• Export Metrics to a CSV File
With CSV (comma separated value) file export, detailed frame performance data can be saved and later pulled into Microsoft Excel* or any other program that can process CSV files. This feature allows you to track game performance changes over time, compare game performance with various game options enabled, or even compare game performance on various graphics cards—all at a per-draw level of detail.

Because this feature is draw call selection set-based, you can select the draw calls you are interested in (or the whole frame) and export only those calls, so you don’t have to wade through large amounts of data to find the details you want.

Conclusion
Intel GPA tools help game developers make sure that performance issues don’t detract from a game’s entertainment value. Developers can run code experiments that measure and report performance results in real time. Intel GPA provides open, accessible libraries that can both customize tools for specific needs and pull data for deeper analysis. Better use of screen real estate avoids the intrusive display overlay of other interfaces, and the ability to share captured frames with team members increases the efficiency of optimization.

Thanks to the Intel® GPA tools, developers can learn more about what’s going on “behind the curtain” on their games. The new features take an already strong engineering toolset and turn it into a formidable asset manager. Thanks to interaction with game developers around the world, Intel continues to fine-tune these tools. Priced at USD 299, the Intel GPA tools are free to anyone willing to take the time to fully register. Go to www.intel.com/software/gpa and grab the tools and the documentation, read the case studies and white papers, and get involved in the developer forums. Your game’s performance—and fun factor—are at stake.

Capture the buzz. Subscribe to Intel® Software Dispatch for Visual Adrenaline. (Did we mention it's fun, informative, visually stimulating, free, and you can unsubscribe at any time?)