My use of FXAA and anisotropic filtering was just making the problem more evident. I would recommend using regular trilinear filtering for derivative maps anyway.

So, mea culpa and all that. Let the name of Morten Mikkelsen and derivative maps be cleared!

I’ll be using the precomputed derivative maps for comparison since the ddx/ddy technique just isn’t acceptable in terms of quality.

Quality

Here’s the close up shot of the sphere with the moon texture again. This shows the derivative map implementation, and if you mouse over, you’ll see the normal map version.

There are some slight differences because the height of the derivative map doesn’t quite match the heights used to precompute the normal map, but overall I would say that they are remarkably similar. It looks to me that the normal map is preserving more of the detail though.

Here’s a high-contrast checkerboard, again with the normal map shown if you mouse over.

I’m no artist, but I would say the the derivative map results are close enough to the normal maps to call the technique viable from a quality standpoint.

Performance

I ran these tests on my Macbook Pro which has an AMD 6750M. The shader in question is a simple shader for filling out the gbuffer render targets. All shaders were compiled using shader model 5. I took the frame times from the Fraps frame counter and the other numbers came from Gpu Perf Studio.

For comparison, I’ve included an implementation with no normal perturbation at all.

Despite the extra shader instructions, the derivative map method is basically as fast as normal maps on my hardware. As Mikkelsen predicted, it seems like having one fewer vertex attribute interpolator offsets the cost of the extra ALU instructions.

Note that the derivative map shader has nine texture instructions compared to just four for the normal maps. The extra five instructions are the two sets of ddx/ddy instructions, and the instruction to get the texture dimensions. The pixel shader can issue one texture instruction and one ALU instruction on the same cycle, these are essentially free.

The only performance overhead which has any impact for derivative maps are the five extra ALU instructions.

Memory

As I mentioned in my previous post, derivative maps also have the tremendous benefit of not requiring tangent vectors. In my case, with a simple vertex containing position, normal, tangent and one set of texcoords, the tangent takes up 27% of the mesh space.

Given that most games these days have tens of megabytes of mesh data, this would turn into some pretty decent memory savings. There’s also a minor benefit on the tool-side to not having to spend time generating face tangents and merging them into the vertices.

Conclusion

Well, for me it’s pretty clear. On my setup, derivative maps have a similar quality with the same performance but less memory. This makes them a win in my book. Of course, these numbers will vary wildly based on the API and hardware, so this can’t be taken as a blanket ‘derivative maps are better than normal maps’ statement, but they look promising. Good job Morten Mikkelsen!

I would love to see a similar comparison for the current generation of console hardware (hint, hint!).

If you have DirectX 11, then you should be able to run the demo here.

I was reading through the AMD CubeMapGen source last week and came across the code for calculating the solid angle of a cube map texel. This code piqued my interest, since it seemed very terse for what I thought would be a horrific calculation.

static float32 AreaElement( float32 x, float32 y )
{
	return atan2(x * y, sqrt(x * x + y * y + 1));
}

float32 TexelCoordSolidAngle(int32 a_FaceIdx, float32 a_U, float32 a_V, int32 a_Size)
{
   //scale up to [-1, 1] range (inclusive), offset by 0.5 to point to texel center.
   float32 U = (2.0f * ((float32)a_U + 0.5f) / (float32)a_Size ) - 1.0f;
   float32 V = (2.0f * ((float32)a_V + 0.5f) / (float32)a_Size ) - 1.0f;

   float32 InvResolution = 1.0f / a_Size;

	// U and V are the -1..1 texture coordinate on the current face.
	// Get projected area for this texel
	float32 x0 = U - InvResolution;
	float32 y0 = V - InvResolution;
	float32 x1 = U + InvResolution;
	float32 y1 = V + InvResolution;
	float32 SolidAngle = AreaElement(x0, y0) - AreaElement(x0, y1) - AreaElement(x1, y0) + AreaElement(x1, y1);

	return SolidAngle;
}

The source code for this particular part is well documented, and points you towards this thesis by Manne Öhrström (@manneohrstrom) where he gives a high level overview of the derivation. I was interested in finding out some more of the details, so I had a go myself, and this post is the result.

Why is it Useful?

When processing cube maps (for example, generating a diffuse irradiance map, or spherical harmonic approximation), you need to be able to integrate the texel values over a sphere.

One way of approximating this integral is to use a Monte Carlo estimator. This is a statistical technique that may oversample some texels and undersample other. This seems a bit wasteful considering that we have a finite number of input values. Ideally we’d like to use each texel value just once.

A naive approach to analytical integration where each texel has the same weight would result in overly bright values in the corner areas. This is because the texels in the corners project to smaller and smaller areas on the sphere. The correct approach is to factor in the solid angle during the integral, and this is what CubeMapGen does.

The Plan

Imagine a single cube map face placed at (0,0,1) and scaled such that the texel locations are all in [-1,1]. For any texel in this cube map, we want to project it onto a unit sphere sitting at the origin, then work out the area on the sphere. This area corresponds to the solid angle because the sphere is a unit sphere.

We can repeat this same calculation for any of the other cube map faces by first transforming them into the same range.

This is the high-level game plan for calculating out the solid angle:

1. Determine a formula for projecting a position from texture-space onto the sphere.
2. Work out how this projected position changes as the texture-space coordinates change in x and y.
3. Imagining that these position change vectors define two sides of a microscopic quadrilateral, then calculate the microscopic area of this quad using the magnitude of the cross product.
4. Integrate the microscopic area using the corner coordinates of a texel to calculate its area on the sphere, and solid angle.

The Details

We start off with the formula for projecting a point from its location on the texture face (x, y, 1) onto the unit sphere. This is just a standard vector normalization.

Note: I’ll be switching back and forth between negative and fractional exponents as I see fit. This makes things easier. Remember, , and .

We want to calculate how this projected point changes as the texture-space x and y coordinates change. We can do this separately for each axis using partial derivatives. First we’ll start by calculating how the projected z component changes along to the texture-space x axis.

Projected Z Change According to X

The z-component of p is simply:

We need to differentiate this equation with respect to x. Because of the exponent, we need to use the chain rule to do this. The chain rule is a method for finding the derivative of the composition of two functions. First, we can reformulate the equation a little bit to make the two functions a bit clearer:

In our case our first function is a function of and our second function is a function of and . Given this, the chain rule says:

We can apply this rule very easily to our reformulated functions:

This equation tells us exactly how the z component of the projected point changes as the texture-space position moves along the x axis.

Projected X Change According to X

Now we’ve found the projected z component derivative, it’s going to make finding the x and y components a little easier. Why? Because we can express the x and y components in terms of the z component.

