410

Here is a (pretty) little video showing the power of the new GObject-ified Firtree. Having signals as a first-class citizen in the Firtree world allows for dynamic pipeline editing as never before. In this example, the entire GUI is written in Python and uses Firtree underneath for the hard work. The rendering is done by Firtree on the CPU making use of multi-core where appropriate transparently.

If you want to see full HD version, or to download it, take a look at the ogg version or on YouTube.

An article in The Times got me thinking today. It was a moderately well researched article into the impact of DAB on resource usage and the ‘green impact’ of the decision that analogue AM/FM will be no-more for national stations by 2015.

As a summary of the article, it makes the following points:

1. “digital radios use more than four times the energy (8.5 watts) of analog [sic] (average 2 watts).”
2. When switched off “they are computers on permanent standby - like leaving a light on full-time.”

Now, we shall leave for a moment Ms Purves’ confusion between energy and power, and her inexcusable Americanism and come to the meat of these sentences. Does switching ‘off’ a DAB radio really raise it’s power usage to 60W? I think not.

It is fun to be a pedant and micro-analyse her article, which one could easily do. In the same way that getting a tasty trout for dinner using a gun and a large water butt is easy.

Let us address her main point: DAB is less green than analogue. Now there is no one measure of ‘resource’ usage. Power usage is of course one but one which can at least be amortised into ‘greener power’. A far scarcer resource (and one mandated by the laws of Physics) is bandwidth in the EM spectrum. Oil and gas may well run out in 20 years, but the EM spectrum has already been plundered as much as it is able. In terms of spectrum usage, the DAB wikipedia article performs a back-of-envelope calculation to show how DAB uses over 17 times less effective spectrum bandwidth than FM (despite the bandwidth for both being around 0.2MHz/channel).

As a wider concern, people should not focus on one resource number to measure environmental impact. There is no such number. Who is to say how many ‘resource units’, 1W of standby power is compared to 1MHz of bandwidth? It is impossible. Instead one should prioritise the scarcest resource while attempting to keep the impact on other resources as low as possible. DAB correctly optimises for the scarcest resource while allowing other resource usage to be optimised over time without impact on the system as a whole (e.g. individual unit power requirements).

Widening the scope even further, it does annoy me when the green lobby come in and attempt to micro-optimise one small area without looking at the bigger picture.

This is horrible! If anyone can find a way to toggle this option without creating a fake command line, please tell me!

rjw57@crowley:~/bzr-repo/firtree/gobject$ bzr diff -r-2..-1
=== modified file 'firtree/engines/cpu/firtree-cpu-engine.cc'
--- firtree/engines/cpu/firtree-cpu-engine.cc	2009-06-07 17:57:57 +0000
+++ firtree/engines/cpu/firtree-cpu-engine.cc	2009-06-07 19:37:17 +0000
@@ -212,6 +212,19 @@
         return NULL;
     }

+	/* Nasty, nasty hack to set an option to disable MMX *
+       * This is really horrible but is required by:       *
+       *   http://llvm.org/bugs/show_bug.cgi?id=3287       */
+	static bool set_opt = false;
+	static const char* opts[] = {
+        "progname",
+		"-disable-mmx",
+	};
+	if(!set_opt) {
+        llvm::cl::ParseCommandLineOptions(2, const_cast<char**>(opts));
+		set_opt = true;
+	}
+
     /* create an LLVM module from the bitcode in
      * _firtee_cpu_engine_render_buffer_mod */
     llvm::MemoryBuffer* mem_buf = 

From an OCaml mailing list post:

From: Jon Harrop
[ snip ]
Lennart Augustsson found that LLVM's vector intrinsics can generate broken
SSE code for 2D vectors. There is no general workaround: you are expected to
special-case this situation in all front-ends (!).

