Downloads

Figure 1. Convex polyhedra interacting with a vortex particle fluid

Convex Obstacles

Video games are compelling because they are interactive. Even visual effects should respond to other entities in the environment, especially those the user controls. Particle effects, including fluids, should therefore respond to rigid bodies of any shape. Those shapes should include airfoils that can experience lift.

This article—the thirteenth in a series—describes how to augment the fluid particle system described earlier, interact with rigid bodies with any polyhedral shape, and generate a lift-like force on those bodies. Part 1 summarized fluid dynamics; part 2 surveyed fluid simulation techniques. Part 3 and part 4 presented a vortex-particle fluid simulation with two-way fluid–body interactions that runs in real time. Part 5 profiled and optimized that simulation code. Part 6 described a differential method for computing velocity from vorticity, and part 7 showed how to integrate a fluid simulation into a typical particle system. Part 8 explained how a vortex-based fluid simulation handles variable density in a fluid; part 9 described how to approximate buoyant and gravitational forces on a body immersed in a fluid with varying density. Part 10 described how density varies with temperature, how heat transfers throughout a fluid, and how heat transfers between bodies and fluid. Part 11 added combustion, a chemical reaction that generates heat. Part 12 explained how improper sampling caused unwanted jerky motion and described how to mitigate it.

Collision Detection

Detecting collisions between objects first entails computing the distance between them. Video games model most shapes with planar, polygonal faces and treat particles as though they have spherical shape. You therefore need to compute the distance between planes and spheres.

A plane is a two-dimensional surface in a three-dimensional space. You can define a plane in various ways. One convenient representation uses a normal vector and a distance, d. The plane equation has this formulation:

All points with coordinates that satisfy this equation lie within the plane. When has unit length (), d is the distance of the plane from the origin. You can use this value to represent a plane as a vector with four components (that is, a 4-vector plane): or .

The distance, D, of a point from the plane is:

Notice that this equation has the same form as the equation for the plane, except that instead of equating it to zero, the formula tells you the distance of the point to the plane. This is obviously consistent because if a point has zero distance to the plane, then the point lies in the plane.

But wait a moment! This formula could result in negative values. For example, choose the point and the plane with and d = 1. The formula claims that point has negative distance from the plane. What the heck is negative distance?

A plane divides all of space into two halves. A half-space is the region of space on one side of a plane. The signed distance formula tells you whether a point lies in the positive half-space or the negative half-space of a plane, as Figure 2 depicts.

Figure 2. Planes and half-spaces

Think of a plane as facing in the direction of its normal. Points behind the plane have negative distance. Points in front of the plane have positive distance. When a point lies behind a plane, we call its distance (which is negative) the penetration depth.

The Plane class shows an implementation of the planar formulae that builds upon a 4-vector class (Vec4):

You can compute the distance of a sphere from a plane by computing the distance of the sphere's center (a point) from the plane, then subtracting the sphere's radius.

Note: Technically, planes exist in other dimensions. For example, in a two-dimensional space, a plane is also a line. In a four-dimensional space, a plane is a three-dimensional hyperplane. But this article discusses three-dimensional spaces, where planes are two dimensional.

Planes Make Convex Hulls

A polytope is a shape with flat sides. In two dimensions, polytopes are called polygons. In three dimensions, polytopes are called polyhedra.

A convex shape is one where any line segment between any two points in the shape is also in that shape. So, a convex polytope is such a shape with flat sides, as shown in Figure 3.

An array of planes can represent a convex polyhedron. You can describe each face, i, of the polyhedron using a plane representation, . This is called a half-space representation (or H-representation).

Figure 3. Convex versus non-convex polytopes

To determine whether a point is inside a polyhedron, compute the distance of that point to each face plane of the polyhedron. If all distances are negative, the point lies inside the polyhedron.

As Figure 4 depicts, computing the distance between a stationary point (or sphere) and the planes of a polytope does not always give an unambiguous measure of distance or penetration depth. Sometimes, the best measure of distance could be from an edge or vertex of the polytope. But the distance formula will always correctly tell whether a point (or sphere) is inside, outside, or overlapping a polytope.

Alternative Method

The point-to-plane method suffices when detecting collisions between particles and polytopes. Other algorithms exist to compute the distance between two convex shapes. One of the most famous and useful, especially among game developers, is the Gilbert–Johnson–Keerthi (GJK) distance algorithm. Although its code is fast and simple, the concepts are not easy to explain and are not in the scope of this article. Furthermore, determining penetration depth can be even more problematic and usually entails more sophisticated approaches, such as the Expanding Polytope Algorithm (EPA). See the "For Further Study" section at the end of this article for more information.

Collision Detection

Detecting a collision between objects entails computing their separation distance or penetration depth. Also, when objects collide, you usually want to know the region of contact and contact normals—that is, the direction along which to apply force or displacement to separate the objects.

Although the point-to-plane distance formula will tell you whether a point lies inside a polytope, it will not unambiguously tell you its distance or penetration depth. In addition to the edge cases described earlier, determining penetration depth entails the relative direction of travel of the two objects. The correct answer depends on the configuration of objects before and after the collision. If objects lie inside each other (or if a particle lies inside a polytope), then you have detected the collision after it occurred. This is called interpenetration, and it should be avoided or corrected when it happens.

For visual effects involving hundreds or thousands of tiny particles, you can get adequate results by using the following simple algorithm:

1. Given a query point, a polytope, its position and orientation, initialize largestDistance to an extremely large negative value.
2. For each plane in the polytope:
   1. Compute the distance between the query point and the plane.
   2. If that distance exceeds largestDistance, then:
      1. Assign largestDistance to that distance
      2. Remember this plane index
3. Return the plane index and largestDistance.

For spheres, subtract their radius from the returned largest distance to get the separation distance. If that value is negative, the sphere interpenetrates the polytope.

From that information, you can compute a contact point and normal:

Given a query point, a plane, a polytope orientation, and the largest distance:

1. Reorient the plane normal to world space.
2. Scale the normal for the returned plane index by the largest distance to get a penetration vector.
3. Subtract the penetration vector from the query point to get the contact point.

Although this algorithm does not accurately measure distance for the edge cases, the distance and normal it returns yield sufficiently close results to work for collision response.

The ConvexPolytope class implements these algorithms. (See the demonstration code that accompanies these articles for more details.)

The routine ContactPoint uses information computed by ContactDistance:

Broad Phase

The ContactDistance algorithm iterates over every face in a polyhedron. That process can get expensive. You can reduce that expense in a few ways:

• Only compute ContactDistance when the query point lies within a coarse bounding volume (such as a bounding sphere) that contains the polytope. That computation is much faster and can let you skip the more expensive ContactDistance until the query point is somewhat near the polytope. The accompanying code uses this technique.
• If you only care about interpenetration, you can change ContactDistance to return immediately when it finds any distance-to-plane that is positive. The returned value will not necessarily be the largest distance, but when positive, you don’t care. Note that if you want to compute the distance to a sphere instead of to a point, then you would have to pass in the sphere radius and take that into account. The accompanying code includes a routine that uses this technique.

To further reduce CPU cost , but at the expense of memory and complexity you can:

• Remember the plane from the previous iteration, and reuse that for the next attempt. If it’s still positive, there is no collision, and you can bail out after testing one plane. Note that this would entail storing another integer per particle. Because there can be tens of thousands of particles, that can add up.
• Store face connectivity information and only visit adjacent faces whose distance would increase largestDistance. Doing so can significantly reduce the number of faces visited. Also, game engines often include such adjacency information. You might be able to exploit that information for particle collisions.

Deepening Penetration

If a particle penetrates an object, it could end up closer to the opposite side of the object rather than the side it penetrated, as Figure 5 shows. This could happen for thin objects or fast particles. It is therefore useful to consider only those planes for which particles are moving farther behind.

Figure 5. Measuring collision depth between a moving spherical particle and polytope

The demo code accompanying this article contains a routine, ConvexPolytope::CollisionDistance, that implements this idea.

Continuous Collision Detection

The most accurate way to determine contacts would entail continuous collision detection (CCD)—that is, detecting the collision just as it happens (instead of after the fact). CCD involves computing a time of impact (TOI) and either advancing the simulation up to that point or rewinding back to it. One way to approximate CCD to estimate TOI is to move into a reference frame where only the object moves. The other object will still be in motion. Now, sweep that moving object across space to span the region it would occupy at all points during the test interval. If the swept shape intersects with the stationary shape, the two objects probably collided during that interval.

Sweeping a shape is relatively easy if its motion is pure translation but more difficult if its motion includes rotation. Video games therefore either treat only linear motion for continuous collision detection or simply use discrete collision detection and allow objects to interpenetrate.

For spherical shapes, like particles, the swept shape is a line segment with hemispherical caps, also known as a capsule or sausage. You can compute intersections between capsules and planes using simple formulae. But particle effects for video games do not need that level of sophistication, and it takes longer to compute than most games budget for effects.

Concave Shapes

The technique described in this article applies directly to convex shapes. To apply to concave shapes, you can either compute the convex hull of that shape or decompose the shape into convex components. See the "For Further Study" section for more information.

Collision Response

When the detection phase indicates that a particle interpenetrated an obstacle, the simulation must resolve the collision. In other words, it must push the particle outside the obstacle and adjust the fluid flow to satisfy boundary conditions.

Part 1, part 2, and part 4 explain boundary conditions and one way to solve them approximately, so I will not repeat that here. This article only describes changes that facilitate particles interacting with convex polyhedra.

Simplified Vorton Interaction with Planes

The routine SolveBoundaryConditions iterates through each rigid body and collides vortons and tracers with that body by calling CollideVortonsSlice and CollideTracersSlice. As of this article, ColideVortonsSlice is a new routine, extracted from SolveBoundaryConditions from previous articles.

The code snippet below focuses on changes made to facilitate colliding with convex polytopes. Code in purple bold is new.

Notice that this code first checks whether the particle lies within a bounding sphere, regardless of whether the obstacle is a sphere or polytope. That is a broad-phase collision test.

The routines CollideTracersSlice and RemoveEmbeddedParticles have similar changes. See the demonstration code accompanying this article for details.

Parallelization

The routine CollideVortonsSlice was extracted from SolveBoundaryConditions to facilitate parallelizing it with Intel® Threading Building Blocks (Intel® TBB). In addition to extracting that code into its own routine, other changes were made. Previously, the corresponding code directly applied changes to the rigid body’s temperature and momentum. The old code performed operations like this:

1. Read body temperature.
2. Compute heat exchange based on body temperature.
3. Write new body temperature.