We don’t have the same ‘composition of functions’ setup that we did last time, so we can’t use the chain rule to differentiate this. Instead, we can use the product rule. The product rule in our case says:

Applying this to equation for for the projected x component:

Projected Y Change According to X

We have a very similar derivation for the projected y derivative:

We can use the product rule again:

Projected Position Change According to X and Y

Putting this all together, we have our equation showing how the projected position changes as the texture-space position changes in the x direction. We can use the exact same process to work out how it moves in the y direction.

Differential Area

The next step is to calculate the differential (microscopic) area of the projected point using the partial derivatives we just calculated. Clearly at a normal scale, we wouldn’t be able to take the cross product of two projected vectors on a sphere and expect the magnitude to be the area they define on the sphere. But at this differential scale, we can treat the surface as if it is flat, so this works.

The first thing we need to do is to calculate the cross product of the partial derivatives.

Calculating the cross product for each of the components relatively straightforward.

If you’re reading carefully, you’ll notice that each component has a factor of on the top and the bottom, so we can divide through. Combining all the components back together again, we arrive at the final equation for the perpendicular vector.

Now we simply need to take the length of the result of the cross product to find the differential area on the sphere.

Solid Angle

The final step is to integrate the differential area over our range of texture-space values to get the solid angle of the texel. We can start by calculating the integral between and some point on the cube map face.

From this formula, we can calculate the area of any texel in the cube map face by adding together the two right-diagonal corners, A and C, and subtracting the left-diagonal corners, B and D.

You can see on the image below that the added areas in green are canceled out by the subtracted areas in red.

That should look familiar, since that’s exactly what the CubeMapGen code does. If you look at the surrounding source code to TexelCoordSolidAngle, then you’ll notice that there’s another method mentioned for calculating the solid angle of a texel. This method is based on Girard’s theorem, which describes how to calculate the area of a spherical triangle based on the excess of the sum of its interior angles. This method was also suggested to me on Twitter by Ignacio Castaño (@castano). I haven’t actually tried it, but it looks fascinating!

Is it Correct?

It’s always a bit daunting to get to the end of a derivation like this, and not know if the answer is correct or not. In this case, it’s pretty easy to verify if this result is correct.

Remember that the texture-space coordinates are in range [-1,1]. If we set our values to 1, that corresponds to the top right quarter of the cube map face. We know that there are steradians in a sphere, so that means that each face gets steradians. Since we’re only calculating for a quarter of a face we expect our result to be .

And it does. Thanks to the various people on twitter (@SebLagarde, @mattpharr, @manneohrstrom, @castano and @ChristerEricson) for engaging me in conversation over this.

Please let me know in the comments if you spot an error in this post, or if anything needs to be explained better or more easily.

Mikkelsen is apparently well-versed in academic obfuscation (tsk!), so the paper itself can be a little hard to read. If you’re interested in reading it, then I would recommend first reading Jim Blinn’s original bump mapping paper to understand some of the derivations.

But Wait! What’s Wrong with Normal Maps?

Nothing really. But if something comes along that can improve quality, performance or memory consumption then it’s worth taking a a look.

A Quick Detour into Gradients

Given a scalar height field (i.e. a two-dimensional array of scalar values), the gradient of that field is a 2D vector field where each vector points in the direction of greatest change. The length of the vectors corresponds to the rate of change.

The contour map below represents the scalar field generated from the function . The vector field shows the gradient of that scalar field. Note how each vector points towards the center, and how the vectors in the center are smaller due to the lower rate of change.

Derivative Maps

The main premise of the paper is that we can project the gradient of the height field onto an underlying surface and use it to skew the surface normal to approximate the normal of the height-map surface. We can do all of this without requiring tangent vectors.

As with the original bump-mapping technique, it’s not exact due to some terms being dropped due to their relatively small influence, but it’s close.

There are really only two important formulae to consider from the paper. The first shows how to perturb the surface normal using the surface gradient. Don’t confuse the surface gradient with the gradient of the height field mentioned above! As you’ll see shortly, they’re different.

Here, represents the perturbed normal, is the underlying surface normal, and is the surface gradient. So basically, this says that the perturbed normal is the surface normal offset in the negative surface gradient direction.

So how do we calculate the surface gradient from the height field gradient? Well, there’s some fun math in there which I don’t want to repeat, but if you’re interested, I would recommend reading Blinn’s paper first, then Mikkelsen’s paper. You eventually arrive at:

In addition to the symbols defined previously, and are the partial derivatives of the surface position, and and are the partial derivatives of the height field. The derivative directions and are not explictly defined here.

It’s easiest to think of this as the projection of the 2D gradient onto a 3D surface along the normal. Intuitively, this says that the surface gradient direction is pushed out on orthogonal vectors to the s/n and t/n planes by however much the gradient specifies. The denominator term is there to scale up the result when the and are not orthogonal, or are flipped.

Implementation

Implementing this technique is fairly straightforward once you realise the meaning of some of the variables. Since we’re free to choose the partial derivative directions and , it’s convenient for the shader to use screen-space x and y. The value is the position, and the value is the height field sample.

// Project the surface gradient (dhdx, dhdy) onto the surface (n, dpdx, dpdy)
float3 CalculateSurfaceGradient(float3 n, float3 dpdx, float3 dpdy, float dhdx, float dhdy)
{
	float3 r1 = cross(dpdy, n);
	float3 r2 = cross(n, dpdx);

	return (r1 * dhdx - r2 * dhdy) / dot(dpdx, r1);
}

// Move the normal away from the surface normal in the opposite surface gradient direction
float3 PerturbNormal(float3 n, float3 dpdx, float3 dpdy, float dhdx, float dhdy)
{
	return normalize(normal - CalculateSurfaceGradient(normal, dpdx, dpdy, dhdx, dhdy));
}

So far, so good. Next we need to work out how to calculate the partial derivatives. The reason why we chose screen-space x and y to be our partial derivative directions is so that we can use the ddx and ddy shader instructions to generate the partial derivatives of both the position and the height.

Given a position and normal in the same coordinate-space, and a height map sample, calculating the final normal is straighforward:

// Calculate the surface normal using screen-space partial derivatives of the height field
float3 CalculateSurfaceNormal(float3 position, float3 normal, float height)
{
	float3 dpdx = ddx(position);
	float3 dpdy = ddy(position);

	float dhdx = ddx(height);
	float dhdy = ddy(height);

	return PerturbNormal(normal, dpdx, dpdy, dhdx, dhdy);
}

Note that in shader model 5.0, you can use ddx_fine/ddy_fine instead of ddx/ddy to get high-precision partial derivatives.

So how does this look? At a medium distance, I would say that it looks pretty good:

But what about up close?

Uh oh! What’s happening here? Well, there are a couple of problems…