I’ve just been bitten by this as well :(.
Update: The bug report makes interesting reading.

I’ve found a weekend to do some proper hacking on the GObject API for Firtree. This has turned into a re-write of the main Firtree engine as a valuble ‘third rewrite’[1].

LLVM is a seductive beast. It promises a lot and delivers a great deal of what it promises. It has some wrinkles however. If you are using LLVM with CMake, one might well hit a lage number of "Option already exists!" assert()-s.

This is because one might assume that the output from llvm-config --libs could be used as input to target_add_libraries(). In actual fact, you get a list of .o file and .a files. The .a files need to be added as libraries and the .o files need to be added as ’source’ files.

This post exsts mostly as Google fodder since I’ve had to re-discover this workaround twice since there are few Google hits on this problem.

[1] A first-system is the first design of a system. It kick starts an entire class of systems people want. The second system is often the attempt to make an all-singing, all-dancing version of the first system (c.f MULTICS). The third-system is generally the small, sleek flexible one that only implements what people need (c.f. UNIX).

A productive morning. I added a target to run the test suite in valgrind. I then dumped some bricks. I then fixed bugs:

rjw57@vega:~/Development/repos/bzr/firtree/gobject-api$ make test-mem
==21936== Memcheck, a memory error detector.
==21936== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==21936== Using LibVEX rev 1884, a library for dynamic binary translation.
==21936== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==21936== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==21936== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==21936== For more details, rerun with: -v
==21936==
>>>> Running tests in valgrind mode <<<<
........................................................................................................
----------------------------------------------------------------------
Ran 104 tests in 14.809s

OK
==21936==
==21936== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 980 from 9)
==21936== malloc/free: in use at exit: 1,456,585 bytes in 1,464 blocks.
==21936== malloc/free: 724,611 allocs, 723,147 frees, 28,229,430 bytes allocated.
==21936== For counts of detected errors, rerun with: -v
==21936== searching for pointers to 1,464 not-freed blocks.
==21936== checked 2,196,316 bytes.
==21936==
==21936== LEAK SUMMARY:
==21936==    definitely lost: 0 bytes in 0 blocks.
==21936==      possibly lost: 0 bytes in 0 blocks.
==21936==    still reachable: 1,378,849 bytes in 1,225 blocks.
==21936==         suppressed: 77,736 bytes in 239 blocks.
==21936== Reachable blocks (those to which a pointer was found) are not shown.
==21936== To see them, rerun with: --leak-check=full --show-reachable=yes
Built target test-mem

As my previous post just made clear, I was bitten by multi-line comments in GCC. I was initially peeved that vim didn’t highlight the line as being a multi-line comment (which would have made the error obvious). It turns out that vim does highlight lines of the form:

int a; // Backslashes look like this: \
a = 7;

But not

int a; // Backslashes look like this: \[whitespace]
a = 7;

GCC 4.3, it would appear through empirical research, treats both as multi line comments. My code had the latter. Gah! Multi-fail :(. Apparently I’m not the only person to have been bitten by this.

The question is: ‘fix’ vim or ‘fix’ GCC?

Update: I suppose many people may wonder, ‘why are you not compiling with -Wall, it would’ve helped you there?’. Well my dear friends, I forgot that C flags are not the same as C++ flags in many build systems. I am having a complete fail day today!

Dear lazy web,

Update: Solved! It was indeed a stupid fail on my part :). Thanks to Simon!

The following is a bug-for-bug port of a PHP UUID generator I’ve been asked to make. GCC moans that there are too few arguments for the format string but I’m at loss to work out why. I count 12 fields and 12 arguments. I’m sure it is a stupidly obvious bug[1]. I probably fail at counting percent signs!

[1] For example, the other day at work a colleague and I spent an embarrassingly long time to spot a ‘foo && 0xff’ where there should’ve been a ‘foo & 0xff’ :).

    gchar separator; // initialised elsewhere
    // ...
    // The field names refer to RFC 4122 section 4.1.2
    snprintf(buffer, 37, "%04x%04x%c%04x%c%03x4%c%04x%c%04x%04x%04x",
            g_random_int_range(0, 65535), // \_
            g_random_int_range(0, 65535), // / `- 32 bits - time_low
            separator,
            g_random_int_range(0, 65535), // ---- 16 bits - time_mid
            separator,
            g_random_int_range(0, 4095),  // ---- leading 12 bits of time_hi_and_version
            separator,
            ((g_random_int_range(0, 65535) & ~0x0300) | 0x0100), // clk_seq_low
            separator,
            g_random_int_range(0, 65535),  // \
            g_random_int_range(0, 65535),  //  |- 48 bits - node
            g_random_int_range(0, 65535)); // /

