Today’s accelerators are not there yet. The tools are not ready yet (code translators) and usual programming practices may not be adequate. All the ecosystem will evolve, accelerators will change (GPUs are the main trend, but they will be different in a few years), so what you will do today needs to be shaped with these changes in mind. How is it possible to do so? Is it even possible?

Available code translators

Code translators are the easiest path to solution. I know two of them.

The first is the PGI compiler. It only supports CUDA and the Fortran and C99 language. I didn’t use it yet, also I plan of testing it in the near future. It is based on pragmas, and the compiler generates the CUDA microcode.

The second solution is HMPP. It supports more than just CUDA (also CAL/IL or OpenCL) and Fortran/C (also Java now). As the PGI compiler, it is based on pragmas, and a excellent thing is that it detects the available accelerators and launches the correct kernel (if you authorized it) or the original code. You can also modify the generated code to put your own (you can tune the code for instance, which may give you an additional x2 factor). Unfortunately, it is not possible to call functions inside the parallelized kernels, which means that only simple or badly-written (too many lines or duplicated code) kernels can be called. I think this is the same for the PGI compiler.

It seems that code translators still need work:

• only few accelerators are supported (CUDA, and sometimes CAL/IL or OpenCL),
• almost no langage (Fortran/C/Java, a lot of Virtual Machines should be able to use them natively, without developers using specific tools),
• only one function can be parallelized at a time.

The last point is currently the biggest issue. You need to cut your function int pieces to have clean code and a good portability/evolutivity for the future.

This is why one still need to program a lot for those accelerators, and so we need to adapt our programming practices, develop in the accelerators’ native langages (even if we know that they may disappear in a few years).

Developping your own “tool chain” for accelerators

For accelerators, there are a lot of things that needs to be done each time: copying some data, computing and getting some data back. These are the steps that code translators automate, in fact it is a common practice to use tools to automate stuff. The issue is that complex kernels are not supported by those translators. So what?

Creating automatic functions that will copy the data you need is in fact very common in metaprogramming. Coding the kernel on an accelerator is in fact not that difficult: the manufacturers provide the needed compilers (that’s what nVidia does and the success of the tool chain cannot be denied), and this is really the cornerstone. One has to write more code, some parts are less portable (because they are written in one of the accelerator’s languages), but in the end, with metaprogramming, the code can be better tuned, enhanced and read. This is the leverage of the accelerators.

Conclusion

Why do we care developing for accelerators? We know that they will go away. Before they do, they are the only way of speeding up our software. Code translators are the best tools to develop in a portable way, but they need time to support more accelerators, languages and method of programming. When CPUs will be on a par with accelerators, their progress will help compilers to target them correctly. It’s just a matter of time.
Meanwhile, metaprogrammin is the next best solution to automate processes that code translators cannot support yet.

Content and opinions

The book starts with two chapers on what actions to take before parallelizing and what can and what cannot. Before the usual algorithms that can be parallelized, the author takes three chapters to explain how you may achieve your goal. Ensuring correctness is a difficult task, so the book gives 8 rules to help and then an explanation of several support libraries that can be used.

The biggest part of the book, as I’ve hinted, is dedicated to simple but usual algorithms that may be parallelized: sums and scans, mapreduce, sorts, searches, and graph algorithms. Each time, several different algorithms are first coded in a serial way and then parallelized with possibly different support libraries. Also each time, the efficiency, the simplicity, the portability and the scalability conclude the sub art: it helps standing back.

The last chapter is a small overview of the additional tools that you may use (but they are not mandatory). They are mainly Intel’s tools, but it’s mainly because Intel provides the developer with some of the best tools.

Conclusion

Although the author works for Intel, he doesn’t expose Intel tools more than others. The book tone is adequate, not too much serious, not like a “For Dummies”, so just enjoyable.

If you need advices to parallelize your applications and you don’t want to buy Patterns for Parallel Programming, buy this one (well, buy it anyway).

The Art of Concurrency: A Thread Monkey’s Guide to Writing Parallel Applications
Price: $40.49

The Art of Concurrency: A Thread Monkey’s Guide to Writing Parallel Applications (Paperback)
by Clay Breshears
ISBN: 0596521537

Price: USD 38.48
40 used & new available from USD 17.99

| 3.5 | 6

I’ve searched if someone has already used this new version to create a VST plugin. The only blog post I’ve found does not use the Qt Solution and is not perfect. According to the documentation what is missing in this solution is precisely what the Solution should do. So let’s try it.

So I’ve download the 2.4 VST SDK as well as Qt 4.5 and the WinMigrate Solution. As I’ll be using Qt with signals and slots, I used SCons to build my small plugin.

Designing the interface and testing it

The interface is really simple: a label with a name, the value of the gain and a slider. Here is what it looks like in Tracktion 3:

The slider takes values from 0 to 99, value that will be displayed in a label. This will be the gain factor in percentage.

Nothing fancy here with the class header:

class QVstPanel : public QWinWidget
{
  HWND h_parent;
  AudioEffectX *again;
 