The main problem is that the height texture is using bilinear filtering, so the gradient between any two texels is constant. This causes large blocks to become very obvious when up close. There are a couple of options for alleviating this somewhat.

One option is to use bicubic filtering. I haven’t tried it, but I would expect this to make a good difference. The problem is that it will incur an extra cost. Another option, suggested in the paper, is to add a detail bump texture on top. This helps quite a lot, but again it adds more cost.

In the image below I’ve just tiled the same texture at 10x frequency over the top. It would be better to apply some kind of noise function as in the original paper.

The second problem is more subtle. We’re getting some small block artifacts because of the way that the ddx and ddy shader instructions work. They take pairs of pixels in a pixel quad and subtract the relevant values to get the derivative. In the case of the height derivatives, we can alleviate this by performing the differencing ourselves with extra texture samples.

The first problem is pretty much a killer for me. I would rather not have to cover up a fundamental implementation issue with extra fudges and more cost.

What Now?

It’s unfortunate that this didn’t make it into the original paper, but Mikkelsen mentions in a blog post that you can increase the quality by using precomputed height derivatives. This method requires double the texture storage (or half the resolution) of the ddx/ddy method, but produces much better results.

You’re probably wondering how you can possibly precompute screen-space derivatives. We don’t actually have to. Instead we can use the chain rule to transform a partial derivative from one space to another. In our case we can transform our derivatives from uv-space to screen-space if we have the partial derivatives of the uvs in screen-space.

To calculate dhdx you need dhdu, dhdv, dudx and dvdx:

To calculate dhdy you need dhdu, dhdv, dudy and dvdy:

The hlsl for this is very simple:

float ApplyChainRule(float dhdu, float dhdv, float dud_, float dvd_)
{
	return dhdu * dud_ + dhdv * dvd_;
}

Assuming that we have a texture that stores the texel-space height derivatives, we can scale this up in the shader to uv-space by simply multiplying by the texture dimensions. We can then use the screen space uv derivatives and the chain rule to transform from dhdu/dhdv to dhdx/dhdy.

// Calculate the surface normal using the uv-space gradient (dhdu, dhdv)
float3 CalculateSurfaceNormal(float3 position, float3 normal, float2 gradient)
{
	float3 dpdx = ddx(position);
	float3 dpdy = ddy(position);

	float dhdx = ApplyChainRule(gradient.x, gradient.y, ddx(uv.x), ddx(uv.y));
	float dhdy = ApplyChainRule(gradient.x, gradient.y, ddy(uv.x), ddy(uv.y));

	return PerturbNormal(normal, dpdx, dpdy, dhdx, dhdy);
}

So how does this look? Well, it’s pretty much the same at medium distance.

But it’s way better up close, since we’re now interpolating the derivatives.

Conclusions

In order to really draw any conclusions about this technique, I’m going to need to compare the quality, performance and memory consumption to that of normal mapping. That’s a whole other blog post waiting to happen…

But in theory, the pros are:

• Less mesh memory: We don’t need to store a tangent vector, so this should translate into some pretty significant mesh memory savings.
• Fewer interpolators: We don’t need to pass the tangent vector from the vertex shader to the pixel shader, so this should be a performance gain.
• Possible less texture memory: At worst this method requires two channels in a texture. At best, a normal map takes up two channels.
• Easy scaling: It’s easy to change the height scale on the fly by scaling the height derivatives. This isn’t quite so easy to get right when using normal maps. See here. As Stephen Hill points out in the comments below, this is a pretty weak argument, so I’m removing it.

And the cons are:

• More ALU: It’s going to be interesting to see the actual numbers, but this is probably the only thing that could put the nail in the coffin for derivative maps. The extra cost for ALU might be compensated partially by the fewer interpolators, but we’ll have to see.
• Less flexible: A normal map can represent any derivative map, but the reverse is not true. I’m not sure that this is a significant problem in practice though.
• Worse quality? I’m not sure about this one, but it’ll be interesting to see if the quality holds up.

I was impressed when I ran the demo with how smooth his UI looked. It turns out that he’s using a little trick (which I’d never seen before, but I’m sure is old to many) to smooth of the edges of his UI elements.

Basically, the trick is to create a ring of extra vertices by extruding the edges of the polygon out by a certain amount. These extra vertices take the same color as the originals, but their alpha is set to zero. Mikko calls this ‘feathering’.

In my case, I found that I got good results by feathering just one pixel. Here’s a quick before/after comparison of the my IMGUI check box at 800% zoom:

And here’s a 1-to-1 example showing rounded button corners:

It’s a pretty nice improvement for a very simple technique! If you’re interested in what the code looks like, then either take a look at Mikko’s IMGUI implementation, or you can find the code I use to feather my convex polygons below.

My implementation is a little less efficient since I recalculate each edge normal twice, but I chose to keep it simple for readability.

void CalculateEdgeNormal(float& nx, float& ny, float x0, float y0, float x1, float y1)
{
	const float x01 = x1 - x0;
	const float y01 = y1 - y0;

	const float length = Sqrt(x01 * x01 + y01 * y01);

	const float dx = x01 / length;
	const float dy = y01 / length;

	nx = dy;
	ny = -dx;
}

void FeatherConvexPolygon(Primitives& primitives, const Vertex* vertices, int count, float amount, const Texture* texture)
{
	Vertex* extruded = Memory::Allocate<Vertex>(Memory::Temp, sizeof(Vertex) * count);

	for (int i = 0; i < count; ++i)
	{
		const Vertex& previous = vertices[(i + count - 1) % count];
		const Vertex& current = vertices[i];
		const Vertex& next = vertices[(i + 1) % count];

		float nx0, ny0, nx1, ny1;

		CalculateEdgeNormal(nx0, ny0, previous.x, previous.y, current.x, current.y);
		CalculateEdgeNormal(nx1, ny1, current.x, current.y, next.x, next.y);

		float nx = (nx0 + nx1) * 0.5f;
		float ny = (ny0 + ny1) * 0.5f;

		extruded[i] = Vertex(current.x + nx * amount, current.y + ny * amount, Color(current.r, current.g, current.b, 0.0f));
	}

	for (int i = 0; i < count; ++i)
	{
		const int j = (i + 1) % count;
		AddQuad(primitives, vertices[i], extruded[i], extruded[j], vertices[j], texture);
	}

	Memory::Free(extruded);
}

I’ve updated the Google Code repository for DoItNow with a newer version. I’ve removed all source control features from DoItNow and separated them into their own add-in. This should make it more compatible with other add-ins you may be using to handle source control. I’ve uploaded the Mercurial version of the add-in, but the full source is available should you want to change it back to Perforce.

I’m only using Visual Studio 2010 at home now, so the project files are all in that format at the moment. I provided Addin files which will work for Visual Studio 2008 as well though.