But when run in parallel, such updates cause a race condition, as shown in Table 1.

Table 1. Parallel threads cause a race condition.

Both threads update a value at the same address (temperature, in this example). Only one thread can "win."

You could solve this issue by synchronizing the code with mutex locks on the body temperature. But doing so would serialize that critical section of code, which would in turn defeat the purpose of parallelizing it.

Instead, have each thread accumulate changes in a variable local to each thread. When the thread terminates, have the parent thread accumulate those changes and apply them to the body. This might seem to be a perfect use case for Intel TBB’s parallel_reduce operation.

There is one more catch, however: That accumulation operation is not associative. (See Part 12 for details of a similar problem.) Even though addition is associative for real numbers, it is not for floating-point numbers. To ensure that this parallelized routine is deterministic, you have to spawn and join threads manually, because Intel TBB’s parallel_reduce does not split and join deterministically. Instead, use Intel TBB’s parallel_invoke and manually spawn and join threads.

Create a functor to run CollideVortonsReduce with Intel TBB’s parallel_invoke:

For comparison, the demonstration code accompanying this article also includes code for using Intel TBB’s parallel_reduce. It works—in the sense that it generates a usable result—but it is not deterministic, so using it would impede diagnosing issues.

Results

Let’s replace some of the spheres in previous articles with polytopes.

Although the demonstration code uses boxes, the algorithms and data structures support any convex polytope, as depicted later in Figure 8.

Scenarios

Figure 6 shows a flat plate interacting with flames and smoke. Notice that particles move around the plate, and the plate causes vortices to shed from it.

Figure 6. Various views of a plate above flames

Figure 7 shows a flat plate moving horizontally through fluid, leaving a wake with vortices. The code accompanying this article also includes demonstrations with the obstacle rotating about longitudinal and lateral axes, exhibiting the Magnus (curve ball) effect.

Figure 7. Flat plate moving through fluid

Figure 8 shows a polyhedral airfoil moving horizontally through fluid, leaving a wake with vortices. This demonstrates that the technique applies to shapes other than boxes and spheres.

Figure 8. Airfoil moving through fluid. This comes from Gourlay (2010), which used a similar formulation to that presented in this article.

Performance

Table 2 shows how the collision-detection and response routines perform for the scenario with flames and smoke passing by the flat plate. This scenario had, on average, 49,000 tracer particles and 981 vortex particles (per frame), two spheres, and one box. Tracers hit bodies 8876 times per frame, and vortons hit bodies 63 times per frame. The benchmark ran 6000 frames for each run. The processor was a four-core (eight hardware threads with hyperthreading) Intel® Core™ i7-2600 running at 3.4 GHz.

Table 2. Collision-detection and response routines for the smoke and flame scenario

Figure 9 shows a plot of the data in the table.

Figure 9. Run times for the benchmark scenario

Lift

Nonrotating spheres do not generate lift. But lift occurs on asymmetric shapes like flat plates and airfoils.

The algorithm to solve boundary conditions generates lift-like impulses. A flat plate moving horizontally through the fluid at an appropriate angle of attack should encounter lift pushing the plate upward. And indeed, this simulation generates a qualitatively similar result—but it’s from deflecting particles that bounce off the obstacle with partially elastic collisions. In contrast, simulations used in science and engineering calculate the pressure the fluid exerts on bodies, and that calculation can include lift. This simulation does not calculate pressure.

Furthermore, the collision response algorithm does not generate new vortons; it only reassigns values for existing vortons in contact with the object. To be more physically accurate, objects should generate new vortons when necessary. For example, vorticity would be generated on the leeward side of the airfoil, and this would generate a low-pressure region behind and above the airfoil, the vertical component of which would be lift. See the "For Further Study" section for more information about more physically accurate ways to calculate realistic pressure and aerodynamic forces on objects immersed in a fluid.

Summary

Using a simple point-to-plane distance formula, you can make fluid effects interact with obstacles that have shapes commonly used to create models in a video game. The algorithm is easy to parallelize using Intel TBB and runs in less than a millisecond for tens of thousands of particles.

Future Articles

Liquids take the shape of their containers on all but one surface, so modeling liquids also implies modeling containers. Future articles will include extending boundary conditions to include interiors, which will allow for creating containers. That will pave the way for a discussion of free surface tracking and surface tension—properties of liquids.

For Further Study