  QLabel *valueLabel;
  QSlider *slider;
public:
  QVstPanel(AudioEffectX *again, HWND h_parent = NULL);
};

The panel is created with a link to the actual audio effect (needed in the future) and the parent HWND given by the host.

The actual code is even simplier:

QVstPanel::QVstPanel(AudioEffectX *again, HWND h_parent)
:QWinWidget(h_parent, NULL), again(again), h_parent(h_parent)
{
  setAttribute(Qt::WA_DeleteOnClose);
 
  QLabel *label = new QLabel("Gain", this);
  valueLabel = new QLabel("0", this);
  slider = new QSlider(Qt::Horizontal, this);
  QHBoxLayout *layout = new QHBoxLayout(this);
  layout->addWidget(label);
  layout->addWidget(valueLabel);
  layout->addWidget(slider);
  setLayout(layout);
}

Now this is the class that will be opened by the VST editor this way:

class QtAGain : public AEffEditor
{
  QWinWidget* widget;
  AudioEffectX* effect;
 
public:
  QtAGain(AudioEffectX* effect)
    :widget(NULL), effect(effect)
  {
  }
 
  ~QtAGain()
  {
  }
 
  bool open(void* ptr);
  void close();
};

bool QtAGain::open(void* ptr)
{
  AEffEditor::open (ptr);
  widget = new QVstPanel(effect, static_cast<HWND>(ptr));
  widget->move( 0, 0 );
  widget->adjustSize();
  widget->setMinimumSize(widget->size());
  widget->show();
 
  return true;
}
 
void QtAGain::close()
{
  delete widget;
}

Now, in AGain’s constructor, I can add my custom editor:

  QtAGain* again = new QtAGain(this);
  setEditor(again);

So there isn’t anything really fancy, it kind of works out of the box. Unfortunately, it doesn’t work as well as in T3 in every host. I cannot resize the window VSTHost gives to the open() method, even if I tested it with almost all solutions I’ve found on MSDN.

Adding interactivity

Now, I will eventually use the power of Qt. The QtAGain class will be a QObject, as will be the AGain effect. This way, I can connect signals from the GUI to the effect when a parameter is modified by the user, and vice-versa, the UI will be updated when the effect sees a parameter change (indicated by the host for instance).

So I add a connection inside the QVstPanel constructor to a new slot that will update the underlying effect:

connect(slider, SIGNAL(sliderMoved(int)), this, SLOT(update(int)));
 
void QVstPanel::update(int value)
{
  valueLabel->setText(QString::number(value));
  again->setParameter(0, value / 100.);
}

The trouble arises from the effect: what should I do if the effect gets a setParameter that didn’t come from the UI? If there is no UI, everything is fine though. So I will add a signal inside QtAgain, the editor, that will forward a signal emitted by AGain only if the UI is up.

void AGain::setParameter (VstInt32 index, float value)
{
  fGain = value;
  emit update(value);
}

So now, the signal that the UI will get is a float, so I can reuse the name update() for my slot:

void QVstPanel::update(float value)
{
  int intValue = value * 100;
  valueLabel->setText(QString::number(intValue));
  slider->setValue(intValue);  
}

Of course, you will have several parameters inside your VST plugin, I suggest you use the editor instance to the mapping between the effect and the different slots you may have inside your UI.

Conclusion

Although I couldn’t get it to work with VSTHost (the host widget is not resized), I think the QWinWidget is a good class to help developing Qt VST plugins. I may want to use this skeletton to test some digital effects with a cool UI.

If you have a solution to make VSTHost work, I’m all ears.

The code is available on Launchpad.

Reflection rays

Each object can reflect a ray more or less from a different object. A mirror would reflect the light totally, and a matte object would reflect nothing. Each new reflection is a new ray tracing call, so it can be costly. The number of recursion levels will be fixed, even if an object reflects nothing: this will be implemented through shaders in the future.

Knowing the normal to the intersection point, the reflected ray can be computing: it’s just the symmetric ray of the incident ray.

Some elements will be stored in a material structure that will be used to compute the reflected color:

/// Caracteristics of the primitive at a given point
struct MaterialPoint
{
  /// Normale at the intersection point
  Normal3df normal;
};

In the past, I’ve used this structure to contain diffuse or reflection colors, but usually, an object has not mirror property in red and matte in green, so this was deleted.

Now, I need to update the raytracer:

void Raytracer::computeColor(const Ray& ray, Color& color, unsigned int level) const
{
  float dist;
  long index = scene->getFirstCollision(ray, dist);
  if(index < 0)
    return;
 
  Primitive* primitive = scene->getPrimitive(index);
  MaterialPoint caracteristics;
  primitive->computeColorNormal(ray, dist, caracteristics);
  color = scene->computeColor(ray.origin() + dist * ray.direction(), caracteristics, primitive);
 
  if(level < levels)
  {
    Ray ray_sec(ray.origin() + dist * ray.direction(), ray.direction() - (ray.direction() * caracteristics.normal) * 2 * caracteristics.normal);
    ray_sec.direction() *= 1./(sqrt(norm2(ray_sec.direction())));
    Color color_sec(0.);
    computeColor(ray_sec, color_sec, level+1);
    color += mult(color_sec, caracteristics.reflect);
  }

I need to update the original collision method. Contrary to the last post, it isn’t enough to test if one primitive is hit by a ray, but I still need to test if the retrieved intersection isn’t too close to the original object. Indeed, I could be testing the intersection with the current object because of numerical instabilities. So I’ve added a minimum distance test:

long SimpleScene::getFirstCollision(const Ray& ray, float& dist)
{
  float min_dist = std::numeric_limits<float>::max();
  long min_primitive = -1;
 
  for(std::vector<Primitive*>::const_iterator it = primitives.begin(); it != primitives.end(); ++it)
  {
    float dist;
    bool test = (*it)->intersect(ray, dist);
 
    if(test && (0.0001f < dist) && (dist < min_dist))
    {
      min_primitive = it - primitives.begin();
      min_dist = dist;
    }
  }
 
  if(min_primitive == -1)
    return -1;
  else
  {
    dist = min_dist;
    return min_primitive;
  }
}

Now, when a ray hits a primitive, a material structure is used to get the normal and the other parameters at the intersection point.

The level parameter indicates the recursion level we are at. If the level isn’t high enough, the symmetric ray is cast and the reflected color is used to add the color of the object. I do not test if the contribution is too small, it is possible in some implementations, but not here. Also, adding more recursion is not always costly, as after a while, all rays point outside the scene.

Result

Now, this is the result with 3 recursion levels and 3 lights:

Test on parallelizing a custom library

I’ve decided to test Advisor Lite on my Interactive Raytracer. This is a test to verify if Advisor Lite finds the adequate parallelization and the memory sharing issues. It is a simple raytracer, so it can be parallelized for each pixel in the image. The only memory sharing issue that I know of is in the kd-tree ray traversal.

Profiling the library

First, I will profile the library. For the complete Advisor Lite workflow, I have to use Intel Compiler, and as it is faster than Microsoft’s compiler, I will use the timeit_image.py script instead of the measure_image.py I’ve used when profiling with Valgrind or Visual Studio.

Amplifier can show the results in a bottom-up or in a top-down manner. Unfortunately, you only have the exclusive timing that is displayed. In my case, when displaying bottom-up results, the method getEntryExitDistances() is the most costly one. In the top-down view, unfortunately, I can’t have a simple tree, as it can be seen in the following view:

In Visual Studio, I have the same results – more or less -, but with a correct top-down call-tree:

The method getEntryExitDistances() cannot be parallelized: it is recursively called, several times per pixel, which would lead to a lot of memory contention. The simpler task is thus to parallelized the pixel rendering, a perfect data-parallel problem.

Annotation of the code

OK, now I can annotate my code. I had to dig inside the help for this, as it was not mentionned in the Starting Guide that Intel provides a header, annotate.h, which mimics the issues you may encounter in a multithreaded application.

So you need to read at least once the online help so that you know the available annotation macros, how you can get them and how they will retrieve what you need. Once the code is annotated, it must be recompiled and then the sharing issues can be detected.

Detection of sharing issues

As expected, Inspector detected errors in the kd-tree traversal:

The solution in this case is to have a ray-traversal stack per thread, which will have to be implemented in whichever parallel library will be chosen, or simply to put the stack in the actual traversal algorithm and not in the instance.

Using TBB

I’ve decided to go for Thread Building Blocks, as it was already used for game development. This seemed to me a good idea, as it is a Open Source solution. So now, I will split the screen in 2D pieces, and add a thread-specific storage in the kd-tree class. Of course, I will have to add a flag to disable this paralellization if TBB is not available.

The actual parallelization will be in a future post in the Interactive Raytracer category. It is pretty straightforward once I had the different elements Parallel Studio gave me.

Conclusion

In fact Advisor is mainly the annotate.h header, as you have to know your program to put the macros at correct locations. The parallelization must be done by hand, as well as correcting the memory sharing issues.

The only problem I had is that annotate.h includes window.h. This header is not C++ compliant and declares some macros as max() (in fact I got the same issue with TBB headers!). As I use a max() function declared in std::numerical_limits, I had to explicitely undefine this macro.

Safe from this, Advisor Lite is a good plugin, and I’m looking forward to seeing Advisor in a next Parallel Studio release.

Content and opinions

Everything on the STL can be found in this book. Every algorithm is explained with details, almost every function of every container, with their features, qualities and defaults. In fact, there are so many things in the STL that one cannot know every detail without studying it in depth. And this is where Meyers shines: the book helps learning this fastly!

Besides the STL, the old non standard containers (hashmap for instance) are also covered, although C++0x changed them, so these items can be bypassed.

Conclusion

Even more useful than Effective C++, the tips provided in this book can be forgot easilly, so you need to come back to it regularly. If you use the STL (which you must if you’re a C++ developer), you must have a copy of Effective STL.

Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library (Addison-Wesley Professional Computing Series)
Price: $32.25

Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library (Paperback)
by Scott Meyers
ISBN: 0201749629

Price: USD 40.55
46 used & new available from USD 27.50

| 4.5 | 38