By request from someone at work, the open in solution dialog now performs matches on multiple (space-separated) search terms.

FindItNow

I’ve been testing out an idea for a replacement for the standard Visual Studio find-in-files. This is the first pass at it (let’s call it an alpha), so download at your own risk! It’s actually sits side-by-side with the existing find-in-files, so it’s pretty safe to install.

Here’s where it’s (possibly) better:

• It can match multiple search terms and will rank results accordingly.
• Remembers all settings from the previous searches. Pushing up or down will set things like ‘match case’ based on the search history.
• It populates the file types drop down based on the files in the solution, and sorts them by frequency.

Here’s where it’s (definitely) worse right now:

• It doesn’t remember the search paths you used in previous Visual Studio sessions.
• Since it ranks results, it doesn’t present them incrementally. This means you might have to wait longer to get results.
• You can’t cancel a search!

FindItNow ranks search results based on the number of hits on each line, as well as hits in the surrounding few lines. In order for a result to even show up, it must have all search terms present in a seven-line block.

The top matches (100% quality) have all search terms on the line in question. Worse quality matches have progressively fewer matches on the line.

e.g. Here are the results for a search I did looking for a quaternion conjugate function on some of my code:

Query: "quat conjugate"
Options: case=ignore, match=partial
Source: Entire solution
Finding... Complete

Match Quality: 100%
--------------------
c:\Development.old\Libraries\C++\Math\Quaternion.h(79): 		inline Quaternion Conjugate(const Quaternion& quat)
c:\Development.old\Libraries\C++\Math\Quaternion.h(96): 			return Conjugate(quat) / Length(quat);
c:\Development.old\Libraries\C++\Math\Quaternion.h(101): 			const Quaternion result = quat * Quaternion(vec.x, vec.y, vec.z, 0) * Conjugate(quat);

Match Quality: 62%
-------------------
c:\Development.old\Libraries\C++\Math\Quaternion.h(76): 			return Quaternion(lhs.x / f, lhs.y / f, lhs.z / f, lhs.w / f);
c:\Development.old\Libraries\C++\Math\Quaternion.h(81): 			return Quaternion(-quat.x, -quat.y, -quat.z, quat.w);
c:\Development.old\Libraries\C++\Math\Quaternion.h(94): 		inline Quaternion Invert(const Quaternion& quat)
c:\Development.old\Libraries\C++\Math\Quaternion.h(99): 		inline Vector3 Rotate(const Vector3& vec, const Quaternion& quat)

Total files searched: 407
Matching lines: 34
Find Time: 90 ms
Output Time: 9 ms

I’m finding it pretty useful when exploring for functions I think *should* exist in a large code-base since you don’t have to get the exact string to match.

If you’re interested in either of these, you can grab the binaries here.

They’ve kindly shared their efforts back with the main repository in google code. Feel free to profit from their hard work!

Thanks a lot Julian & Clement!

The Arduino is designed to be very easy to use. It comes with a set of tools based on the Wiring programming environment and libraries. The board is controlled by an Atmel 8-bit microprocessor. In comparison to what I spend my days working with, this is a very simple processor. No vector registers, no floating point registers. Even something as simple as adding two 32-bit numbers requires three assembly instructions (add word, add byte with carry, add byte with carry).

While I was waiting for my Arduino to be delivered, I downloaded the IDE and compiled the simple example code to blink an LED once every second. The status window of the IDE dutifully printed out the compilation progress, and at the end, also printed out the executable size – 1018 bytes.

Since I’ve never worked on this platform before I wasn’t sure what the executable size should be, but that seemed a little large to me. So I started to dig around a little bit…

Warning: There’s a fair amount of code and assembly in this post, but I’ll do my best to explain it all!

Start Simple

The Blink program is really simple. It just sets a specific pin on the board to output mode, then continually turns that pin on and off every second.

void setup()
{
	pinMode(13, OUTPUT);
}

void loop()
{
	digitalWrite(13, HIGH);   // set the LED on
	delay(1000);              // wait for a second
	digitalWrite(13, LOW);    // set the LED off
	delay(1000);              // wait for a second
}

I thought I may as well start at the top, so I took a look at the pinMode function. Fortunately, the Arduino codebase is open source and comes as part of the install package.

The pinMode function just sets the data direction (i.e. input or output) of a particular pin on the microcontroller. Most of the pins on the ATmega328p chip are wired into the numbered pins on the Arduino board, but the mapping isn’t one-to-one.

void pinMode(uint8_t pin, uint8_t mode)
{
	uint8_t bit = digitalPinToBitMask(pin); // * Fetch
	uint8_t port = digitalPinToPort(pin); // * Fetch

	volatile uint8_t *reg;

	if (port == NOT_A_PIN) return;

	// JWS: can I let the optimizer do this?
	reg = portModeRegister(port); // * Fetch

	if (mode == INPUT) {
		uint8_t oldSREG = SREG;
		cli();
		*reg &= ~bit;
		SREG = oldSREG;
	} else {
		uint8_t oldSREG = SREG;
		cli();
		*reg |= bit;
		SREG = oldSREG;
	}
}

What Does It Do?

Here’s a quick overview of what this code does by line number:

• 3, 4 & 11: Look up which bit of which particular data direction register (DDR) needs to be set or unset.
• 14 & 15/19 & 20: Perform the first part of the disable interrupts dance – storing off the existing status register and clearing the global interrupt bit (cli).
• 16: Clear the DDR bit if the mode is input
• 21: Set the DDR bit if the mode is output
• 17 & 22: The rest of the interrupt dance – restore the status register to its previous state.

Some Thoughts

• This code performs three fetches (marked) from program memory to convert the Arduino pin number into the correct data direction register and bit. Each fetch from program memory costs 3 cycles.
• It needs to disable interrupts because setting or clearing the DDR bit requires a read/modify/write pattern. If an interrupt happened after the read but before the write, the handler might change that DDR but the portMode function would change it back.
• It stores off the existing status register before disabling interrupts. I presume this is so that it can restore global interrupts to the previous state at the end of the function rather than arbitrarily turning them back on.
• It’s interesting that the author (JWS) hints that there may be a faster way to do this in his comment…

What are we trying to do again?

After looking at all of this code, it’s easy to forget what the point of this function actually is. All it really does is set or clear one bit in a specific data direction register – that’s it! All the other code is just there for support.

Digging Deeper

It’s all very well looking at the source code, but this isn’t what the microcontroller sees. In order to see that, we need to look at the result of the compilation. We can do this really easily by taking the elf that is produced and running it through the disassembler (avr-objdump) included with the toolchain.

avr-objdump -D Blink.elf > Blink.asm