If you make use of the greasemonkey extension for Firefox, this little user script will remove the Facebook ads that AdBlock Plus cannot reach.

// ==UserScript==
// @name           Remove FaceBook ads
// @namespace      http://l4.me.uk/
// @description    Hides the Facebook advert bar
// @include        http://facebook.com/*
// @include        http://*.facebook.com/*
// @include        https:/facebook.com/*
// @include        https://*.facebook.com/*
// ==/UserScript==

document.getElementById('sidebar_ads').style.display = 'none';
document.getElementById('home_sponsor_nile').style.display = 'none';

// vim:sw=4:ts=4:cindent:et

It only took all day but now my inbox has zero messages. Along the way I discovered the neat Google Labs ‘task list’ feature for GMail.

Being bored at home gives me time to play with the ever awesome Blender. Here is a little attempt at relatively realistic grass rendering.

I was at a practise this weekend in Oxford for our Edinburgh show. During the weekend we took some publicity photos. Here is a group shot. It only took assembling three shots into one to make one where we all looked OK :).

This post is not in Old English :).

A nice thing about having a toy path tracer is that you can play with it. Another nice thing about path tracing (and all ray tracing-like rendering methods) is that adding in reflections and panoramic cameras is generally very easy:

As a reminder, the only light in this scene is from the sky. The sky itself is a uniform emitter of white light, somewhat like a bright but overcast day.

But this post is not about panoramas or reflections, although it is nice to note that the denoiser copes correctly with non-diffuse lighting; I want to discuss ways to ‘optimize’ a path tracer.

Note the nice use of scare quotes there. In this case I don’t mean make the code faster (although that is certainly possible). Instead, I mean we want to make the code smarter.

Up until yesterday, when I was in need of something to distract my fevered brain, the path tracer repeatedly iterated over the image drawing one output sample per pixel. These samples were averaged over a number of iterations and the result outputted.

This is all fine and dandy but something of a waste. Consider the sky in the image above. Every time I fire an eye ray through a sky pixel, I’ll hit sky. And since the sky is uniform I wont get a terribly interesting result. Also this result won’t change much as I draw more samples. Surely it would be better to concentrate my efforts on the areas under the arches where more samples are required to get a meaningful output.

Of course it is easy to say this but hard to implement. How does the path tracer ‘know’ where the pixels it should concentrate on are? Aha! This is where keeping track of the sample statistics suddenly becomes useful.

We want to come up with a measure which is high when the samples we draw from a pixel differ greatly from each other — implying we need to draw a large number to get a good estimate for the mean — and low when the samples are similar.

Of course the variance (or at least relative variance when compared to the mean) gives a measure with these properties. Yesterday I modified the path tracer to, after each iteration, assign a sampling likelihood to each pixel based on it’s relative variance — those with higher relative variance were more likely to be sampled in the next iteration. I then draw a set of pixel locations to be sampled from these likelihoods and iterated.

The result? After a few iterations, there was more sampling effort being directed to the ‘dark’ areas under the arches with complex lighting and less to the more easily calculated areas.

The following image shows the sample counts per pixel, white being the most samples per pixel and black being the least. Notice how the path tracer concentrates on ‘interesting’ areas like the under arch area and areas of fine detail. The tracer quickly realises the sky and strong reflections are relatively uninteresting.

So does this speed up the renderer? Well, it depends of course on how you measure speed. It generates exactly as many samples/second as before but now the level of noise in the image is more uniform meaning that one isn’t left running iteration after iteration ‘waiting for the sodding arches to fill in’.

So, do people think abeorn andbita == ‘burning feast’ == barbecue?

Ic awilne nebboc in ealdre Englisca!

I want an Old English Facebook!