It looks like I'm not the only one who's not a fan of EA. The Consumerist really doesn't like them. Ouch.

Off-and-on for a couple years (no kidding) I've been working on a branch that compiles the assembly shaders (e.g., GL_ARB_vertex_program) to GLSL IR. I even talked about it at XDC 2011. This project has turned into such an incredible rat's nest of irritation that I can't even believe it.

All of that asside, the project reached a significant milestone today. I can run retail Doom3 binaries. There are a couple caveats (incorrect rendering, have to disable HiZ on Sandybridge, etc.), but it's still significant progress. The images below are i965 on Mesa 8.0.2 (with HiZ disabled), i965 on my branch (with HiZ disabled), and classic swrast on my branch. At least at the time of this writing, there are some bugs related to separate stencil on Sandybridge that only occur when HiZ is enabled.

I finally got around to reading some H. P. Lovecraft. I really enjoyed most of it. It was amazing to see how much his work has influenced modern sci-fi and horror. In a few of the stories I really felt like I was reading an episode of the X-Files. Most of the time the stories were more creepy than scary. Most of the time.

The notable exception was "Hunter of the Dark". To maximize the effect of these stories, I only read them in bed just before going to sleep. After reading this particular story, I went to sleep very happy. Well, not happy per-se, but I was very satisfied with how much I enjoyed the story. About 3am my cat woke me up madly scratching on the wood floor in the next room. I'm not sure if he was running around in circles or fighting some blasphemous creature from another realm. In any case, the sound woke me so suddenly that I sat straight up in bed. My heart was racing.

I looked out towards the open doorway from my bedroom. As my eyes slowly adjusted to the darkness I noticed it. Something, in the corner of the room above the doorway, shifted slightly. I waited with bated breath. There was only darkness. The thing that had moved was the shadow. After more than a minute watching, waiting, it moved no more.

Still sitting up, I closed my eyes and took a deep breath. When I opened my eyes, I smiled from ear to ear. After having read a dozen or more of Lovecraft's stories, I finally understood the joy that readers who hadn't grown up on Alien, Jaws, and The X-Files must have felt reading this work for the first time. I laid back down and slept like a baby.

