Skip to main content

Regular posting schedule

A short behind-the-scenes look at blogging. I know that the key for a successful blog is a more or less reliable post schedule. As you can well see, I'm quite far away from that :) While I was trying to get one running at one point, with one blog post per week, I have quickly abandoned this again, because the main reason for running this blog is to write when there is something to write about, and this is more complicated than it sounds.

For quite a few topics, I want to write about, but I don't have the time right now to cover the topics with sufficient detail. For example, I would love to write a longer article on SSE optimization, but I estimate that it will probably take me around one work day to prepare it -- time which I don't have at the moment.

The other things are topics which are interesting, but where I don't feel like I should already blog, because my knowledge in that particular area is not big enough. For example, a topic here would be triangle rasterization. While I have written a few rasterizers so far, I consider none of them good enough to write a good blog post which covers the topic adequately.

What I have in the pipe now are a few posts, which I hope to push out in May -- about stuff I'm currently working with, and about the life as a developer in general. This is something I increasingly start to care about, how the life of a developer is supposed to be. What are the things we should strive to achieve? How can we make sure that we love what we do? Things like these are becoming more important, as I meet more and more developers, and unfortunately I didn't have the chance yet to meet someone who has answers for these questions, like Carmack. (Note: Well, I did meet someone who must know it as well -- Matt Pharr. I didn't have too much time to speak with him though, but he surely is also one of the programming heroes).

So stay tuned, and if you want to read about a specific topic, feel free to drop me a line! I'm also happy to hear your feedback.

Boost 1.39 has been released, and CMake 2.6.4 is out as well

Quite a few things going on ;) First of all, CMake 2.6.4 has been released, with a bunch of bugfixes. Just tried it, no problems so far. The other major new release is Boost 1.39, which is now fully in the 3-month release cycle. In my opinion, this is the best thing that could happen for Boost, as we -- the users -- can be sure that a fixed bug will be pushed out no later than in 3 months. It adds the header-only, thread-safe signals2 library, which I'm going to try out really soon. The build system has not been changed, so you can still use my old build instructions to get a customized x86 & x64 build.

Development machines

The quest for the perfect developer PC is a long one. So far, I didn't manage to find a machine at work which is really optimal for development. Let's take a look at my current one, and the associated problems. It has a dual-dual Xeon at 3.00 GHz, with 8 GiB of RAM - this is no problem, though I would have been more happy with having a dual-quad running at 2.5 GHz. The issue with multithreading is, that either your app is indeed properly multithreaded, and then you can scale to many cores, or it isn't, in which case you're better of with a high-clocked dual core.

Ideally, you would have a dual-core running at 3.5 GHz in one socket, and six 2 GHz cores in the other, with some OS support to pin a thread to the "serial" or the "parallel" processor. Actually, it's my firm believe that we will eventually end up with such architectures, where you have a few large out-of-order cores, and a bunch of simpler in-order-cores, which all support the exactly same instruction set (so from the developer perspective, there is no difference except for speed). Whatever the future architectures will actually look like, for a developer today broad parallelism is a must have.

What's good is that the machine has 2 GiB of RAM per core, which allows for some heavy-duty computing. The worst you can have is something like 8 cores and 4 GiB of RAM, because for any reasonably parallel application, you'll be quickly running out of private, that is, per core, memory.

The graphics card is a pretty nice GTX 280. Right now, I'm far away from doing any serious graphics development, and the card is more than sufficient. Just to give you an idea, the scenes I'm drawing consist of 20k triangles or so, and maybe 50 MiB of textures, while the card is able to run Crysis at 1920x1200 with maxed out settings smoothly, pushing something in the order of 1 million polygons per frame. However, for heavy-duty graphics development, I would like to have something in the range of a GTX 295 in it, for two reasons. First of all, you can prototype faster, as you can skip crucial optimizations and get things running quickly. Second, for GPGPU, it's the same as with the CPU core count for normal multithreading. Having more to see scalability issues early is crucial, especially while developing.

No matter how good the graphics card is, it can be worth nothing without a good screen setup. In my case, I have a 24" and a 20" display on my desktop side-by-side. It's ok, but I'm not happy with the 24" screen. I have a 22" at home, which is more or less perfect for me, and the pixel density difference between a 22" at 1680x1050 and a 24" at 1920x1200 is pretty small, but I still have problems to put a 24" screen at a distance where I can both read from it without problems, and not getting a headache from it.

The major problem with the screens though is the colour reproduction. The 24" is slightly yellow, while the 20" is more or less neutral. On their own, they would be perfectly fine, but next to each other, it's simply annoying if you move a window over and the colours change visibly. I may be biased here, having seen Eizo screens. Anyway, a setup with two visibly different screens is nothing I can recommend. If you can, spend the extra money to get screens which reproduce colours truthfully.

What's the perfect development machine for you? I'm really curious what points are important for you, and what experiences you have made. I haven't touched topics like fast hard disks, because I've yet to see a machine which fast enough drives to make a difference, so I'm really interested in your opinion here. Feel free to comment!

[Update] Just found something on SSDs for compiling, on "Joel on Software" -- doesn't look too promising. Makes me wonder whether a fast disk drive makes any difference at all, if you have plenty of RAM. Anyway, I'm surprised, because compiling seem to be a task which stresses small random reads/writes the most, which looks like a perfect match for SSDs.

Updating a DXTC texture with DX10

Updating a texture is usually straightforward: You call map, and mem-copy the stuff over the returned pointer, taking the stride into account. This is not so simple for DXTC though, as the data is organised in 4x4 pixels blocks.

With DX10, you have to copy one row of blocks before adding the row-pitch, even though the documentation states that the pitch is the number of bytes in a block:

RowPitch is the number of bytes in a block of 4x4 texels

This is not true, it's rather the number of bytes you have to skip after copying one row of blocks. Hope this helps you to save some time, I've been scratching my head for two hours yesterday, and I can tell you that even with Pix, debugging DXTC related problems is no fun, because you usually wind up with large randomly-colour texture areas with no clues where the problem appeared.

More information on Caustic Graphics

Caustic graphics is a company which claims to have solved most problems related to incoherent memory access when ray-tracing secondary rays (gosh, that's a sentence, but the claim is even more impressive). While nobody knows so far how they do it, PC Perspective has released an article which explains a bit more what they do. Interesting read, even though I have doubts that this is really the future (which I see in hybrid ray-tracing algorithms, where the ray-tracing is part of the shader execution -- and primary rays are still handled by rasterization).