You can also get objdump to interleave the original source code with the disassembly. I sometimes find this more confusing than the plain assembly since it can be misleading with where it places some of the source code.

avr-objdump -S Blink.elf > Blink.asm

Disassemble!

This might look intimidating at first, but please bear with it. The assembly proceeds in the same order as the original source code, and I’ve added comments to explain what’s going on. You can really dig much further into it by looking at the assembly instruction reference in the Atmel Microcontroller Guide, but it’s not necessary to understand the rest of this post.

000002d8 :
// Fetch the port bit mask
2d8:	48 2f       	mov	r20, r24
2da:	50 e0       	ldi	r21, 0x00	; 0
2dc:	ca 01       	movw	r24, r20
2de:	86 56       	subi	r24, 0x66	; 102
2e0:	9f 4f       	sbci	r25, 0xFF	; 255
2e2:	fc 01       	movw	r30, r24
2e4:	24 91       	lpm	r18, Z+
// Fetch the processor port
2e6:	4a 57       	subi	r20, 0x7A	; 122
2e8:	5f 4f       	sbci	r21, 0xFF	; 255
2ea:	fa 01       	movw	r30, r20
2ec:	84 91       	lpm	r24, Z+
// Return if the port is invalid
2ee:	88 23       	and	r24, r24
2f0:	c1 f0       	breq	.+48     	; 0x322
// Fetch the DDR address
2f2:	e8 2f       	mov	r30, r24
2f4:	f0 e0       	ldi	r31, 0x00	; 0
2f6:	ee 0f       	add	r30, r30
2f8:	ff 1f       	adc	r31, r31
2fa:	e8 59       	subi	r30, 0x98	; 152
2fc:	ff 4f       	sbci	r31, 0xFF	; 255
2fe:	a5 91       	lpm	r26, Z+
300:	b4 91       	lpm	r27, Z+
// Check the mode and branch if necessary
302:	66 23       	and	r22, r22
304:	41 f4       	brne	.+16     	; 0x316
// Clear the DDR bit and return
306:	9f b7       	in	r25, 0x3f	; 63
308:	f8 94       	cli
30a:	8c 91       	ld	r24, X
30c:	20 95       	com	r18
30e:	82 23       	and	r24, r18
310:	8c 93       	st	X, r24
312:	9f bf       	out	0x3f, r25	; 63
314:	08 95       	ret
// Set the DDR bit and return
316:	9f b7       	in	r25, 0x3f	; 63
318:	f8 94       	cli
31a:	8c 91       	ld	r24, X
31c:	82 2b       	or	r24, r18
31e:	8c 93       	st	X, r24
320:	9f bf       	out	0x3f, r25	; 63
322:	08 95       	ret
000002ce :
// Copy the parameters into registers
2ce:	8d e0       	ldi	r24, 0x0D	; 13
2d0:	61 e0       	ldi	r22, 0x01	; 1
// Call pinMode
2d2:	0e 94 6c 01 	call	0x2d8	; 0x2d8
2d6:	08 95       	ret

The pin mode function is comprised of 38 assembly instructions. The call to pinMode from Setup call requires an additional 3 instructions – 2 to put the parameters into registers, and 1 to call the function. That’s a grand total of 41 instructions. That sounds like an awful lot of work just to set one bit.

Isn’t there an easier way to set or clear a bit in a register? Of course there is. If you look at the assembly instruction reference, there’s actually a single instruction (sbi) that sets a specific bit in a register. There is a corresponding instruction (cbi) to clear that bit.

Improving pinMode

Ok, so we know in theory it could be more efficient, but how do we get the compiler to do this so that we don’t have to look at assembly all of the time? Aren’t there other things we need to worry about? What about interrupts? What about the memory fetches?

I made a few different changes to the pinMode function to try and reduce the instruction count. I’m going to go over them in the order I attempted them.

Removing One Fetch

As the old adage goes, two memory fetches are better than three. Well, perhaps it’s not an adage, but it’s true nonetheless.

The original code looks up the port number using the pin index, then uses the port number to look up the DDR address. We can skip that first lookup by creating a table that goes directly from pin index to DDR address.

You’re probably thinking, “but that’ll cost more memory”, and you’d be right. We’ll address that shortly though. First, let’s see what that does to the assembly.

000002e0 :
// Fetch the port bit mask
2e0:	a8 2f       	mov	r26, r24
2e2:	b0 e0       	ldi	r27, 0x00	; 0
2e4:	cd 01       	movw	r24, r26
2e6:	8e 53       	subi	r24, 0x3E	; 62
2e8:	9f 4f       	sbci	r25, 0xFF	; 255
2ea:	fc 01       	movw	r30, r24
2ec:	24 91       	lpm	r18, Z+
// Fetch the DDR address
2ee:	a4 58       	subi	r26, 0x84	; 132
2f0:	bf 4f       	sbci	r27, 0xFF	; 255
2f2:	8c 91       	ld	r24, X
2f4:	e8 2f       	mov	r30, r24
2f6:	f0 e0       	ldi	r31, 0x00	; 0
// Check the mode and branch if necessary
2f8:	66 23       	and	r22, r22
2fa:	31 f4       	brne	.+12     	; 0x308
// Clear the DDR bit
2fc:	9f b7       	in	r25, 0x3f	; 63
2fe:	f8 94       	cli
300:	80 81       	ld	r24, Z
302:	20 95       	com	r18
304:	28 23       	and	r18, r24
306:	04 c0       	rjmp	.+8      	; 0x310
// Set the DDR bit
308:	9f b7       	in	r25, 0x3f	; 63
30a:	f8 94       	cli
30c:	80 81       	ld	r24, Z
30e:	28 2b       	or	r18, r24
310:	20 83       	st	Z, r18
312:	9f bf       	out	0x3f, r25	; 63
// Return
314:	08 95       	ret

It’s definitely better – we’ve reduced the function size by 11 instructions, but we’ve also added another constant table of 20 bytes (not shown). Each assembly instruction is 2 bytes, so we have a net saving of only 2 bytes. Let’s do something about that.

Inlining

Inlining a function just means that the compiler puts the code directly into the caller site rather than jumping to a separate function. No function call means that we don’t pay the cost (three instructions in this case) of calling the function. It also allows the compiler to be more aggressive about optimizations.

Often, the compiler will inline functions in the same file automatically when it can. If you want to share that function, then you can put it in a header file and explicitly mark it as inline by including ‘inline’ in front of the function declaration.

The main drawback of inlining function calls is that it can make your code larger since duplicates of the same function can be scattered around the compiled code.

In this case, the code size for calling the non-inlined function just once is 3 instructions per call, plus 27 instructions for the function itself. Assuming we call the function N times, and the inlined function size is Y, then a rough guide for when it’s better (spacewise) to inline is when N * Y < N * 3 + 27.

