Tuesday, September 21, 2010

Writing Captions for Figures

Before reading a book or paper, I always browse its figures and read their captions. If it seems the content will interest me, I go back and actually read it. I suspect almost everyone does this.

Jim Kajiya makes an excellent point about this in How to Get Your SIGGRAPH Paper Rejected, which I believe applies equally to books:
Ivan Sutherland once told me that Scientific American articles are constructed so that you can get the point of the article just by reading the captions to the illustrations. Now, I'm not suggesting that you write a technical comic book; but you should take a look at those SIGGRAPH papers you were initially attracted to and see how they went about getting their point across.
Given that a reader is likely to read captions for figures before reading the main text, it is important to write good captions! A trick I use is to write the captions before writing the main text. This has worked pretty well so far. You need to be careful that you don't include too much in the caption but a little redundancy isn't bad: I like captions to reiterate a key point from the main text.

Sunday, September 12, 2010

Multithreaded Resource Preparation

I gave myself three weeks to write our chapter on multithreaded resource preparation. I manged to come in right on time even with Labor Day weekend in the mix. I am exhausted.

This is not an introduction to multithreading but rather how to apply multithreading to improve the performance and responsiveness of a 3D engine by moving I/O, CPU intensive algorithms (think triangulation, vertex cache optimization, etc), and renderer resource creation to worker threads.

The chapter highlights include:
  • Brief review of hardware parallelism
    • CPU: Pipelining, superscalar, SIMD, multithreading, Hyper-Threading, multi-core.
    • GPU: Pipelining, shaders, CPU/GPU parallelism.
  • Architectures for multithreaded resource preparation
    • Using message queues to communicate between threads [code contributed by Kevin Ring].
    • Coarse grain threads [code].
    • Pipeline of fine grain threads.
  • Multithreading with OpenGL
    • One GL thread, multiple worker threads.
    • Multiple threads, one context.
    • Multiple threads, multiple contexts.
      • Shared contexts.
      • CPU vs GL synchronization. Fences [code].
Also, here's a list of resources on OpenGL multithreading that I found useful:

Wednesday, September 1, 2010

Proofreading your own Writing

Proofreading our own writing is hard because, well, we wrote it. We tend to read what we think we wrote and not what we actually wrote.

When I first write something, it usually isn't that great. That doesn't worry me, I want to get ideas down and avoid staring at a blank screen. I write a few pages, create a pdf, proofread it, and immediately rewrite the parts I don't like or that have blatant grammar errors.

This type of proofreading isn't enough though.

The next day I work on the book, I reread what I wrote the previous day, hopefully after forgetting most of it. I'm able to improve the quality to the point where I'm not ashamed, or perhaps even proud, to show it to reviewers.

This second proofreading also helps me get back into the zone for writing the next section and helps each section flow into the next one. I find getting into the zone for writing much hard than getting into the zone for coding so I feel this trick goes a long way.

I always proofread my previous day's work before writing. Sometimes, I even proofread previous work from a few days. By the time I "finish" a chapter, I've probably read it five times - and reviewers still find things!