Smurf com•mit [smɚf kə'mĭt]
noun

1. Commit made, usually during a long series of commits, that makes incremental changes or tweaks while developing some larger feature or performing some larger refactor. Such commits often feature commite messages such as "almost there," "will be working soon," or "not much further now."

2. Commit made by a Smurf.

Just for giggles, watch an episode of Grimm, then watch and episode of Portlandia. For more fun, take a shot of [beverage of choice] each time you see a location in one show that you saw in the other.

After planning my first LAN party in over a year, I discovered that the game I planned to play, Battlefield: Bad Company 2, intentionally does not include support for LAN-only servers. In over 15 years of hosting LAN parties, I have never encountered a game that does this.

EA made this choice, supposedtly, to curb piracy. What they have done is guarantee that I will never buy one of their products again. Ever.

Strong work.

In the wake of Occupy Portland being shut down, it's good to reflect on why it failed: 1% ruined it for 99%.

GIT is a wonderful tool. It enables some really powerful, flexible working models. There is one model that is commonly used when developing a major feature (or large refactor):

• Create a long series of patches in the order that it makes sense to develop them.

• Rebase, reorder, and merge patches into the order that it makes sense to review them.

• Post patches for review in small, easy to digest groups.

There is a danger in this process. While reordering patches it is very easy to create a tree that won't build at intermediate commits. Since the entire group of patches gets pushed at once, this may not seem like a problem. However, having intermediate commits not build makes it impossible to bisect when failures are found later.

Having every commit along a long patch series build is an absolute requirement.

However, it's kind of a pain in the ass to manually build the tree at every step. The emphasis in the previous sentence is manually. In some sense the ideal tool is something like a scripted bisect. This doesn't work, of course, because both ends of the commit sequence, in bisect terminology, are good.

To get around this in Mesa, I wrote a script that builds origin/master and every commit in some range of SHA1s. If any build fails, the script halts. At the end, it logs the change in the compiler warnings from origin/master to each commit (as I write this, it occurs to me that the warning diffs should be between sequential commits). This is useful to prevent new warnings from creeping in.

My script is available. This particular script is very specific to Mesa, but it should be easy to adapt to other projects. The script is run as:

check_all_commits.sh /path/to/source /path/to/build firstSHA..lastSHA

(Better never than late... or something...)

I had high expectations for Hiding Complexity, but I was largely disappointed. I only stayed for the first two talks. As far as I could tell, Occlusion Culling in Alan Wake summarized the combination of a bunch of known techniques for occlusion. Their combination seems to have the strong disadvantage that it has a lot of temporal instability, and this can lead to frame rate jitter. Even the bit of the talk about optimizing shadow generation seemed like a subset of the optimizations from CC Shadow Volumes. I'll have to look at their I3D paper, Shadow Caster Culling for Efficient Shadow Mapping to be sure.

Increasing Scene Complexity: Distributed Vectorized View Culling can be summarized by: we optimized a slow part of our code in all the obvious ways, and it got a lot faster. shock.

After that, I bailed and went to Compiler Techniques for Rendering (slides are also available.

I missed the first couple talks, but I did arrive in time for AnySL. They have an interesting project. It's essentially an N:M compiler. It seems like we should connect their OpenCL work with various open-source efforts that are underway. This is especially the case if their claim of beating Intel's (CPU) OpenCL compiler on almost all kernels turns out to be true.

Automatic Bounding of Shaders for Efficient Global Illumination was interesting, but I don't think it has anything directly applicable to our GLSL compiler work. However, it did give me some ideas to try for a real-time light integrator that I've been working on.

Compilation for GPU Accelerated Ray Tracing in OptiX looked mostly like their talk from SIGGRAPH last year. I didn't recall any mention of the previous RTSL work, and that paper was an interesting read. There are a couple built-in functions in that language that are useful. I've open-coded a couple of them in the past...

The final session of the conference was Real-Time Rendering Hardware.

Clipless Dual-Space Bounds for Faster Stochastic Rasterization and Decoupled Sampling for Graphics Pipelines were related pieces of work. Each was a different part of solving the automatic defocus and motion blur problem. I like the idea of having the hardware assist with these in a similar way that it helps with antialiasing. While it's trivial to expose MSAA to the developer (it's mostly transparent), it's not clear to me how to expose motion blur or, to a lesser degree, defocus blur. Given all the weird ways that people implement animation in real-time systems, how can the API directly expose a time dimension as a shader parameter?

Spark: Modular, Composable Shaders for Graphics Hardware echoes a lot of concerns that I've had for a few years. That people have to machine generate 10,000 shaders or use #define madness to specialize 10,000 variations of their shaders shows that we haven't given them a useful system. Even without that it's pretty much impossible to have separation of concerns in a shader stack. They way that OSL allows shaders to be composed solves some of this, and Spark takes a different approach.

Physically Based Real-Time Lens Flare Rendering goes in the "I should try to implement that" bin. Bastards! It was nice ending the conference with pretty pictures.

I went to Surfaces just to hear LR: Compact Connectivity Representation for Triangle Meshes. Their technique is pretty simple, and achieves really good results. Their primary insight was that a lot of mesh connectivvity can be stored implicitly by the ordering of the verticies. If all of your vertex data is a (non-indexed) strip, you get a lot of information for free. Like most mesh data structures, they only handle manifold meshes. The big disadvantage is that LR doesn't "yet" handle updates, but that's an area of planned future research.

I also tried to get over to the last bits of Mixed Grill, but I only managed to catch High-Resolution Relightable Buildings From Photographs. Their technique is really a novel combination of several known techniques. Their results are pretty impressive.

The last session before lunch was Image Processing. I was primarily interested in Antialiasing Recovery, and it was a really well given talk. You can tell that a speaker knows their audience when he starts with, "I understand that there are people like me that like to take naps during talks, so if you want to get the gist of the paper, pay attention to these parts." Strong work.

They take an image before and after some filter operation (e.g., thresholding to black and white) and try to recover antialiasing (smooth edges, really) in the prefiltered image. This is acomplished by examining both images for hard edges and doing neighbor searches and blending in the areas where new hard edges appear. On current limitation is the assumption that only two colors from a pixel's 8 neighbors contribute to the original smooth edge. They also plan to have code available on their project page in a month or so.

Local Laplacian Filters: Edge-aware Image Processing with a Laplacian Pyramid was a clever techniqe. I'll probably try to play around with it a bit. There are a few areas in real-time rendering (e.g., SSAO, some soft-shadow algorithms) where bilateral filtering is used as an edge-aware filter. Most of these are low-frequency effects where some of the noise isn't as apparent, but there may still be some benefit.

The remaining papers, Domain Transform for Edge-Aware Image and Video Processing and Non-Rigid Dense Correspondence With Applications for Image Enhancement, produce really good results, but they're both in area way outside my area of expertise.

I spent the afternoon in the expo hall and at the Animation Theater "demoscene" session. Hurray for seeing CNCD / Fairlight on the big screen. Things have come a long way since my scene days...

After that, I went to the OpenGL BoF. Hurray for OpenGL 4.2!