event PostBeginPlay()
{
  // Do something
}

However, my typical style places the opening brace on the current line:

event PostBeginPlay() {
  // Do something
}

Unfortunately, this does not seem to work for defaultproperties blocks. If you place the brace on the same line, the compiler will not give you any warnings or errors, but the entire defaultproperties block is just ignored!

So this code works:

defaultproperties
{
  PlayerControllerClass=class'MyPlayerController'
}

while the following code compiles but silently just ignores all of the contained settings:

defaultproperties {
  PlayerControllerClass=class'MyPlayerController'
}

I was banging my head on the wall for at least an hour figuring this one out!

I hope this can help prevent someone else from repeating my mistake.

This game was developed by myself, Jason Kim, Joseph Ahn, Vjekoslav Kovacevic, and Daniel Guinn for a computer animation class during Winter Quarter 2007.

You can find a zip file here. This requires XNA 4.0 and the February 2010 DX packages to be installed on your machine. For convenience, I’ve included both of the redistributable packages in the zip file.

The source can be found on BitBucket.

Enjoy!

When it comes to GUI frameworks for C++, it’s very hard to beat Qt.  It’s modular, easy to use, and available on practically any desktop system (and even a few mobile systems).  The MOC’ing can get a bit annoying, but IDE and command-line support is very mature at this point.  However, only OpenGL is supported currently for real-time 3D rendering. If you want to render to a Qt widget from a Direct3D 11 device, you end up having to do a lot of setup yourself.

Unfortunately, there is not a lot of information out on the internet about setting up Direct3D to play nice with Qt.  Most of the information is either out-dated, or only applies to Direct3D 9.  Lately, I’ve been playing around with this and I want to share my method for combining Direct3D 11 and Qt.

Creating a Widget

To start, we define a new widget sub-class specifically for Direct3D 11 rendering. On the Qt side, the key to eliminating flickering or UI artifacts is the paintEngine() method.  We need a way to tell Qt that we want complete control over drawing for our widget, so we can override paintEngine() in our widget definition:

class D3DRenderWidget : public QWidget {
  Q_OBJECT
  Q_DISABLE_COPY(D3DRenderWidget)
public:
  D3DRenderWidget(QWidget* parent = NULL);
  virtual ~D3DRenderWidget();
  virtual QPaintEngine* paintEngine() const { return NULL; }
protected:
  virtual void resizeEvent(QResizeEvent* evt);
  virtual void paintEvent(QPaintEvent* evt);
};

(Note that for ease of viewing, all of the fields have been removed from this code snippet)

We also need to set a few attributes on our widget, as shown in the constructor:

D3DRenderWidget::D3DRenderWidget(QWidget* parent)
: QWidget(parent) {
  setAttribute(Qt::WA_PaintOnScreen, true);
  setAttribute(Qt::WA_NativeWindow, true);

  // Create Device
  createDevice();
}

First, we tell Qt that we do not want it to do any draw buffering for us. Second, we require a native window handle for our widget. Otherwise, Qt may re-use the same native handle for multiple widgets and cause problems for our Direct3D rendering. You may have also noticed the createDevice() method call; this will be explained in a bit.

Creating the Direct3D 11 Device

Now that we have a basic widget that can support Direct3D rendering, we can initialize the Direct3D 11 device we want. This procedure is mostly identical to setting up Direct3D in a raw window. The only difference is that we must use the width(), height(), and winId() methods to return the widget size and native window handle, respectively:

swapChainDesc_.BufferCount = 1;
swapChainDesc_.BufferDesc.Width = width();
swapChainDesc_.BufferDesc.Height = height();
swapChainDesc_.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
swapChainDesc_.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
swapChainDesc_.SampleDesc.Count = 4;
swapChainDesc_.SampleDesc.Quality = 0;
swapChainDesc_.Windowed = true;
swapChainDesc_.OutputWindow = winId();
swapChainDesc_.BufferDesc.RefreshRate.Numerator = 60;
swapChainDesc_.BufferDesc.RefreshRate.Denominator = 1;

Everything else remains the same… pretty easy, huh?

Handling Paint Events

Remember the paintEvent override from the widget class definition? We can simply implement it with a call to some rendering function:

void D3DRenderWidget::paintEvent(QPaintEvent* evt) {
  render();
}

Here, render() is just some arbitrary method that uses the Direct3D 11 device to render something to the primary swap chain.

Handling Resize Events

Resize events are perhaps the hardest events to handle when integrating Direct3D 11 and Qt. To resize our swap chain, we need to release all device-allocated resources, and reallocate them. The procedure I follow is:

void D3DRenderWidget::resizeEvent(QResizeEvent* evt) {
  releaseBuffers();
  swapChain_->ResizeBuffers(1, width(), height(),
                            swapChainDesc_.BufferDesc.Format, 0);
  swapChain_->GetDesc(&swapChainDesc_);
  viewport_.Width = width();
  viewport_.Height = height();
  createBuffers();
}

We start by releasing all of the buffers we had allocated (vertex buffers, index buffers, shaders, textures, etc.). We then issue a resize request to the swap chain, resize our rendering viewport, and then recreate all of our needed buffers. In this snippet, releaseBuffers() will call Release() on all buffers, and createBuffers() will create all of the needed resources (again).

It would probably be easier to just allow the swap chain to grow and just adjust the viewport if the widget shrinks, but this method shows how to keep the swap chain the exact same size as the widget.

Conclusion

At this point, you should have a functional Direct3D 11 rendering context for a Qt widget. For brevity, I have omitted most of the Direct3D initialization code (this can be found in many places on the web).

If you want to check out the complete sample program, it is located on my BitBucket account. To build it, you need a relatively recent Qt release, the DirectX SDK, and the Qt Visual Studio Add-in.

According to the programming guide, this environment variable can take one of three values:

Therefore, if you run your OpenCL program with:

$ GPU_DUMP_DEVICE_KERNEL=3 ./my-program

You will get two files in your local directory: [kernel-name]_[device-name].il and [kernel-name]_[device-name].isa, which contain AMDIL and Device ISA disassembly, respectively.

In this post, I aim to give a quick overview of how to use the back-end to compile OpenCL kernels.

As an example, consider the following matrix multiplication routine written in OpenCL:

#define BLOCK_SIZE 16

__kernel
void matmul(__global float* A, __global float* B, __global float* C) {

__local float scratchA[BLOCK_SIZE][BLOCK_SIZE];
__local float scratchB[BLOCK_SIZE][BLOCK_SIZE];

int globalX = get_global_id(0);
int globalY = get_global_id(1);
int size = get_global_size(0);
int k;
float sum = 0.0f;
int numBlocks = size / BLOCK_SIZE;
int b;

int tidX = get_local_id(0);
int tidY = get_local_id(1);

for(b = 0; b < numBlocks; ++b)
{
// Populate a cache for A/B
int x;
int y;

x = b * BLOCK_SIZE + tidX;
y = globalY;

scratchA[tidY][tidX] = A[y * size + x];

x = globalX;
y = b * BLOCK_SIZE + tidY;

scratchB[tidY][tidX] = B[y * size + x];

barrier(CLK_LOCAL_MEM_FENCE);

for(k = 0; k < BLOCK_SIZE; ++k)
{
float myA;
float myB;

myA = scratchA[tidY][k];
myB = scratchB[k][tidX];

sum += myA * myB;
}

barrier(CLK_LOCAL_MEM_FENCE);
}

C[globalY * size + globalX] = sum;

}

We can use the libclc library, written by Peter Collingbourne, to provide the OpenCL built-in functions for Clang.  This library will map OpenCL built-in functions to target-specific functions in the LLVM IR that the PTX back-end knows how to handle.  If $LIBCLC points to the download of libclc, then you can invoke Clang with:

clang -ccc-host-triple ptx32
-Xclang -target-feature -Xclang +ptx23
-Xclang -target-feature -Xclang +sm20
-I$LIBCLC/include/generic -I$LIBCLC/include/ptx
-include clc/clc.h -Dcl_clang_storage_class_specifiers
-O3 matmul_kernel.cl -S -o matmul_kernel.ptx

The options can be a bit verbose at the moment, but practically all of them can be placed in a wrapper script.  Clang will compile the kernel and emit the generated PTX code to matmul_kernel.ptx.  This code can then be loaded as an OpenCL binary kernel using the nVidia OpenCL SDK, using the clCreateProgramWithBinary function.  As an added bonus, the performance is about the same as if the kernel was compiled using the nVidia OpenCL compiler!

For those of you that do not know, Matplotlib is an excellent Python plotting library that allows you to create professional-quality plots for inclusion on web pages, Latex documents, Beamer presentations, Keynote presentations, and any other software that can import SVG, EPS, PNG, or virtually any graphic format.

However, getting matplotlib installed on Mac OS X 10.7 can be a bit tricky, especially if you are using Homebrew as your “package manager.”  First off, Homebrew does not have packages for matplotlib, as well as some of its dependencies.  Additionally, the current Matplotlib release version (1.0.1 as of this post) does not compile out-of-the-box against libpng 1.5, which is included in the X11 distribution shipped with Mac OS X 10.7.

For previous versions of Mac OS X (10.6, 10.5), the usual way to install matplotlib was to install python, pkg-config, and gfortran with Homebrew, then install numpy and matplotlib through pip, ala:

$ brew install python
$ brew install gfortran
$ brew install pkg-config
$ easy_install pip
$ pip install numpy
$ pip install matplotlib

Unfortunately, as previously mentioned, all is not so easy in the world of Mac OS X 10.7, and the difficulty lies with libpng 1.5, installed with Mac OS X 10.7′s version of X11. Briefly put, Matplotlib 1.0.1 is not compatible with libpng 1.5 due to a change in the API. Fortunately, the fix is already applied up-stream and will probably be a part of Matplotlib 1.0.2, or 1.1.0, or whatever the next released version is.

Until the next release, the Matplotlib sources in Git can be used. Instead of pulling the sources from the Matplotlib SourceForge site, you need to pull them from the Matplotlib GitHub site. I’m not sure if this GitHub site is “official,” but is looks to be.

All that is needed is to build Matplotlib from source instead of using pip, so the installation procedure is now:

$ brew install python
$ brew install gfortran
$ brew install pkg-config
$ easy_install pip
$ pip install numpy
$ cd $HOME
$ git clone https://github.com/matplotlib/matplotlib.git
$ cd matplotlib
$ python setup.py build
$ python setup.py install

And now you’re good to go! Hopefully this will become much easier with the next official release of Matplotlib.

The Problem

The problem was simple.  Suppose you have a C++ template class/struct that is parameterized by a single type, e.g.

template <typename T>
class my_data {
// ...
private:
  T element_;
};

The Solution

Now, the question is, “how do I write a method for this class/struct that maps the type of T to an enumeration value?”  For context, the real problem involved mapping T to an MPI data type, e.g. (float -> MPI_FLOAT), (double -> MPI_DOUBLE), etc..

The first thought for anyone familiar with containers may be to explicitly generate a map, e.g. std::map in this case, to hold all possible mappings from the C++ type (via typeid()) to the MPI type (really just an integer).  Such a solution is certainly valid and may be the best way to approach the problem in another language such as C# or Java.  After pondering the “C++” solution to the problem for a few minutes, my colleague and I came up with a fairly elegant solution involving templates.  Or, at least I found it quite elegant.

/**
 * This struct wrappers the MPI data type value for the given C++ type.
 *
 * Any valid MPI data type value must have a corresponding explicit template
 * instantiation below.
 */
template <typename T>
struct mpi_type_wrapper {
  int mpi_type;
  mpi_type_wrapper();
};

// Explicit instantiation for `float'
template <>
mpi_type_wrapper<float>::mpi_type_wrapper()
: mpi_type(MPI_FLOAT) {}

// Explicit instantiation for `double'
template <>
mpi_type_wrapper<double>::mpi_type_wrapper()
: mpi_type(MPI_DOUBLE) {}

The mpi_type_wrapper struct is a convenient way to convert an arbitrary C++ type to an equivalent MPI type.  All one has to do is declare a local variable of type mpi_type_wrapper<T> (with appropriate T) and read the value of its mpi_type field.  Of course, none of this is specific to MPI in any way.  The only requirement is that an explicit instantiation of the constructor must be provided for any C++ types that are to be converted.

Why This Solution?

This solution strikes me as elegant for two reasons.  First, it is a solution that would be difficult, if not impossible, to express in many other languages.  Second, and most interesting to me, there is no run-time overhead associated with this solution.  You can even compile this with RTTI turned off.  Any reasonable compiler automatically inlines the appropriate constructor, then constant propagation replaces any uses of the mpi_type field with the appropriate MPI_* enumeration value.  There is no memory overhead associated with explicitly keeping a map at run-time, nor any time overhead of performing a map look-up.  The final code just uses the constant value!  If you do not believe me, check out this example:

/**
 * Some template class that needs to know the MPI_DataType value for its
 * template parameter type.
 */
template <typename T>
struct some_type {
  void printType() {
    mpi_type_wrapper<T> wrap;

    printf("My Type: %d", wrap.mpi_type);
  };
};

int main() {

  some_type<float>  floatClass;
  some_type<double> doubleClass;

  floatClass.printType();
  doubleClass.printType();

  return 0;
}

And the generated code?

_main:                                  ## @main
## BB#0:
	pushq	%rbx
	leaq	L_.str(%rip), %rbx
	movq	%rbx, %rdi
	xorl	%esi, %esi
	xorb	%al, %al
	callq	_printf
	movl	$1, %esi
	movq	%rbx, %rdi
	xorb	%al, %al
	callq	_printf
	xorl	%eax, %eax
	popq	%rbx
	ret

Conclusion

While this example is probably trivial for most experienced C++ programmers out there, including myself, I always find myself stopping and appreciating such solutions.  In this case, C++ templates provide such an elegant and efficient solution that I cannot help feeling giddy.