Wouldn’t it be nice if Y were 3 or less? Then it’s always better to inline.

Let’s try it out for portMode and see how it affects the assembly size. Note that we’re now looking at the Setup function, since that’s the place where pinMode was being called from, hence the place where the inlined function now resides.

00000368 :
// Fetch the port bit mask
368:	e7 ea       	ldi	r30, 0xA7	; 167
36a:	f0 e0       	ldi	r31, 0x00	; 0
36c:	e4 91       	lpm	r30, Z+
// Set the DDR bit
36e:	9f b7       	in	r25, 0x3f	; 63
370:	f8 94       	cli
372:	84 b1       	in	r24, 0x04	; 4
374:	e8 2b       	or	r30, r24
376:	e4 b9       	out	0x04, r30	; 4
378:	9f bf       	out	0x3f, r25	; 63
// Return
37a:	08 95       	ret

Wow, that’s pretty small – just 9 instructions (not including the return for Setup) now… Where did all of the code go?

The compiler now knows exactly what the function parameters are, so it can go to town on optimizing the code for those particular parameters rather than having to support the general case.

• It got rid of the branch when the pin index is out of bounds since it knows what the pin index is now.
• It removed the entire part of the function to deal with the input mode – not needed.
• It worked out which data direction register is needed by looking at the array and indexing into it at compile time.
• It’s still loading the bit mask from program memory though…

Why could it resolve the DDR address at compile time, but not the bit mask? They’re both just arrays of bytes indexed by the pin.

The answer to this one is to do with where the arrays are defined. Because I made the DDR address array myself, I put it in the same file as pinMode. The bit mask array is in an entirely different file, so the compiler couldn’t index into it during compilation.

That’s pretty easy to fix – just move the array into the same file as pinMode.

00000368 :
// Set the DDR bit
368:	8f b7       	in	r24, 0x3f	; 63
36a:	f8 94       	cli
36c:	25 9a       	sbi	0x04, 5	; 4
36e:	8f bf       	out	0x3f, r24	; 63
// Return
370:	08 95       	ret

Great! No more memory fetches! But hang on… What happened to where it sets the DDR bit? It used to load the DDR register, ‘or’ in the mask, the write the DDR register back out.

Again, the compiler is being clever. It knows that the mask only ever contains one bit, so it can use the more optimal ‘sbi’ instruction.

Interrupts

If you remember, we needed the interrupt because of the fact that we were reading, modifying then writing to a register. But now we only have on instruction to set the bit.

The Atmel guide says that an instruction will finish before an interrupt is processed – even if that instruction takes multiple cycles (sbi takes 2 cycles). This means that we don’t need to disable interrupts since you can’t get an interrupt at a bad time.

Et Voila!

Removing interrupts removes three instructions, so that’s it. We’re down to a single instruction to set a bit, as it should be.

00000368 :
// Set the DDR bit
 368:	25 9a       	sbi	0x04, 5	; 4
// Return
 36a:	08 95       	ret

Summary

The code went from 41 instructions for a single call to just 1. What’s more, the savings increase the more frequently we call it. Not only is it smaller, it’s also faster.

I compiled and ran the Blink application using the modified pinMode function, and the program size went down to 936 bytes. Not bad for a quick bit of experimentation.

void pinMode(uint8_t pin, uint8_t mode)
{
	const uint8_t digital_pin_to_bit_mask[] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20 };
	const uint8_t digital_pin_to_ddr[] = { 0x2A, 0x2A, 0x2A, 0x2A, 0x2A, 0x2A, 0x2A, 0x2A, 0x24, 0x24, 0x24, 0x24, 0x24, 0x24, 0x27, 0x27, 0x27, 0x27, 0x27, 0x27 };

	uint8_t bit = digital_pin_to_bit_mask[pin];
	volatile uint8_t* reg = (volatile uint8_t*)digital_pin_to_ddr[pin];

	if (mode == INPUT)
		*reg &= ~bit;
	else
		*reg |= bit;
}

I think there’s the potential for performance optimizations such as these the elsewhere in the Arduino codebase. For example, digitalWrite has many of the same issues as pinMode, so the same solutions would apply.

I suspect that even more optimizations could be applied by putting more of an onus on the programmer to do things like remember to turn off pulse width modulation on a pin when it’s not needed.

On the other hand, I understand why some of the decisions have been made as they stand – to keep things simple. The nice thing is that the source code is provided, so it’s easy for those who want to look at the original code to change it to suit their needs.

I would definitely recommend having a look at the assembly for your Arduino programs every now and then. It gives you a good idea of what’s really happening at the hardware level. It can also give you insight into how you might be able to speed things up, or reduce program size.

The biggest lesson I learned throughout this is this: 8 year olds don’t care about optimizations and disassembly. They like flashing lights, buttons, sensors, motors and other cool stuff like that.

I should have known…

Well, you could point out a number of things to answer that question. There’s some pretty obvious aliasing, a random pixel on the ground which should be in shadow but isn’t, it’s noisy, boring etc. But that’s not my point. The point is: It’s too dark!

I know it’s too dark because I know how I rendered it, and I rendered it wrong. It still kind of looks acceptable (well to me at least) though. I’m not sure that I would say that it’s implausibly dark if I didn’t know it.

How many bounces are enough?

I rendered this image using a Monte Carlo estimator with two bounces of indirect light. Each bounce estimated the irradiance at the intersection point using 256 rays in a cosine-weighted stratified-sampling pattern. It’s the two bounce part that makes it wrong. Any light that bounced more than twice before heading toward the camera is totally ignored. Since this approach doesn’t converge on the correct solution to the rendering equation, it’s classified as ‘biased’.

How much does light that bounced more than twice really contribute to a scene? Of course that depends on the materials in the scene quite a bit, but in this case, there’s a noticeable difference. I rendered the same exact scene using the Monte Carlo estimator for the first bounce, but for the subsequent bounces I used a path tracer. By using Russian Roulette (a topic unto itself) to terminate the path, you can get an unbiased approximation of the irradiance.

Ok, great. It’s brighter, but is it actually correct? I was wondering about this, then I happened to come across an idea while reading Physically Based Rendering to compare the results of my integrators with something that has an analytical solution to the rendering equation.

I now present an analytical solution to the Rendering Equation!

(… in a very simple case)

Solving the rendering equation analytically for most scenes is just impossible, that’s why we have to rely on numerical methods like Monte Carlo Estimation. However, the book suggests a very simple scene for which it can be solved. The suggested setup is that of light bouncing around the inside of a sphere. The sphere emits light internally, and reflects it diffusely to other points on the inside of the sphere. Since the sphere is rotationally invariant and the reflections are diffuse, every point on the sphere reflects and emits the same radiance in all directions.