• Casey Muratori posted a video (https://mollyrocket.com/849) that explains the GJK algorithm using straightforward geometry.
• Lien and Amato ("Approximate Convex Decomposition of Polyhedra," 2006) describe an algorithm to decompose a concave model into nearly convex shapes. Lien’s Ph.D. dissertation (http://cs.gmu.edu/~jmlien/masc/uploads/Main/lien-dissertation.pdf) contains pseudo-code for their algorithms and a comprehensive bibliography on the subject. Also see their technical report (http://cs.gmu.edu/~jmlien/masc/uploads/Main/cd3d_TR_2006.pdf).
• The Wikipedia article on Convex Hull Algorithms (http://en.wikipedia.org/wiki/Convex_hull_algorithms) describes algorithms to obtain the convex hull of a set of points, such as the vertices of a model.
• In chapter 6 of Vortex Methods: Theory and Practice, Cottet and Koumoutsakos describe a vorticity creation algorithm to satisfy boundary conditions. In contrast to the algorithm presented here and in part 4, their algorithm takes into account the entire body at once instead of only a single point at a time.
• I presented a formulation similar to the one described in this article in "Fluid-body simulation using vortex particle operations," an animation poster session at the International Conference on Computer Graphics and Interactive Techniques (SIGGRAPH), Los Angeles in 2010.

About the Author

Dr. Michael J. Gourlay works as a senior software engineer on interactive entertainment. He previously worked at Electronic Arts Inc. (EA Sports) as the software architect for the Football Sports Business Unit, as a senior lead engineer on Madden* NFL, on character physics and the procedural animation system used by EA on Mixed Martial Arts, and as a lead programmer on NASCAR*. He wrote the visual effects system used in EA games worldwide and patented algorithms for interactive, high-bandwidth online applications. He also developed curricula for and taught at the University of Central Florida, Florida Interactive Entertainment Academy, an interdisciplinary graduate program that teaches programmers, producers, and artists how to make video games and training simulations. Prior to joining EA, he performed scientific research using computational fluid dynamics and the world’s largest massively parallel supercomputers. His previous research also includes nonlinear dynamics in quantum mechanical systems and atomic, molecular, and optical physics. Michael received his degrees in physics and philosophy from Georgia Tech and the University of Colorado Boulder.

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

Summary

What is Device Fission?

Why Use Device Fission?

• Device fission allows the use of a portion of a device. This is useful when there is other non-OpenCL work on the device that needs resources. It can guarantee the entire device is not taken by the OpenCL runtime.
• Device fission can allow specialized sharing among work-items such as sharing an L3 cache or sharing a NUMA node.
• Device fission can allow a set of sub-devices to be created, each with its own command queue. This lets the host processor control these queues and dispatch work to the sub-devices as needed.
• Device fission allows specific sub-devices to be used to take advantage of data locality.

How to Use Device Fission in OpenCL* 1.2

• Equally – Partition the device into as many sub-devices as can be created, each containing a given number of computational units.
• By Counts – Partition the device based on a given number of computational units in each sub-device. A list of the desired number of compute units per sub-device can be provided.
• By Affinity Domain – Partition the device based on the affinity of the compute units to share the same level of cache hierarchy or to share a NUMA node. Sub-devices can be created from compute units that share the same:
  • NUMA node
  • L4 Cache
  • L3 Cache
  • L2 Cache
  • L1 Cache
  • Next partitionable affinity domain

cl_int clCreateSubDevices (
	cl_device_id in_device,
	const cl_device_partition_property *properties,
	cl_uint num_devices,
	cl_device_id *out_devices,
	cl_uint *num_devices_ret)

• in_device: The id of the device to be partitioned.
• properties: List of properties to specify how the device is to be partitioned. This is discussed below in more detail.
• num_devices: Number of sub-devices (used to size the memory for out_devices).
• out_devices: Buffer for the sub-devices created.
• num_devices_ret: Returns the number of sub-devices that device may be partitioned into according to the partitioning scheme specified in properties. If num_devices_ret is NULL, it is ignored.

• CL_DEVICE_PARTITION_EQUALLY
• CL_DEVICE_PARTITION_BY_COUNTS
• CL_DEVICE_PARTITION_BY_AFFINITY_DOMAIN

• CL_DEVICE_PARTITION_EQUALLY is followed by N, the number of compute units for each sub-device. The device is partitioned into as many sub-devices as can be created that have N compute units in each sub-device.
• CL_DEVICE_PARTITION_BY_COUNTS is followed by a list of compute unit counts. For each number in the list, a sub-device is created with that many compute units. The list of compute unit counts is terminated by CL_DEVICE_PARTITION_BY_COUNTS_LIST_END.
• CL_DEVICE_PARTITION_BY_AFFINITY_DOMAIN is followed by the type of partitioning for the affinity, either NUMA, L4_CACHE, L3_CACHE, L2_CACHE, L1_CACHE, or Next Partitionable:
  • CL_DEVICE_AFFINITY_DOMAIN_NUMA
  • CL_DEVICE_AFFINITY_DOMAIN_L4_CACHE
  • CL_DEVICE_AFFINITY_DOMAIN_L3_CACHE
  • CL_DEVICE_AFFINITY_DOMAIN_L2_CACHE
  • CL_DEVICE_AFFINITY_DOMAIN_L1_CACHE
  • CL_DEVICE_AFFINITY_DOMAIN_NEXT_PARTITIONABLE

Contexts for Sub-devices

Programs for Sub-devices

Partitioning a Sub-device

Query a Sub-device

• CL_DEVICE_PARTITION_MAX_SUB_DEVICES: Maximum number of sub-devices that can be created for this device.
• CL_DEVICE_PARTITION_PROPERTIES: Partition Types that are supported by this device.
• CL_DEVICE_PARTITION_AFFINITY_DOMAIN: List of supported affinity domains for partitioning the device using Partitioning By Affinity Domain.

• CL_DEVICE_PARENT_DEVICE: Parent device for the given sub-device.
• CL_DEVICE_PARTITION_TYPE: Current partition type in use for this sub-device.

• CL_DEVICE_GLOBAL_MEM_CACHE_SIZE
• CL_DEVICE_BUILT_IN_KERNELS
• CL_DEVICE_PARENT_DEVICE
• CL_DEVICE_PARTITION_TYPE
• CL_DEVICE_REFERENCE_COUNT
• CL_DEVICE_MAX_COMPUTE_UNITS
• CL_DEVICE_MAX_SUB_DEVICES

Release and Retain Sub-device

Other Considerations

• New or different cache hierarchy
• NUMA or Non-NUMA platforms
• More or fewer compute units
• Heterogeneous compute nodes
• Hyper-Threading Technology enabled or disabled

Device Fission Code Examples

// Get Device ID from selected platform:

clGetDeviceIDs( platforms[platform], CL_DEVICE_TYPE_CPU, 1, &device_id, &numDevices);

// Create sub-device properties: Equally with 4 compute units each:

cl_device_partition_property props[3];
props[0] = CL_DEVICE_PARTITION_EQUALLY;  // Equally
props[1] = 4;                            // 4 compute units per sub-device
props[2] = 0;                            // End of the property list

cl_device_id subdevice_id[8];
cl_uint num_entries = 8;

// Create the sub-devices:

clCreateSubDevices(device_id, props, num_entries, subdevice_id, &numDevices);

// Create the context:

context = clCreateContext(cprops, 1, subdevice_id, NULL, NULL, &err);

// Get Device ID from selected platform:

clGetDeviceIDs( platforms[platform], CL_DEVICE_TYPE_CPU, 1, &device_id, &numDevices);

// Create two sub-device properties: Partition By Counts

cl_device_partition_property_ props[5];
props[0] = CL_DEVICE_PARTITION_BY_COUNTS; // Equally
props[1] = 2;                             // 2 compute units 
props[2] = 4;                             // 4 compute units 
props[3] = CL_DEVICE_PARTITION_BY_COUNTS_LIST_END; // End Count list
props[4] = 0;                             // End of the property list

cl_device_id subdevice_id[2];
cl_uint num_entries = 2;

// Create the sub-devices:

clCreateSubDevices(device_id, props, num_entries, subdevice_id, &numDevices);

// Create the context:

context = clCreateContext(cprops, 1, subdevice_id, NULL, NULL, &err);

// Get Device ID from selected platform:

clGetDeviceIDs( platforms[platform], CL_DEVICE_TYPE_CPU, 1, &device_id, &numDevices);

// Create sub-device properties: Partition By Affinity Domain - NUMA

cl_device_partition_property props[3];
props[0] = CL_DEVICE_PARTITION_BT_AFFINITY_DOMAIN; // By Affinity
props[1] = CL_DEVICE_AFFINITY_DOMAIN_NUMA;         // NUMA
props[2] = 0;                                      // End of the property list

cl_device_id subdevice_id[8];
cl_uint num_entries = 8;

// Create the sub-devices:

clCreateSubDevices(device_id, pprops, num_entries, subdevice_id, &numDevices);

// Create the context:

context = clCreateContext(cprops, 1, subdevice_id, NULL, NULL, &err);

Strategies for Using Device Fission

Conclusion

APPENDIX: Device Fission in OpenCL 1.1

#include < CL/cl_ext.h >

    cl_int clCreateSubDevicesEXT( 
        cl_device_id in_device,
        const cl_device_partition_property_ext * properties,
        cl_uint num_entries,
        cl_device_id *out_devices,
        cl_uint *num_devices );

Download Article

DirectCompute Applications

• Game physics and artificial intelligence;
• Applying algorithms in image space that require kernels that are more flexible when it comes to the relationship between data used and the threads applied on this data; and
• The many advanced rendering effects that use the Read/Write abilities, such as order-independent transparency, ray tracing, and global illumination effects.

DirectCompute Memory Model

• RWBuffer
• RWTexture1D, RWTexture1DArray
• RWTexture2D, RWTexture2DArray
• RWTexture3D

// Compute Shader code: RWTexture with Unordered Access View in u0
RWTexture2D<float4> output : register (u0);

// Compute Shader code: structured buffer with Unordered Access View in u0
struct BufferStruct
{
  float4 color;
};
RWStructuredBuffer<BufferStruct> output : register(u0);

uint stride = WindowWidth;  

// buffer stride, assumes data stride = 
// data width (i.e. no padding)
// DTid is the SV_DispatchThreadID
uint idx = (DTid.x) + (DTid.y) * stride;
output[idx].color = color;  

// 
// structured buffer
//
struct BufferStruct
{
  float color[4];
};

D3D11_BUFFER_DESC sbDesc;
sbDesc.BindFlags = D3D11_BIND_UNORDERED_ACCESS | D3D11_BIND_SHADER_RESOURCE;
sbDesc.CPUAccessFlags = 0;
sbDesc.MiscFlags = D3D11_RESOURCE_MISC_BUFFER_STRUCTURED; sbDesc.StructureByteStride = sizeof(BufferStruct);

int Height = WindowHeight; 
int Width = WindowWidth;
sbDesc.ByteWidth = sbDesc.StructureByteStride * Width * Height; sbDesc.Usage = D3D11_USAGE_DEFAULT;
pd3dDevice->CreateBuffer(&sbDesc, NULL, &pStructuredBuffer);

ByteAddressBuffer
RWByteAddressBuffer

// Create constant buffer
typedef struct
{
	float diffuse[4]; // diffuse shading color
	float mu[4];    // quaternion julia parameter
	float epsilon;  // detail julia
	int c_width;      // view port size
	int c_height;
	int selfShadow;  // selfshadowing on or off 
	float orientation[4*4]; // rotation matrix
	float zoom;
} QJulia4DConstants;

D3D11_BUFFER_DESC Desc;
    	Desc.Usage = D3D11_USAGE_DYNAMIC;
    	Desc.BindFlags = D3D11_BIND_CONSTANT_BUFFER;
    	Desc.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE;
    	Desc.MiscFlags = 0;

    	// must be multiple of 16 bytes
Desc.ByteWidth = ((sizeof( QJulia4DConstants ) + 15)/16)*16;  
pd3dDevice->CreateBuffer(&Desc, NULL, &pcbFractal);

// 
// shader resource view on structured buffer
//
D3D11_SHADER_RESOURCE_VIEW_DESC sbSRVDesc;
ZeroMemory( &sbSRVDesc, sizeof( sbSRVDesc ) ); sbSRVDesc.Buffer.ElementOffset = 0;
sbSRVDesc.Buffer.ElementWidth = sbDesc.StructureByteStride; sbSRVDesc.Buffer.FirstElement = sbUAVDesc.Buffer.FirstElement; sbSRVDesc.Buffer.NumElements = sbUAVDesc.Buffer.NumElements; sbSRVDesc.Format = DXGI_FORMAT_UNKNOWN;
sbSRVDesc.ViewDimension = D3D11_SRV_DIMENSION_BUFFER;
hr = pd3dDevice->CreateShaderResourceView((ID3D11Resource *) pStructuredBuffer, &sbSRVDesc, &pComputeShaderSRV);

// Unordered access view on structured buffer
D3D11_UNORDERED_ACCESS_VIEW_DESC sbUAVDesc;
ZeroMemory( &sbUAVDesc, sizeof(sbUAVDesc) ); sbUAVDesc.Buffer.FirstElement = 0;
sbUAVDesc.Buffer.Flags = 0;
sbUAVDesc.Buffer.NumElements = sbDesc.ByteWidth / sbDesc.StructureByteStride; 
sbUAVDesc.Format = DXGI_FORMAT_UNKNOWN;
sbUAVDesc.ViewDimension = D3D11_UAV_DIMENSION_BUFFER;
HRESULT hr = pd3dDevice>CreateUnorderedAccessView((ID3D11Resource *)pStructuredBuffer, &sbUAVDesc, &pComputeOutputUAV);

// Unordered access view on structured buffer
D3D11_UNORDERED_ACCESS_VIEW_DESC sbUAVDesc;
ZeroMemory( &sbUAVDesc, sizeof(sbUAVDesc) ); sbUAVDesc.Buffer.FirstElement = 0;
sbUAVDesc.Buffer.Flags = D3D11_BUFFER_UAV_FLAG_APPEND;
sbUAVDesc.Buffer.NumElements = sbDesc.ByteWidth / sbDesc.StructureByteStride; 
sbUAVDesc.Format = DXGI_FORMAT_UNKNOWN;
sbUAVDesc.ViewDimension = D3D11_UAV_DIMENSION_BUFFER;
HRESULT hr = pd3dDevice>CreateUnorderedAccessView((ID3D11Resource *)pStructuredBuffer, &sbUAVDesc, &pComputeOutputUAV);

groupshared float sharedmem[256];
 

DirectCompute Threading Model

Dispatch(UINT ThreadGroupCountX, UINT ThreadGroupCountY, UINT ThreadGroupCountX);

DispatchIndirect(ID3D11Buffer *pBufferForArgs, UINT AlignedOffsetForArgs);

// C++ application code
pImmediateContext->Dispatch(Width / THREADSX, Height / THREADSY, 1 );

// HLSL compute shader code
[numthreads(THREADSX, THREADSY, 1)]
void CS_QJulia4D( uint3 Gid : SV_GroupID, uint3 DTid : SV_DispatchThreadID, uint3 GTid : SV_GroupThreadID, uint GI : SV_GroupIndex )
...

Thread Addressing System

• vThreadID.xyz
• vThreadGroupID.xyz
• vThreadIDInGroup.xyz
• vThreadIDInGroupFlattended

• SV_DispatchThreadID - index of the thread within the entire dispatch in each dimension: x - 0..x - 1; y - 0..y - 1; z - 0..z - 1
• SV_GroupID - index of a thread group in the dispatch — for example, calling Dispatch(2,1,1) results in possible values of 0,0,0 and 1,0,0, varying from 0 to (numthreadsX * numthreadsY * numThreadsZ) – 1
• SV_GroupThreadID - 3D version of SV_GroupIndex - if you specified numthreads(3,2,1), possible values for the SV_GroupThreadID input value have the range of values (0–2,0–1,0)
• SV_GroupIndex - index of a thread within a thread group

RWTexture2D<float4> output : register (u0); 
void CS_QJulia4D( uint3 Gid : SV_GroupID, uint3 DTid : SV_DispatchThreadID, uint3 GTid : SV_GroupThreadID, uint GI : SV_GroupIndex )
{
...
	output[DTid.xy] = color;
}

struct BufferStruct
{
	float4 color;
};
RWStructuredBuffer&;lt;BufferStruct> output : register (u0); // UAV 0 
void CS_QJulia4D( uint3 Gid : SV_GroupID, uint3 DTid : SV_DispatchThreadID, uint3 GTid : SV_GroupThreadID, uint GI : SV_GroupIndex )
{
...
	uint stride = c_width;  
	uint idx = (DTid.x) + (DTid.y) * stride;

	output[idx].color = color;  
}
 

Thread Synchronization

• AllMemoryBarrier/*WithGroupSync
• DeviceMemoryBarrier/*WithGroupSync
• GroupMemoryBarrier/*WithGroupSync

for (uint tile = 0; tile < numTiles; tile++) 
{
    sharedPos[threadId] = particles[…];
       
    GroupMemoryBarrierWithGroupSync();

    // gravitation() uses sharedPos[] as input data
    acceleration = gravitation(…);
        
    GroupMemoryBarrierWithGroupSync();
}

• InterlockedAdd
• InterlockedMin
• InterlockedMax
• InterlockedOr
• InterlockedAnd
• InterlockedXor
• InterlockedCompareStore
• InterlockedCompareExchange
• InterlockedExchange

Example

   //
   // Initialize Direct3D device and swap chain
   //	
   DXGI_SWAP_CHAIN_DESC sd;
// …
   // this qualifies the back buffer for being the target of compute shader writes 
   sd.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT | DXGI_USAGE_UNORDERED_ACCESS | DXGI_USAGE_SHADER_INPUT;
// …
   
   // return value -> what the hardware supports
   D3D_FEATURE_LEVEL MaxFeatureLevel = D3D_FEATURE_LEVEL_11_0; 
   
   // we are asking for DirectX 11 feature level support here
   D3D_FEATURE_LEVEL FeatureLevel = D3D_FEATURE_LEVEL_11_0;

   HRESULT hr = D3D11CreateDeviceAndSwapChain(
							   NULL,
							   D3D_DRIVER_TYPE_HARDWARE,
							   NULL, 
							   D3D11_CREATE_DEVICE_DEBUG,
							   &FeatureLevel,
							   1,
							   D3D11_SDK_VERSION,
							   &sd,
							   &pSwapChain,
							   &pd3dDevice,
							   &MaxFeatureLevel,
							   &pImmediateContext);

DXGI_SWAP_CHAIN_DESC sdtemp;
pSwapChain->GetDesc(&sdtemp);

// get access to the back buffer via a texture
ID3D11Texture2D* pTexture;
pSwapChain->GetBuffer(0, __uuidof( ID3D11Texture2D ), ( LPVOID* )&pTexture );

// create shader unordered access view on back buffer for compute shader to write into texture
pd3dDevice->CreateUnorderedAccessView(pTexture, NULL, &pComputeOutput );

//
// Create constant buffer
//
D3D11_BUFFER_DESC Desc;
Desc.Usage = D3D11_USAGE_DYNAMIC;
Desc.BindFlags = D3D11_BIND_CONSTANT_BUFFER;
Desc.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE;
Desc.MiscFlags = 0;
Desc.ByteWidth = ((sizeof( MandelbrotConstants ) + 15)/16)*16; // must be multiple of 16 bytes

pd3dDevice->CreateBuffer(&Desc, NULL, &pcbFractal);		

// Fill constant buffer
D3D11_MAPPED_SUBRESOURCE msr;
pImmediateContext->Map(pcbFractal, 0, D3D11_MAP_WRITE_DISCARD, 0,  &msr);
 *(MandelbrotConstants *)msr.pData = MandelC;
pImmediateContext->Unmap(pcbFractal,0);
 

//
// compile the compute shader
//
if(D3DX11CompileFromFile(L"Mandelbrot.hlsl", NULL, NULL, "Mandelbrot", "cs_5_0", 0, 
				0, NULL, &pByteCodeBlob, &pErrorBlob, NULL)!= S_OK)
  MessageBoxA(NULL, (char *)pErrorBlob->GetBufferPointer(), "Error", MB_OK | MB_ICONERROR);
if(pd3dDevice->CreateComputeShader(pByteCodeBlob->GetBufferPointer(), 
			pByteCodeBlob->GetBufferSize(), NULL, &pCompiledComputeShader)!= S_OK)
  MessageBoxA(NULL, "CreateComputerShader() failed", "Error", MB_OK | MB_ICONERROR);

// Set compute shader
pImmediateContext->CSSetShader(pCompiledComputeShader, NULL, 0 );
 		
// UAV for CS output into back-buffer
pImmediateContext->CSSetUnorderedAccessViews(0, 1, &pComputeOutput, NULL);
		
// CS constant buffer
pImmediateContext->CSSetConstantBuffers(0, 1, &pcbFractal );

// Run the CS
pImmediateContext->Dispatch((gWidth) / 16, (gHeight) / 16, 1 );

// make it visible
pSwapChain->Present( 0, 0 );

[numthreads(16, 16, 1)]
void Mandelbrot( uint3 Gid : SV_GroupID, uint3 DTid : SV_DispatchThreadID, uint3 GTid : SV_GroupThreadID, uint GI : SV_GroupIndex )
{
…
        output[ DTid.xy ] = color;
}

Summary

References

• Wikipedia on the Mandelbrot set, http://en.wikipedia.org/wiki/Mandelbrot_set
• Registers used in cs_5_0 http://msdn.microsoft.com/en-us/library/hh447206(v=VS.85).aspx
• Jan Vlietinck, http://users.skynet.be/fquake
• Jason Zink, Matt Pettineo, Jack Hoxley, “Practical Rendering & Computing with Direct3D 11,” CRC Press, 2011; p. 305.

Introduction

Texture Compositing Overview

Figure 1 - Texture Splatting - In this example, a blend map is used to blend together 4 textures with a 5th being used as a base texture. The red square simply denotes that only a portion of the blend map is used to generate the composited texture.

What to Composite

Figure 2 - The nine tiles surrounding the camera (C) are composited. If the camera moves to a new tile, composited textures for the out of bounds tiles are marked for deletion (D) while textures for newly in-range tiles are marked for compositing (N).

Details

Figure 3 - In this example both the source (left) and destination (right) texture resolutions are the same. Tiling the source texture twice in the horizontal direction does not produce the desired results. By tiling twice, the step size becomes two and every other texel is skipped and the information is lost.

Performance

Figure 4 - Sample with highlighting enabled. Red areas are pre-composited on the CPU while green areas are composited on the GPU.

Table 1 - Frame times in ms for CPU compositing and GPU compositing at 1366x768 resolution. The number of textures decreases by removing pairs of diffuse and normal map textures from the GPU compositing shader. The CPU composited shader remains unchanged at three texture reads.

Table 2 - Selected GPU metrics from Intel Graphics Performance Analyzer for rendering the tile closest to the camera. The main discrepancy between the two methods is in bandwidth used for all the texture reads and the total time required to render the terrain tile.

Conclusion

Thanks

References

Download Article

• Bookkeeping to manage new objects and inter-object references.
• Main computation kernel that processes and computes independent object data.
• Post-processing on object data that have dependencies.

• Bookkeeping to keep track of the objects and allow node objects to reference each other if needed
• I moved data dependency into the post processing step so that the computation kernel can run independently in parallel.
• Thread local storage is used for non-thread-safe data to avoid race conditions.

Abstract

1. Introduction

2. Intel SIMD Overview

3. Video Processing Code

3.1. Desaturation - Sample Code

3.2. Desaturation - Optimization with AVX

• AVX provides greater throughput for parallel processing of single-precision floating- point units than any past Intel SIMD x86 extension (MMX, SSE, SSE2, SSE3, SSE4.1, SSE4.2).
• The cost (SIMD) to cast byte (8-bit unsigned char) to integer (32-bit signed integer) to single precision floating point (32-bit float) and back is less than using multiple calls of the equivalent code (scalar) using just bytes or integers.
• Using byte based SIMD with this procedure gives poor precision. Parallel performance is not considered.
• Using integer based SIMD with this procedure gives acceptable precision. Current AVX instructions for integer arithmetic do not exist and therefore cannot take full advantage of the 256-bit registers.
• Using float based SIMD with this procedure gives very good precision and offers higher performance than those described above.

3.3 Desaturation - Performance Test Results³

4. Packed Integer Conversion Instructions

5. Conclusion

About the Authors

Appendix A: Inner loop quivalent assembly of the serial code

Appendix B: Equivalent assembly of inner loop optimized with AVX

Download Article

Introduction

Historical Perspective

Benefits of Veo* Technology

MBIR Algorithm Challenges

• Algorithm optimization resulting from joint research of GE engineers and academic research partners
• Intel® processor microarchitecture improvements made over several years
• A very dense, high performance IBM* Blade Server system
• Algorithms tuned by GE and Intel engineers to increase speed on Intel Xeon processors

MBIR Optimizations

Figure 5. Three Multi-Tasking Examples

Advancing Image Reconstruction

About the Authors

Download Article

Intel® GPA Platform Analyzer Overview

Leading Game Middleware Instrumented for Intel® GPA Platform Analyzer

Simple and flexible instrumentation API

Create or Integrate into Instrumentation System

1. Begin/End markers: Delimit specific code sections with begin/end calls.
2. Scoped objects: Macros called at the beginning of the profiled code section create an instrumentation object that goes out of scope at the end of the code section.

#include <ittnotify.h>

class GPAScopedTask
{
  public:
  GPAScopedTask( __itt_domain* pDomain, const char* szTaskName )
  : m_pDomain( pDomain )
  { 
    __itt_string_handle* pTaskName = __itt_string_handle_createA( szTaskName );
    __itt_task_begin( m_pDomain, __itt_null, __itt_null, pTaskName ); 
  }
  ~GPAScopedTask( void ) 
  { 
    __itt_task_end( m_pDomain ); 
  }
  
  private:
  __itt_domain* m_pDomain;
}

#define GPA_TASK( Domain, TaskName ) \
  GPAScopedTask _gpa_scoped_task_( Domain, TaskName )
#define GPA_TASK_BEGIN( TaskName ) \
  __itt_task_begin( Domain, __itt_null, __itt_null, TaskName )
#define GPA_TASK_END( Domain ) __itt_task_end( Domain )
 

Organize Your Instrumentation

The rest (and then some) of the instrumentation API

• __itt_relation_is_dependent_on
• __itt_relation_is_sibling_of
• __itt_relation_is_parent_of
• __itt_relation_is_continuation_of
• __itt_relation_is_child_of
• __itt_relation_is_continued_by
• __itt_relation_is_predecessor_to

Appendix A : Intel® GPA Monitor

1. Running applications from Intel GPA Monitor
2. Enabling Hardware Context Data
3. Viewing and enabling domains

About the Author