So how do you solve the rendering equation for this situation? It’s fairly easy. Recall the rendering equation:

In this setup, we are using a diffuse BRDF with reflectance d. It’s also normalized to maintain energy conservation

Also, as mentioned previously, the outgoing radiance in all directions is the same as the incoming radiance, so this reduces the rendering equation to:

Solving this equation for L is now pretty easy. First we have to convert from an integral over solid angles, to a double-angle version. The important thing to remember when doing this is to introduce the new sine term:

There’s a double angle trigonometric identity that makes this easier:

So we just need to integrate the following:

Integrate over theta:

This integral over theta is just 1, so now integrate over phi:

This integral is of course just 2 Π. So we’re left with a very simple equation:

Solving for L gives us the final expect radiance at every point in the sphere:

This intuitively makes sense. As d grows, so does L. When d is 1, all hell breaks loose, and when d is 0 all we are left with is the emitted light. Obviously d can never be greater than 1 or the energy conservation rule would have been broken.

The test application

Alright, so all I need to do now is make a test application that fires a bunch of rays around the inside of a sphere and compare the results to the analytical solution. Well… So I thought. Due to the curvature of the inside of the sphere, I found that a good number of rays I fired near the horizon were escaping the sphere.

Currently I apply an epsilon to the minimum ray intersection to try and prevent self-intersections and this causes problems. For now (and just for these tests), instead I’m pushing the ray starting point away from the intersection a small amount in the direction of the intersection normal. I made the sphere really big too. I’d welcome any better ideas for alleviating this problem.

For the tests below, I set the emitted light value to 1, and the diffuse reflectance, d, to 0.5, meaning that the outgoing radiance, L, should be 2.

Multi-bounce Monte Carlo results

You can work out from the radiance equation how different numbers of bounces of light will affect the final solution. In this case, I just ran my Monte Carlo integrator from 0 to 16 bounces and produced the following graph showing the percentage (of the expected result) absolute error.

You can see that the error starts off really high, but drops off pretty quickly as more bounces are added. Each subsequent bounce has less and less effect on the error reduction, as expected.

What you have to remember though, is that each bounce adds exponentially to the number of rays that have to be cast to achieve that error. In real-world situations we need to cast a lot of rays over the hemisphere in order to get a correct solution. To get under 5% error you’d need four bounces with this method. Even using a very modest number of rays per estimation quickly becomes unruly: 256 rays with 4 bounces = over 4 billion rays needed! Per pixel! Without anti-aliasing!

Path Tracer results

Ok, so how about the path tracer? In theory the path tracer should average out to zero error, but can have potentially very high variance. Here’s the average error over 1000 runs with different survival probabilities:

Well, it’s not zero everywhere, but it’s a pretty close in most cases. I think that the results obtained from this kind of method probably depend quite a bit on the quality of the random number generator used. I’m just using the stdlib version, so I’ll try switching it up at some point to see how it affects things. I haven’t shown it here, but the variance at low survival probabilities is incredibly high. This surely accounts for how far off the results are under about 10% survival.

The good thing about the path tracer is that it doesn’t require exorbitant numbers of rays. Yes, the variance can be high, but it can be reduced by tracing more paths. The net result is that it produces low error images much quicker than using standard Monte Carlo integration.

The End

Well, the point of this post really was: How do you know your integrator is correct? Comparing it to something simple that can be calculated analytically is not the be-all and end-all, but it’s a good start. There are many other things that could still be wrong even if your integrator gets good results against this simple test, like how you’re calculating sample directions, your PDF etc.

For me, being able to compare my integrators to a known solution definitely helped me to make sure that my path tracer was getting correct results.

Things have changed a lot with Direct3D 11. The rendering API has been separated from the factory functions into a separate object called the device context. The factory functions on the device are all free threaded, meaning that they can be called from any thread. The device context functions are designed to be called from the same thread.

The basic idea behind multithreading in Direct3D 11 is that you create an immediate device context on the main thread. Then, for each thread on which you’d like to be able to render, you create a deferred context. As you can probably guess from the names, commands executed on the immediate context get executed immediately, but those on the deferred context just get saved off into a command list. You then execute the deferred command lists on the main thread using the immediate device context. Sounds easy enough.

Thread Pools

Given that you can submit draw calls to deferred contexts on multiple threads, it makes sense to ditch the single rendering thread concept and switch to using something like a thread pool for issuing the draw calls. This scales far better than a dedicated rendering thread. It’s also pretty easy to set up a simple thread pool, and give each worker thread a deferred render context.

There are plenty of places on the internet to read about thread pools so I’m not going to get into it here, but one thing I can’t stress enough is to make sure that you get your synchronization right! In my initial implementation, I used my normal queue data structure, but wrapped it up in mutexes (mutices?) to make sure it was thread-safe. This worked out well since I was very confident that things were working correctly, but a quick foray into VTune told me that I was spending 40% of the time waiting on synchronization points!

After some quick digging around, I came across a few articles that Herb Sutter wrote for Dr Dobb’s Journal about producer/consumer queues. I implemented the low-lock queue recommended by Sutter, and got a good speedup of at least 30% (that number is off the top of my head, but I remember it was a lot). The relevant articles I read are single producer/consumer queue, generalized concurrent queue, and measuring performance. I still use events for sending the worker threads to sleep when there is nothing left to work on, and to wake them up when data is added to the queue.

My application already stores up all of the state needed for a draw call in an object called a RenderContext, so instead of passing off this render context to the renderer on the main thread, instead it just gets enqueued to be rendered by one of the threads in the thread pool. When the worker thread gets to it, it passes the render context off to a thread-local renderer object initialized with a deferred device context. This renderer sets all of the changed state and issues the final draw call.

Finally, back on the main thread, it waits until all of the render contexts have been submitted to the deferred device contexts, and then executes each of these on the immediate device context.

Test Scenario

In order to stress my renderer a bit, I fabricated a scenario with 10,000 models. Each model has a sphere and a ground plane with their own material. I use a loose octree for culling out the models outside of the frustum, but I don’t do any sorting of any kind. This means that the alternating materials that get rendered for the sphere and then the ground put a fair amount of stress on the CPU side of the renderer.

My single threaded renderer took about 50 ms to render the intial view of the scene. By switching to using the thread pool, this went down to about 30 ms. A nice improvement, that’s for sure. Obviously, as fewer objects are visible, the gains of using the multithreaded renderer disappeared.

Profiling

I was happy that the multithreading appeared to be doing its job, but I wasn’t quite satisfied because I couldn’t really tell how well it was doing. Time for some profiling!

There appear to be quite a few CPU profilers out there. First of all I downloaded an evaluation of Intel VTune. It’s pretty overwhelming, but it gave me a lot of pertinent information. The bugger is that you have to pay a hefty sum for it, so I tossed it out of the window. I also tried out Microsoft xperf. This sampling profiler gave me a pretty good overview of what was expensive with the standard inclusive/exclusive view. It was a great help for quickly tracking down some areas of the code that I could very easily improve. I still use this.

The trouble with most of the sampling profilers is that they don’t know about frames. They just add up all of the samples over the given time period which gives you an idea on average what is happening. I wanted to get information about what was happening within the frame, so I implemented a really simple frame profiler.

Frame Profiler

An in-game profiler is a really handy tool to have. It lets you see in real-time exactly how your CPU time is being spent in one frame on each of your threads. It’s also pretty easy to set up.

First of all, I created a class called ThreadProfiler. As the name suggests, the ThreadProfiler class is responsible for recording events on a specific thread. This class has functions to notify it of the beginning and end of the frame, as well as when a profiling event begins and ends. All it really does is to record the name of the event, a color for display, and the timestamps when the event begins and ends. The events can be nested, so it maintains a stack of active events and records the depth of the stack for each event.

Next I created the singleton FrameProfiler class. The idea for this class is to hold all of the ThreadProfiler objects, and to forward events onto those classes based on the current thread ID. Threads are required to register their thread ID with the frame profiler in order for events to be recorded.

        class FrameProfiler : public Core::Singleton<FrameProfiler>
        {
        public:

            FrameProfiler();

            void RegisterThread(int threadId);

            void BeginFrame(bool enabled);
            void EndFrame();

            void BeginEvent(int threadId, const Core::String& name, uint32 color);
            void EndEvent(int threadId);

            DataStructures::ArrayList<ThreadProfiler>& GetThreadProfilers();
            const DataStructures::ArrayList<ThreadProfiler>& GetThreadProfilers() const;

        private:

            DataStructures::ArrayList<ThreadProfiler> m_threadProfilers;
        };

The final piece is a really simple macro which grabs the function name and creates an object which tells the FrameProfiler when it is created and destroyed. This is the macro that I place into whatever function or loop I’d like to profile.

class ScopedProfileEvent
{
public:

        ScopedProfileEvent(const Core::String& name, uint32 color)
        {
                if (FrameProfiler::IsCreated())
                {
                        FrameProfiler::Instance().BeginEvent(Core::Platform::GetCurrentThreadId(), name, color);
                }
        }

        ~ScopedProfileEvent()
        {
                if (FrameProfiler::IsCreated())
                {
                        FrameProfiler::Instance().EndEvent(Core::Platform::GetCurrentThreadId());
                }
        }
};
#define PROFILE(X) const Profile::ScopedProfileEvent event__LINE__(String(__FUNCTION__), (uint32)X)

Unlike a sampling profiler, this kind of profiling has a certain amount of processing overhead. There are a couple of quick things you can do to help with this though. The first is just to make sure that you don’t always have the overhead, and compile it out for your final builds. It’s important to do your profiling on an optimized build, so I would recommend debug, release, and final configurations or something similar. The second thing you can do is to just not run it every frame. I have it set on a key press so that I can get to the area I’d like to profile without the overhead, then hit the button to profile the next frame and display the results.

I’m not sure about how accurate this would be, but you could probably compare the previous frame’s duration to the profiled frame to get a rough estimate of the overhead that the profiling functions added. I wouldn’t rely on that though.

There’s actually quite a bit of information that can be gleaned from these profiling events, but the first thing I did was to render out the events as rectangles on a timeline. In the image below, I have two threads running. The main thread at the bottom has three levels of nested events being shown, and the top worker thread just has one.

Ok, there’s no legend right now, but I’m working on it. Each black/grey bar in the background represents one millisecond of frame time.

The bottom row on the main thread represents the update in green, the render in blue, and the call to Device::Present in red. Given the long red bar, I’d say I’m GPU limited in this scene.

The row above represents the breakdown of the render function from the bottom row. The cyan sliver is shadow rendering (actually I’m not rendering any shadows which is why it’s tiny). The huge magenta bar is the model rendering, and the yellow bar is post-processing.

The top row in the bottom thread represents the breakdown of the model rendering function. The green slivers are models being found in the octree and the red blocks are models being prepared for rendering. The large white bar is actually the command list from the worker thread being executed on the immediate device context. I was pretty surprised to see this segment so large, since I didn’t notice it in the other profilers at all.

Experiments

Now that I have a frame profiler, I can really experiment with my thread pool setup to see how it affects the frame. My computer has a dual core processor, so based on Sutter’s articles, I was expecting that one main thread and one worker would be the best setup. Even so, I tried running a variety of numbers of worker threads to see how it looked. Here’s what four threads looks like:

The first thing I noticed was just how much worse all of the threads fared. Each worker thread appeared to perform a tiny bit of work, and then get swapped out for another thread. The main thread really suffered due to this too. This is a great example of how visualizing this data is really illuminating. The scene was already GPU bound, so even though the rendering code was performing far worse, the frame rate actually stayed the same.

Another experiment I wanted to run was just how much other applications could affect the frame rate of my application. In this case, I just had sysinternals process exlporer running and polling the system processes every half second. It only took me a few tries to hit a frame where I could see the effect:

Notice the scale of the millisecond bars now – this frame took over twice as long to run as my first example with the exact same setup. You can see a big gap on the worker thread where another process stole its time. Event when it did get some time, it appears to be running very slowly.

Also, you can now see a large grey bar in the middle row of the main thread which shows the main thread waiting for the worker thread to finish.

The execution of the command list is pretty consistently taking up three and half milliseconds or so. This is much higher than I had thought it would be. I really hope that this time gets reduced with newer drivers or hardware.

One last thing I’ve done to investigate what is happening in my application is to display the frame rate history. I use a moving average to calculate the frame time, so I have the last 100 frames stored anyway. It’s a simple enough task to just display this.

You can see how varied the frame times are even though the camera isn’t moving. This is probably due to other processes on my computer interfering I’d imagine.

Final Thoughts

It was a fun adventure porting my code to Direct3D 11, particularly implementing a multithreaded renderer using a thread pool. I would recommend trying it out to those of you who have Direct3D 10 engines at the moment.

The jump from Direct3D 10 to 11 is nowhere near as bad as the previous jump from 9 to 10. It took me about three hours to change my rendering code to deal with the changes. The most awkward part was probably having to pass in the device context to functions which need to map buffers, since these functions are no longer on the buffers themselves.

Visualizing profiling data in real time can be a real eye-opener for understanding how your code is actually running rather than how you think it may be running. It has really helped me identify good candidates for moving to using the thread pool as well as pointing out areas of the code that are taking a surprisingly large amount of frame time.