idr's blog - archive

Portland is... ?

2012-01-10T02:19:51Z

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.

No LAN-only servers? You're kidding, right?

2011-12-16T20:45:06Z

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.

Occupy Portland

2011-11-14T18:13:43Z

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

No build breaks!

2011-10-27T03:02:12Z

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

SIGGRAPH 2011: Day 4

2011-08-18T17:43:21Z

(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.

SIGGRAPH 2011: Day 3

2011-08-12T17:11:49Z

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!

SIGGRAPH 2011: Day 2

2011-08-10T16:38:28Z

I started the day with Out of Core, but I missed Google Body: 3D Human Anatomy in the Browser.

Over the last few years there have been a lot of papers about real-time global illumination. They always start with two caveats: no specular and one bounce. Interactive Indirect Illumination Using Voxel Cone Tracing breaks the mold and goes for two bounces! Hurray! They can also handle long-range indirect illumination better than LPVs, and it runs slightly faster. Based on their 2009 GigaVoxels work.

Out-of-core Raytracing was really hard to listen to. A big chunk of his presentation was a video of animated slides. Bad presenter, no biscuit! Even more frustrating is that the bulk of the presentation focused on the performance of his very limited raytracer. The raytracer can handle a lot of polygons, but it can't do shaders, textures, etc. When asked, he said, "Right now shading is not implemented in this project." Performance comparisons with other (more capable) raytracers are just not interesting.

What was interesting is the paging structure that he developed to make it work. The fundamental problem with GPU raytracing is that interesting scenes are multiple gigabytes, and GPUs can't handle that much data in a single batch. To over come this he developed a novel way of breaking the scene data into pages and determining which rays needed which pages. That was the interesting part, but he only spent a few scant minutes talking about it.

After that, I headed over to Stochastic Rendering & Visibility.

High-Quality Spatio-Temporal Rendering using Semi-Analytical Visibility is obviously not targeted at real-time rendering, but it seems like some aspects could be adapted. One of my favorite things about this presentation was the rich list of areas for future research.

Both Frequency Analysis and Sheared Filtering for Shadow Light Fields of Complex Occluders and Temporal Light Field Reconstruction for Rendering Distribution Effects assumed a lot of background knowledge that I don't have. In particular, all the bits about the Fourier analysis of occluder depths (which was a pretty key element!) was completely lost on me. I did find the medium frequency artifacts in the former paper interesting. Who gets medium frequency noise?!? It's always either high frequency or low frequency. I also appreciated the background material at the start of the later presentation. I'll probably harvest some of that for my VGP sequence.

The Area Perspective Transform: A Homogeneous Transform for Efficient In-Volume Queries was an interesting idea that seems to obvious to work. It takes a bunch of math operations to intersect a frustum with a bounding volume, but it's cheap to intersect an AABB with another bounding volume. Their solution? Project the points of the base (the big part) of the frustum to inifinit so that the lines become parallel (in the limit). I still need to read the paper to get all the details.

There were only a couple of papers that I paid attention to in By-Example Image Synthesis.

Techniques like Image-Guided Weathering: A New Approach Applied to Flow Phenomena are increasingly important in games. They take some examplar images to generate parameters for a particle simulation, then they use those parameters to generate new images. What's cool about this is that almost all of the computation is done to "reverse engineer" the original image. It ought to be possible to use that data (with some perturbation of the parameters) to generate new images each time the game is run. This is another one that goes on my "to implement" list.

I was really stoked about Discrete Element Textures. One of the authors, Li-Yi Wei, presented one of my favorite SIGGRAPH papers. This is "another" exemplar-based texture synthesis algorithm. Like some of the previous work they treat elements in the exemplar as units. This prevents the old artifacts of getting half a of a pebble, for example, in your gravel texture. I haven't read all of other previous work, but I thought it was pretty cool that their work also applies to 3D objects. The piles of carrots and plates of spaghetti were pretty cool.

SIGGRAPH 2011: Day 1

2011-08-09T22:09:30Z

I started the day with Advances in Real-Time Rendering in Games. I found it interesting that Halo Reach uses "state mirroring" to communicate updated world state from the simulation process to the rendering process. They're essentially treating the cores in the Xbox 360 as a distributed system rather than an SMP. This echos what Matteson et. al. found while developing the Single-Chip Cloud Computer.

The Cars 2 talk started the long train of "we do annoying stuff to work around the limitations of console GPUs." In particular, a large portion of their stereo rendering algorithm was implemented on the SPUs because the RSX cannot do scattered writes. It seems like at least the generation of the item buffer, which is the mapping of points the reference image to one of the stereo pairs, could be done on the RSX. Of course, OpenGL 4.x class GPUs can do this. It would be interesting to recast their algorithm using GL_ARB_shader_image_load_store (Note: DX people will know this as unordered access views / UAVs).

The Little Big Planet 2 talk was pretty cute. Their voxel algo rithm for doing AO in world space (instead of screen space) was clever and produces really good results. Generating one blob of expensive data and using it for a lot of things usually means you're winning. I'll also have to add mention to my VGP353 lectures that both LBP1 and LBP2 use variance shadow maps.

The CryEngine 3 talk moved really fast and spent a lot of time switching between speakers. It was hard to get much out of it. However, I did get a couple notes for things we need to make better in our driver.

They showed a bit of HLSL code:

float4 HPos = (vStoWBiasZ + (vStoWBiasX * Vpos.x) + (vStoWBiasY * Vpos.y)) *
    fSceneDepth;
HPos += vCamPos.xyzw;

The initial calculation of HPos should be implemented as a single DP2A instruction on architectures that can do that:

DP2A    HPos, Vpos, vStoWBias, vStoWBiasZ;

We can't do that with our current compiler, and it would take a lot of work to do so. One thing that we would have to do is notice that two independent float variables need to be packed into a single vec2. Doing that packing could have repercussions elsewhere in the code. This is where tree matching code generators that use dynamic programming and cost functions really shine.

They CryTek guys also complained about the high latency for frame read back (up to 4 frames) on desktop GPUs. They want to do CPU processing on the depth buffer from a previously rendered frame to do approximate visibility calculations for later frames. On consoles, there's only a single frame of lag.

They also mentioned that they have used cascaded shadow maps since Crysis 1.

I ducked out of Advances in Real-Time Rendering in Games part way through to go to Drawing, Painting, and Stylization. I caught just the tail end of A Programmable System for Artist Directed Volumetric Lighting, and I wish I had seen the rest of it.

I actually went to that session to see Coherent Noise for Non-Photorealistic Rendering, and I was quite pleased. There are two main problems with applying noise to NPR. Using 3D noise depends on depth, so the frequency of noise applied to object (e.g., to make lines wavy) depends on the how far away from the camera it is. Using 2D noise gives what the authors called the "shower door effect." That is also fail.

They really want three things:

cheap to compute
noise moves with objects
uniform spectrum in screen space

The algorithm that they developed accomplishes these goals. Throughout the presentation, they showed a bit of UP! with Russel hanging from the garden hoses below the house. With their NPR noise applied as the "texture," the still image just looked like white noise. As soon as the animation began, all of the structure of the image magically appeared. It was pretty cool. I'll need to implement it and make some piglit test cases.

The final session of the day was Tiles and Textures and Faces Oh My!

I enjoyed the Procedural Mosaic Arrangement In "Rio" talk. It felt like their system was perhaps a little over complicated, but that complexity may give it more flexibility for reuse. Not only was the technique used for the mosaic sidewalks in Copacabana but also for "plain" cobblestone streets. I would like to have heard more about that. This is something that everybody does in games, and everybody does it poorly.

There were some bits of Generating Displacement from Normal Maps for Use in 3D Games that I didn't fully grok. Their initial attempt was to reverse the derivative approximation used to generate the normals and propagate the new offsets around. It seems obvious that this wouldn't work. They moved on from that to a polar coordinate integration scheme that wasn't communicated very well by the presentation. I'll have to read the paper and think about it some more.

I first heard about Ptex at the "open-source in production" panel last year. At the time, I had thought that you could implement them in a fairly straightforward way on a GPU. Per-Face Texture Mapping for Real-Time Rendering follows pretty much what I was thinking, but there are some differences.

To maintain some batching, all surfaces with textures of the same aspect ratio are grouped. Textures of a particular aspect ratio are stored in a series of non-mipmapped texture arrays. Each texture array corresponds to a particular mipmap size for that aspect ratio. That is, all of the 512x512 mipmaps are in one texture array, all of the 256x256 mipmaps are in another, etc. When a texture is sampled, the texture is selected (texture array index), the LODs are calculated (the arrays), everything is sampled, and the intermipmap blending is done. This is all open-coded in the shader (via ptex function).

Having this goofy organization means that a texture with a 64x64 base level doesn't waste a bunch of space when it's batched with a texture with a 2048x2048 base level. It's the classing time vs. space trade-off.

Um, duh

2011-06-14T19:09:31Z

After seeing her wonderful display of US history knowledge, I have decided to replace the words "retard" and "retarded" in my vocabulary with "Palin." Imagine:

"That is the most Palin thing I've ever heard anyone say."
"Did you see that guy's driving? Is he a Palin or something?"
"Hey you bully! Don't pick on those Palin kids!"

Well, maybe not the last one...

ud-chains coming to GLSL compiler near you...

2011-05-04T00:10:58Z

I finally started working on ud-chains for Mesa's GLSL compiler. I'm continually amazed that it works as well as it does without them. There are so many ugly hacks and so much ad hoc data-flow analysis that I just couldn't put it off any longer. If you want to cry, take a look at how reaching definitions are determined in loop_analysis.cpp. It's pretty horrible.

My primary goal is to get enough infrastructure in place to fix that code. In addition to the ugliness, it fails on cases like:

void main()
{
    int n = 3;
    int i = 0;

    if (b)
        some_function();

    while (i < n) {
        some_other_function();
    }
}

The loop analyzer will have no idea what the values of i or n are. There are similar issues with identifying values that are constant across all iterations of the loop. In this case, flow control inside the loop confuses the analyzer.

The first step to this project is to get real basic block tracking. We have a mechanism to iterate over instructions as basic blocks (see ir_basic_block.cpp, but nothing is stored about the blocks. This means we don't know which blocks can transfer control to which other blocks.

I now have some code that creates a the basic block structure of a function. The next step will be to process the instructions in the basic blocks to track the (value) definitions within the block.

In the mean time, I modified the stand-alone compiler to optionally dump a graph of the basic blocks in dot. The results, even for small shaders, are shockingly cool.

Here's the code for the piglit test glsl-fs-vec4-indexing-temp-dst-in-nested-loop-combined.shader_test:

uniform float one;
uniform int count1, count2;
uniform vec4 red;

void main()
{
    vec4 array[11];
    array[0] = vec4(0.1, 0,   0,   0) * one;
    array[1] = vec4(0,   0.1, 0,   0) * one;
    array[2] = vec4(0,   0,   0.1, 0) * one;
    array[3] = vec4(0,   0.1, 0,   0) * one;
    array[4] = vec4(0,   0  , 0.1, 0) * one;
    array[5] = vec4(0,   0,   0.1, 0) * one;
    array[6] = vec4(0.1, 0,   0,   0) * one;
    array[7] = vec4(0,   0.1, 0,   0) * one;
    array[8] = vec4(0,   0.1, 0.1, 0) * one;
    array[9] = vec4(0.1, 0.1, 0,   0) * one;
    array[10] = vec4(0.1, 0,   0.1, 0) * one;
    for (int i = 0; i < count1; i++)
        for (int j = 0; j < count2; j++)
            array[i*3+j] += red*float(j+1);
    gl_FragColor = array[0] + array[1] + array[2] + array[3] + array[4] +
        array[5] + array[6] + array[7] + array[8] + array[9] + array[10];
}

And here is the resulting basic block graph:

Linux native games?

2011-05-04T00:12:24Z

I was talking to Linus and others at Intel's Open Source Technology Summit last week, and it occured to me that I have completely lost touch with what's available for commercial games that run native on Linux. The last native game that I bought / played was Enemy Territory: Quake Wars. That was a long time ago.

I know that OilRush has recently become available, and I think a few other Unigen based games are coming soon-ish.

What else is there?

More importantly, what else is there that I can add to an automated test suite for my driver? The easily scriptable timedemo feature of the old Quake3 engine games was the best.

They must have cheated again

2011-01-25T18:22:23Z

The list of nominees for the 83rd Academy Awards was just posted. Somehow TRON: Legacy isn't on the list for Visual Effects. It's like 1983 all over again...and what a shitty year that was! It is nominated for Sound Editing, but WTF?

My predictions (which I had meant to post weeks ago) were:

I haven't seen Narnia, but that series has gotten Visual Effects nominations in the past.

The actual list is:

3 out of 5 isn't too bad, I guess. I haven't seen Hereafter, and I wasn't that impressed with Iron Man 2. meh.

I think the winner will be either Inception or Harry Potter. I think Inception deserves it, but it may be cursed by having too many other nominations. It seems like the Academy tends to vote for movies with only a few nominations (HP has 2 vs 8 for Inception) in this category.

@override

2010-08-18T20:56:34Z

After bashing Java so brutally, I have to add another thing to the list of Java features that I wish C++ (or even just a GCC extension) had: @override notation. Imagine this scenario...

You have a base class that implements a bunch of methods, and some of the methods have numerous overloads. We'll call this class base.

You have a bunch of classes that derive from base. Each of the derived classes only override some of the methods provided by base.

These derived classes are used by other infrastructure that just takes pointers to objects of type base.

For example:

class base {
    virtual void do_something(float x);
    virtual void do_something(int x);
    virtual void do_something(char *str);
};

class d1 : public base {
    virtual void do_something(float x);
};

class d2 : public base {
    virtual void do_something(int x);
};

class d3 : public base {
    virtual void do_something(char *str);
};

Everyone with me so far? Sound like every large C++ you've ever seen? Good.

Now the signature of some of the methods in base changes, perhaps by adding a parameter. While making that change, n-1 of the derived classes are correctly modified.

class base {
    virtual void do_something(float x, int y);
    virtual void do_something(int x, int y);
    virtual void do_something(char *str, int y);
};

class d1 : public base {
    virtual void do_something(float x, int y);
};

class d2 : public base {
    virtual void do_something(int x, int y);
};

class d3 : public base {
    virtual void do_something(char *str /* FAIL!!! */ );
};

Try to find the bug or go to drinking island?

In Java this bug would never happen. All of the do_something methods in the derived classed would be annotated with @override. When the compiler found do_something in d3 that didn't match the signature of any do_something in base, it would complain. With C++ you just spend hours trying to track down the bug.

P.S.: I still hate Java.

GPU Ray Casting of Virtual Globes

2011-01-28T23:11:37Z

I mentioned the GPU Ray Casting of Virtual Globes poster in a previous post. The author has since sent me a link to an updated version of an older blog post with the poster, a five minute video, and source code. Cool stuff. The video is 18MB, so be prepared.

Patrick is also working on a book called, "Virtual Globe and Terrain Rendering". I'll watch for that at the next SIGGRAPH.

SIGGRAPH 2010: Day 4

2011-01-28T23:11:37Z

Even though I'm completely exhausted, it was well worth the effort to get up for the Large Steps Toward Open Source panel. It seems that the movie industry is today where the computer industry was 10 years ago w.r.t. open source. They want to join the cool kids, but they don't quite "get" it yet. The biggest failing is that they only want to open source something when it's 1.0... after it has been used on a couple movies. ur doin it rong. sigh...

The single exception seems to be Sony Pictures / Imageworks. They have realized that the community is an integral stakeholder at every step of a successful open source project. The first slide from Rob Bredow's part of the talk said, in big letters, "Develop a community." YES!!!

In any case, there were a couple choice quotes and some cool projects. The best was Andy Henrickson from Disney Animation saying, "Disney isn't in the habbit of giving things away for free." He made another comment that I think really strikes to the core of why open source is so important across industries. He said, "Some things have no value unless you give them away."

I also liked a couple of comments from Florian Kains (of ILM). When talking about their move to Linux, he said, "All our production used to be on SGI machines at one point, but that ceased to be viable." I have to give some credit back to George Lucas. Apparently he was the one who got the "no value unless you give it away" argument that ultimately led to OpenEXR being open source. Florian siad, "Once George signed off, all the lawyers said, 'Yes sir, Mr. Lucas.'"

Here's a run down of current and future projects from the various presenters:

Disney Animation - current projects
- Ptex
- Pythoscope is test generator for Python. Next time I have to do a large Python project, I'll take a closer look at this.
- Maya Dynamica front end for Bullet Physics
- Partio -> Particle input / output library to abstract many, many different formats. It is intended to be "the" interchange library for the various particle systems used in production.
- Disney's (mathematical) expression editor. This was a pretty rhobust set of widgets and a parser for mathematical expressions. It looked pretty damn cool.
Pixar Animation Studios
- Rhobust, accurate, readable subdivision surface reference library. They have big plans for this, but it looks like they're going to do it wrong. They're going to develop it completely in house, in isolation, then release it when it's "done."
ILM
- OpenEXR
- Alembic
- A couple other projects that I didn't write down. Sorry.
Sony
- Open Shading Language As an aside, Rob mentioned that Rhythm & Hues plans to use OSL in a future project.
- Alembic
- OpenColorIO
- Field3D
- Imageworks SP Reticle
- Scala Migrations
- Pystring

I was also impressed that both Sony and ILM give money (ILM to Python) and machines (Sony to some "small" Linux distro) to "pay" for the open source software that they use. Florian did comment that it's often really, really hard to pay people for stuff. He gave a hypothetical example of trying to donate to some random guy in Wales. What's his tax ID? How do I notify the government? Etc.

The Games & Real Time had some good presentations, but by the time it came around (the last session on the last day), I was exhausted.

User-Generated Terrain in ModNation Racers had some pretty cool ideas. They let the user draw the terrain map using brushes. Instead of storing the drawing, they store the brush strokes. This allows them to have a very small in-core foot print. Of course, all the terrain "drawing" is done on the GPU. New terrain is combined with existing terrain using the alpha blend unit. They even use min/max blending! I'll have to rent this game (sorry!) to try out the editor.

Irradiance Rigs is largely based on several algorithms (irrandiance volumes and spherical harmonics lighting) that I'm not familiar with. meh. I need to get on that.

Practical Morphological Anti-Aliasing on the GPU was a GPU implementation of an algorithm presented last year at SIGGRAPH. Basically, you scan the rendered image from certain types of sharp features and blur them. It's a major hack, but it does fix may unappealing artifacts. It's still pretty slow, and it doesn't handle some common cases (e.g., breaks in rendered telephone lines).

One of my favorite phrases in graphics: "[This algorithm is] not physically correct, but plausible." Curvature-Dependent Reflectance Function for Rendering Translucent Materials reminds me a bit of a poster that I saw at SIGGRAPH last year, but I couldn't find any information about that. I might have a flyer or something at home. It's also similar to the curvature based AO technique that I mentioned yesterday. A preprocess step determines the curvature at each point. This curvature is then used in a different sort of lighting equation boost lighting. The equation is fairly complex, and the fast implementation uses a look-up texture based on the material properties.

The biggest failing seems to be a variety of unfortunate interactions with shadows. The precomputation step also hurts, but not as much. Still, it seems pretty cool.

SIGGRAPH 2010: Day 3

2011-01-28T23:11:37Z

I got to the Textures session a bit late because I went to Nvidia's "OpenGL 4.0 for 2010" session, and the session went over by 20 minutes. It was a good overview of OpenGL 4.0 / 4.1. Nvidia (Mark Kilgard, more precisely) continues to spread mis-information about the compatibility profile, and that's really frustrating.

I missed all of By-Example Synthesis of Architectural Textures and everything except the results of Synthesizing Structured Image Hybrids. The results in the later were very cool. I especially liked the synthesized pirate flags.

Every year there's some piece of cool tech at SIGGRAPH that I want to implement. I think Vector Solid Textures is it this year. It's a very clever method of compactly storing volumetric textures as a sort of voxelized SVG. The complex step, of course, is generating the texture data. Any algorithm that utilizes sub-algorithms with names like "L-BFGS-B minimizer" and "teleportation" is bound to be frightening. lol.

The Mesh Colors presentation started with an excellent overview of all the problems with 2D texture mapping. If he had stopped there, I would have called it a useful presentation. Of course, he didn't stop there. The idea behind mesh colors is that a set of colors are stored for each triangle (one per vertex, one per edge, and N per triangle) along a tessellation grid (basically). At run-time the UV value is used to weigh the nearest colors. The frustrating bit of the presentation was the massive amount of hand waving (shown in the photo below) about the implementation. I suspect the details are in the paper. The hair farm shirt was a nice touch.

It also seems like there is a lot of area for future research. The filtered performance is pretty poor. I had a brief discussion with Cem about using hardware tessellation (to a level that matches the mesh colors pattern) to solve some of the filtering issues. It seems like it could work in some cases, but it presents problems of its own (i.e., potentially a lot more work for the rasterizer).

I may have to implement this algorithm too.

There were a bunch of cool things in the poster session, and I took the opportunity today to talk to some of the authors. There were several useful posters about soft-shadow algorithms, a couple about image enhancement, and a couple about ambient occlusion. I especially liked Curvature depended Real-Time Ambient Occlusion (sic). They use a preprocess to determine the concave curvature at each vertex. At run-time, this is interpolated, and the interpolated to determine the AO. The interpolation here gives a better result vs. per-vertex AO in the same way that interpolating light parameters gives better results than interpolating per-vertex light calculations.

My two favorite posters were GPU Ray Casting of Virtual Globes and, I kid you not, A Physical Rendering Model for Human Teeth. I plan to add both of these to my VGP curriculum. The tooth shader is useful because it shows a case of a lighting model developed for a specific type of surface.

The other poster that really caught my eye was the WebGLU poster. It sounds like Benjamin is doing a lot of the same things for WebGL that I'm doing for desktop GL. He and I talked, and there may be some colaboration in our future.

There are some things to really like about Open Shading Language. Being able to arbitrarily connect shaders (via matching inputs and outputs) in a DAG is something that I've been talking about doing in OpenGL for years. Pulling data out by specifying an arbitrary expression on shader outputs is also genius. In OSL the data gets dumped as an image, but I still see use for this in GL.

The implementation of automatic differentiation is really, really smart. I suspect that something like this could even be implemented in our hardware shaders. This would allow higher quality derivatives in some cases. I guess I need to read the Piponi paper from journal of graphics tools.

And they now use LLVM.

Since this system has texture mapping support in this system, this might make an interesting test bed for my thesis work. Hmm...

REYES Using DirectX 11 wasn't too interesting to me. During the Q-and-A period, someone (the previous presenter, in fact) asked what could be changed in either DirectX or the hardware to make this either easier or faster. Being able to insert compute shaders directly into the pipeline (to eliminate the intermediate buffers, synchronization, etc.) would have helped a lot. This isn't the first time I've heard a request for this.

The WebGLot: High-Performance Visualization in the Browser (slides available) guys are doing some really cool stuff on top of WebGL. We'll need to use this app to test WebGL on our drivers!

The Gazing at Games: Using Eye Tracking to Control Virtual Characters course didn't feel like a course. It felt like a presentation of a survey paper on what people have done related to eye tracking in games. I got references to a bunch of papers that seem interesting, but that's about it. I do like the idea of "smart text." Text (dialog, etc.) is displayed until you look away from it. I had to leave early to go to the OpenGL BoF, so I probably missed the best parts. shrug

The highlight of the OpenGL BoF was, of course, the announcement of GLU3 as part of the OpenGL SDK. Getting a round of applause was cool.

One of the trivial questions was, "What ARB extension has not been shipped in any publicly available driver?" Answer? GL_ARB_shading_language_include. Damnit!!! Okay, we need to add that to our compiler todo list. Ugh. It's a cool feature, and John Kessenich, Jon Leech, and I spent a lot of time working on it. In all fairness, GLSL needs a much better module mechanism than it currently has. I have some ideas, but they'll have to wait until our new compiler actually ships at least GLSL 1.30.

SIGGRAPH 2010: Day 2

2011-01-28T23:11:37Z

The Importance Sampling for Production Rendering course was interesting, but a lot of it was review. I hadn't noticed that the first presenter in the course was also the author of the GPU-Based Importance Sampling from GPU Gems 3 that I use in VGP352. The bits about multiple important sampling and the bits about resampled importance sampling for shadows from the second presenter were new to me. There was a question from the audience about the Lafortune BRDF. Matt's response echoed what I say in VGP352 every year. He says that the Lafortune BRDF is not used at IMD beause it is "too uncontrollable for many artists."

I don't really know anything about REYES, so most of Micropolygon Ray Tracing With Defocus and Motion Blur was lost on me. The hyper-trapezoid BVH was interesting, though. Real-Time Lens Blur Effects and Focus Control was similarly a loss. The foreground occlusion image may find a place in VGP352 when I talk about depth-of-field effects. OptiX: A General Purpose Ray Tracing Engine was mostly an advertisement for Nvidia's ray tracing engine. There were a couple interesting bits about their compiler architecture, but meh.

To this point, I wish I would have gone to the An Introduction to 3D Spatial Interaction With Videogame Motion Controllers session instead.

That changed with Reducing Shading on GPUs using Quad-Fragment Merging. One of the opening tidbits will annoy keithp to be sure. "...one of the better ideas of real-time rendering [is] multisample anti-aliasing." In any case, their method of merging quads (2x2 pixel blocks processed by the fragment shading hardware) is fairly straight forward, but still clever. They track facing and connectivity for covered pixels in each quad. Multiple quads that have connected triangles with the same facing are merged. This can save a lot of processing.

Much to my joy, the Making of TRON: Legacy session got moved to Tuesday evening... when it didn't conflict with anything that I wanted to attend! w00t! Yes folks, that is the line...

EIGHT MINUTES of footage from the movie. A new trailer (I want one of those lightcycle throw pillows from 0:12 in the trailer). Full on awesome.

A couple interesting bits:

Daft Punk is doing the music, and they have a cameo.
Some of the concept drawings from the original movie that couldn't be done on computers at the time was used. For example, the original lightcycles had the rider on the outside. There was no way the computers of 1982 could render that, so the design was changed.
It was filmed in 3D, but, in the words of the director, there's no "spear poking you in the eye" business.

In the Q-and-A session I asked a semi-smart ass question. That's how I roll. "My biggest disappointment with the film industry came when I was 8 and the original TRON wasn't nominated for an Oscar because it "cheated" [by using computers]. Come January, is it going to be lightcycles or broomsticks? TRON or Harry Potter?" Yes, I know the Oscars are in March. I was nervous. Unfortunately, their answer was way, way too serious. "Ultimately that's up to you, but we think our work will stand on it's own." meh.

UPDATE: One thing I forgot before, there was an off-hand mention by the director that some effort was going into doing a "re-imagination" of The Black Hole. That was such a creepy movie! A re-make could be awesome... or horrible.

SIGGRAPH 2010: Day 1

2011-01-28T23:11:37Z

This year I was finally smart enough to register at the conference the day before it starts. Yay me. That made is so much easier the first day.

I wasn't expecting a lot from envLight: An Interface for Editing Natural Illumination, but I was pleasantly surprised. There were a couple of surprises in their results. I keep meaning to implement some sort of parameter editing interface for my BRDF demos, and I would have done it quite differently before seeing this paper.

I understand the method in Interactive On-Surface Signal Deformation, but I don't really get how it would be implemented in a real system. I guess that's what I get for not reading the paper before attending the presentation. I would have read the paper if I had remembered to bring the DVD drive for my laptop. That's the one annoying thing about the X200s... no built-in optical drive. In any case, it seems like this approach could be used to great effect in a demo. I imagine a scene where, say, the shock wave from a heavy object hitting the ground causes shadows on the ground to get pushed away.

My first Avatar presentation, PantaRay: Fast Ray-Traced Occlusion Caching was impressive. I guess rendering scenes with 10M to ONE BILLION DOLLARS... er... one billion polygons needs some new acceleration techniques. And a petabyte of "live data" needs some kick ass I/O. There are so many different optimizations implemented here that I think they could have gotten multiple papers out of it. Seriously. Just the layers of optimizations in the spatial index calculation should have been sufficient. Showoffs!

On a whim, I went the SIGGRAPH awards presentation. The cool thing there was a visualization app that shows, on a map of the world, where every technical paper ever published at SIGGRAPH originated. It will supposedly be posted on the web, so I'll link it here soon. The talk by Don "The Tornado" Marinelli really made it worth it, though. You can tell that he comes from a drama background. They also said that some of the content would be posted on YouTube, so his talk may get linked here later.

The word(s) of the day: deferred shading. Screen Space Classification for Efficient Deferred Shading was the first of the bunch. The basic technique is to read back the G-buffer to generate a batch of polygons to draw. The screen is divided into tiles, and the tiles are classified by attributes (e.g., in shadow, direct lit, etc.). On both PS3 and Xbox360 it cuts the frame time by about half. They talked a bit about the optimization of the polygon submission. Since the polygons are tile aligned, it seems like some sort of quadtree could be generated and rendered using point sprites. I'll have to think on that a bit more.

"Boom. 60 is better." lol. How to Get From 30 to 60 Frames Per Second in Video Games for "Free" uses the Z-buffer and the velocity buffer from the current frame and the color buffer of the previous frame to generate an in-between frame. The author was inspired by MPEG motion vectors. Here, it's a big hack. It has a bunch of hacks on top of it to fix artifacts. The best part is the way dynamic objects are "erased" from the frame (this is only necessary with deferred shading). I like it.

Split-Second Motion Blur covered some additional work from Split Second. They render a per-pixel 2D motion vector ID. This ID is then used in a blur post-process. In addition, they update the texture sampling derivatives based on the motion vector. Cheap, easy, good results. I'll definitely add this to the motion blur techniques covered in VGP351 next time it comes around.

Over the last couple years systems for indirect lighting in real-time have been all the rage. Pretty much all of them have used deferred shading. A Deferred-Shading Pipeline for Real-Time Indirect Illumination is shock no different. However, they're algorithm has good quality and speed. The other algorithms that I have seen pick one or the other. They incorporated a clever way to include occlusion for bounces, but this costs a lot of memory. I guess that's the trade off. The method for mipmapping the G-buffer was pretty clever. At each downscale they average the attributes from the largest object. This is sort of a bilateral filter in reverse. It's still screen space, so it has some drawbacks:

losing indirect light from an object that goes off screen
no support for mirrors reflecting objects behind the camera

Also, if I hear "current console hardware can't" one more time, I'll puke... or just roll my eyes again. I knew realize dynamic branching was bad on PS3, but I didn't it was so bad on Xbox360. sigh...

I wrapped up the day with Live Real-Time Demos. As Eric Haines notes, they were pretty cool. Thinking back to my days as a demo coder, it brings a tear to my eye to see demos on the big screen at SIGGRAPH.

GLU3 0.9 release

2011-01-28T23:11:37Z

The 0.9 release is now available! I'm calling this 0.9 because not all of the functionality is available in the C interfaces. Once that is resolved and a couple other GLSL utilities are complete, I'll call it 1.0.

There is a tag in the GIT repo for the release. The glu3-0.9.1 tag is the "real" tag. I pushed the glu3-0.9 before doing make distcheck, and, of course, there were errors.

md5sums:

75032c9aaf2d279738ce3940383439ff  GLU3-0.9-20100721-bin.zip
63ccdbdb8d6799b9a530b661f1d9d0f7  GLU3-0.9-20100721-src.zip
862b22f67dd7d6f087ff6ba497653621  GLU3-0.9-20100721.tar.bz2
6266c6944128eec4149c8b8101e290df  GLU3-0.9-20100721.tar.gz

SIGGRAPH 2010 Preview

2011-01-28T23:11:37Z

I've been pretty busy over the last few months, so I haven't had a chance to really comb through the SIGGRAPH program. There are several good overviews at the Real-Time Rendering Blog.

My plan feels full, but there is still time left for posters and the expo. I think I'm doing it right. There are a couple courses and some of the Avatar talks that look interesting on Sunday, but, seriously? Sunday? FAIL.

Monday

Lighting & Material Design (9:00AM - 10:30AM)
There are several presentations about PantaRay in conjunction with all the sessions (at least a dozen!) about Avatar. PantaRay: Fast Ray-Traced Occlusion Caching in this session looks good.
Split Second Screen Space (2:00PM - 3:30PM)
All four papers in this session sound interesting. I'm especially interested in Screen Space Classification for Efficient Deferred Shading and Split-Second Motion Blur. Unfortunately, I don't see a preprints for either one online.

Tuesday

Importance Sampling for Production Rendering (course) (9:00AM - 10:30AM)
I've been wanting to include some coverage of this topic in VGP352 for the last couple years. I already talk about GPU-Based Importance Sampling from GPU Gems 3, but I'd like to have a bit broader coverage.
GPU Rendering (2:00PM - 3:30PM)
Reducing Shading on GPUs Using Quad-Fragment Merging and Real-Time Lens Blur Effects and Focus Control look to be the highlights in this session for me.

As usual at SIGGRAPH, there are big periods of nothing for me, and big periods where there are 37 things I want to see. Also at 2:00 is An Introduction to 3D Spatial Interaction With Videogame Motion Controllers. Since this session runs until 5:00PM, I might just drop in late.

Wednesday

Textures (10:45AM - 12:15AM)
I like the looks of all the papers in this session. By-Example Synthesis of Architectural Textures

Synthesizing Structured Image Hybrids

Vector Solid Textures

Mesh Colors

APIs for Rendering (2:00PM - 3:30PM)
I posted about Open Shading Language a few months ago. I'd like to hear more about what they've done... especially since I've been off in compilerland this whole year.
Perception, Presence & Animation (2:00PM - 3:30PM)
I might try to drop in for Using Blur to Affect Perceived Distance and Size.
OpenGL BoF (5:15PM)
Duh.

Thursday

Large Steps Toward Open Source (panel) (9:00AM - 10:30AM)
I feel obligated to attend this panel.
Games & Real Time (10:45AM - 12:15AM)
Both Practical Morphological Anti-Aliasing on the GPU and Curvature-Dependent Reflectance Function for Rendering Translucent Materials are high on my list. I think the later paper had a poster last year. Whether it was them or not, there was an cool posted about a similar technique.

I may need to bail to go to The Making of "TRON: LEGACY".
Global Illumination Across Industries (2:00PM - 5:15PM)
GI has always been fascinating to me, and I'm so happy to live in a time where real-time GI is just about within reach.

Constructor-as-function-call idiom

2010-07-07T21:54:31Z

Several coworkers and I have been working on a compiler project for the last six months or so. We're implementing it in C++, and, for most of us, it's our first real C++ project. We're using various flavors of visitors ¹ for a lot of our IR processing. In quite a few places we have visitors that just do stuff but have no value. To invoke them some code that looks something like:

    ir_validate_tree v;
    v.run(instructions);

Often these are wrapped in a function. In other places we have things like:

    ir_swizzle_swizzle_visitor v;
    v.run(instructions);

    /* Do something with v.progress */

The latter form is always wrapped in a function that just returns v.progress.

I find the first form to be particularly ugly. Wrapping it in a function makes using it less ugly, but the ugly is still there, lurking in the shadows.

It occured to me today that at least the first form could be "fixed" by using the constructor as the run method. Instead of the code above, there would be a constructor that had the code from the run method, and callers would just do:

    ir_validate_tree(instructions);

Something similar could be done with the second case, but that would look like:

    progress = ir_swizzle_swizzle_visitor(instructions).progress || progress;

My conundrum, as a C++ newb, is whether or not this is a common idiom. Would someone familiar with C++ (at least more familiar than I am) look at that code and know what was going on? Or would they just think the author was a clueless newb?

1: We primarily use hierarchical visitors.

GLSL compiler, take 2

2010-06-10T19:32:49Z

Folks may remember from XDS 2008 that I was working on a rewrite of Mesa's GLSL compiler. To make a long story short, let's just say that effort fell over and sank into the swamp.

Last December, I started building another one. I had called the working directory of the first compiler glsl, so this one, being take 2, was called glsl2. After I had been working on it for a couple months, Eric Anholt and Ken Graunke (who has since joined our group at Intel) started working on it with me. We've come a long way.

I expect we'll take some flak for working in semi-secret. I'll take the blame for that one. The first attempt at rewriting the compiler was widely publicized and turned into a disaster. In spite of it being widely publicized, I don't think anyone ever pulled the tree. I decided that I wanted to just keep my head down and work on this one. The announcements can come when there's actually something to announce. I think we're close enough to having something to announce to make it worth the effort.

At this point, the front-end (parsing, semantic checking, generation of the initial high-level IR) is mostly complete. We support all of GLSL 1.20 and most of GLSL 1.30. We've temporarily punted on switch-statements, the float (vs. vec4) variants of the shadow sampler functions, and the "offset" versions of all the texture look-up functions. Each of those is going to require a bit more thought to implement correctly.

Carl Worth has written a preprocessor for us, but it hasn't been integrated into the tree yet. As was mentioned on the Mesa mailing list, without the preprocessor we're passing over 90% of the piglit tests.

There's still a lot left to do.

Linker: The single biggest thing remaining is the linker. The compiler and the IR are structured such that we can actually have a real linker (instead of just concatenating multiple sources and recompiling), but that means we have to write a real linker.
More optimizations: Our primary target is i915-class hardware. In order to get GLSL to run on hardware that doesn't have branches, there are a bunch of optimizations, like loop-unrolling, that you have to do. We still need to do some of those.
Preprocessor: We still have to integrate Carl's preprocessor. I believe that is being done this will still.
Memory management: Any objects that are no longer needed get dropped on the floor. We leak like a screendoor on a submarine. This was an intentional design decision. I had planned to eventually write some sort of slab allocator. At the end of compilation, the entire slab would be deleted. Eric and Carl have since convinced me to just use talloc.
Codegen: Eric is writing a back-end that will generate Mesa's existing low-level IR from our IR. I believe this is getting close to being done enough.
Mesa: Once all that stuff is done, we need to get our stand-alone compiler in the Mesa tree. We're expecting it to live in a branch for a few months while things stabilize. It should make for interesting times.

The primary repo is my GIT tree. Eric, Ken, and Carl all have their own trees, and I pull from them when their stuff is ready.

git://anongit.freedesktop.org/~idr/glsl2

For those interested in help things along, the biggest thing we need are more test cases. We're especially interested in shaders from real applications that are known to work correctly on other drivers. We have a bunch from gstreamer and other projects, but more is better. If you have some shaders and don't mind releasing them under a piglit compatible license, please send them our way.

w00t!

2011-01-28T23:11:37Z

Last night Rose and I went to see w00tstock at the Aladdin Theater. It was freakin' awesome. If you live in Chicago or Minneapolis (the next stops on the tour), you need to go see it when it comes to town. I have to admit, other than Adam Savage and Wil Wheaton, I hadn't heard of any of the acts before the show. I was a bit skeptical about the whole thing. Alas. It was 4+ hours of win. I know, it's billed as "3 Hours of Geeks & Music," but it went way over.

Since they expressly released the content of the show under a Creative Commons NC-BY license, the whole show has probably been posted, bit by bit, to YouTube by now.

Even though the show went hours over time, I stayed until the very end for autographs. (Note: I'll post pictures later.) The autographs were being done from the bar area where the Aladdin usually serves pizza. The line went across the lobby, up the stairs, across the balcony, down the other stairs, and out on to the side walk. I was fourth from last. I get up to the front, have a little chit chat with Paul and Storm, but I'm really waiting to meet Adam. Of course, by the time I got there, I couldn't think of "my favorite episode." It came to me this morning. Three words: exploding cement truck.

Instead, all I can think of is Tori whacking his knee. That episode drove me nuts! They kept replaying that clip over and over again. Every time I got this shot of sympathy pain in my left knee... that I damaged in a skiing accident. So, that's what I told Adam about. As soon as I mentioned that episode, his facial expression changed. "I wasn't at that shoot," he tells me, "but I soon as I saw that set-up I said, 'What the hell are they thinking?'" And then we had a decent conversation about it. It was really cool.

What's GNU?

2010-04-02T04:43:06Z

Am I the only one terrified by the thought of RMS making educational games for children?

Train your rendering engine

2010-03-30T06:07:47Z

Over the weekend my wife and I went to see How to Train Your Dragon. Holy crap. It was really good. For the type of movie that it is, I think it was just about perfect. Coming from me, that's saying something. I can pretty much always find something to complain about.

Not only was the movie great, but the rendering went above and beyond! I was expecting the fire to be the impressive rendering feat, but it was the water and the clouds that impressed me. Of course, it is hard to top the fire from The Half-Blood Prince. I think the best shot was towards the end of the movie. The Vikings had arrived at an island by ship. One of the dragons was going breathe fire over the ships. The camera cut to a shot from under the water looking straight up. It's hard to explain, but it was freakin' cool. It's about 3 seconds after the image below.

And yeah, the fire is pretty damn sweet in that shot.

About a minute into the trailer are some good shots of the water (surface of the lake) and the clouds.

GLX-fixes tree

2011-01-28T23:11:37Z

I've just created a branch in my personal xserver git repository where reviewed GLX and DRI patches will land. My intention is to collect, review, and test server-side GLX and DRI patches. When I believe the tree is stable, I will send a pull request to keithp. My hope is that this will get some patches into the tree a little faster.

For people who would like to try out this branch, it is available at:

git://anongit.freedesktop.org/~idr/glu3 GLX-fixes

Discussion win

2010-03-19T18:56:05Z

Mar 19 11:38:44 <anholt> idr: so, I've been looking into savage2.  guess what we need to fix it? :P
Mar 19 11:38:58 <idr>    anholt: A pony?
Mar 19 11:39:03 <anholt> yeah
Mar 19 11:39:12 <anholt> more specifically CSE inside of loops
Mar 19 11:39:21 <anholt> and decent register allocation in the presence of loops
Mar 19 11:40:11 <anholt> float v = length(a); vec4 n = normalize(a); /* oh no where'd all my temps go, and why's my program a million instrs long? */
Mar 19 11:40:36 <idr>    blarg.
Mar 19 11:40:36 <anholt> lots of n_dot_l recomputation
Mar 19 11:41:42 *        idr gets back to work trying to give birth to a pony...
Mar 19 11:41:56 <ajax>   there's an image i didn't need
Mar 19 11:42:29 <idr>    I'll post pictures to my blog later.

Little blue GPU...

2010-03-06T23:49:35Z

You'd think with a name like that they'd have better performance.

This is the old Apollo MVP4 chipset used in Super Socket 7 sytems used primarily with AMD K6-2 and K6-III CPUs. It used the Trident Blade3D graphics core, so you know it was full of win.

Meet me at Flynn's

2010-03-06T05:24:51Z

I just got back from seeing Alice in Wonderland. It was really pretty but largely content free. The high point was the trailer for Tron Legacy (I think this says more about me than about the quality of AiW.). Oh man... I am so stoked for that movie to come out! I'm really hoping there will good Tron swag in the Disney booth at SIGGRAPH this year.

/me crosses his fingers...

How do people seriously use Java?!?

2010-03-01T02:06:20Z

I've been taking a design patterns class at Portland State this term. I've been really enjoying and getting a lot out of the material of the class. However, the class is entirely in Java, and each time I sit down to do an assignment, I find myself wonder how people can actually use this steaming pile of a language. Seriously. Let me cite an example of why this language is just worthless.

I have a class hierarchy for expressions in a programming language. This consists of a base class (Expr), derived classes for different types of operations (ExprMul, ExprAdd, etc.), a derived class for variable dereferences (ExprVar), and a derived class for literal constants (ExprIntLiteral).

I want to use implement the last two as flyweights. I add a class ExprFactory to manage the instances of the flyweights. I also make the constructors of the flyweights private. This is where the whole thing falls apart. Now that the flyweights' constructors are private, I have to put all of the classes into a package.

Now that all of the classes are in the same package, they all have visibility into all of the other classes. WTF?!? I wanted to limit the visibility of a couple methods in a couple of classes, but in order to do that I've had to remove all visibility limitations on everything. Fueled by bong hits.

I've also noticed that it's almost impossible to do Java development without using an integrated environment. It appears that once you start using packages, you have to build things in a very precise order. I basically have to fiddle with it until the compiler stops giving me useless messages.

And don't get me started about having to put every public class in a separate file with a matching name. Seriously?

Java is a toy language for making web applets. It is completely useless for anything else.

UPDATE: I have now learned the difference between marking a method or member explicitly private and leaving it blank. But I'm still irritated.

GLU3 is a real project!

2011-01-28T23:11:37Z

GLU3 is now a "real" project with hosting on freedesktop.org! This means that there is a development mailing list, and the GIT repo has moved.

git://anongit.freedesktop.org/git/glu3

My hope is to have a 1.0 release out in the next month or so. I've got some new functionality that I'm working on, but I should be able to finish most of that this weekend.

Presentation Camera 0.2

2010-02-24T20:26:03Z

I updated my presentation camera rig this week with a new camera. I replaced the old Quickcam for Notebooks Deluxe with a Dynex 1.3MP Web Cam. I was hoping that going from 640x480 to 1280x1024 would solve a lot of the problems with the 0.1 setup. Alas, it did not.

I encountered two primary problems. First, Cheese would occasionally turn into a slide show when capturing at full res with a maximized window. It was very annoying. The frame-to-frame lag was long enough for me to write an entire word. The other problem, and this is the deal breaker, is that the camera has a fixed focus distance of about thee feet. If I position the camera three feet from the writing pad, the writing pad occupies about 640x480 of the captured image. Fail.

I guess I need a camera that will stream at 1.3MP (or better) and either automatically focus or a focus adjustment (the old camera had the latter). Cameras that I could find on the net that meet these requirements all cost $70 or more. Meh.

I have an alternate plan, but I'll have to actually write some code. I have an older Canon PowerShot A70 that I don't use. I seem to recall that there are some libraries available that allow real-time capture of single frames directly from the camera. The library basically tells the camera to take a picture, and then it downloads that picture. If I can get it to stream fast enough, say 10fps to 15fps, that should be a usable solution.

Given that nobody has written a V4L driver to stream from these cameras in this manner, I suspect that I may be heading down a road of disappointment. If it wasn't for disappointment, I wouldn't have any appointments.

Presentation Camera Hack

2010-02-12T06:47:14Z

For years I have been irritated by the lack of white-board space in the classrooms at the Art Institute. When the screen for the projector is pulled down, there is, literally, 4'x4' of white-board space available. As a result, I frequently have to erase drawings, equations, and bits of pseudo-code that I've written on the board. Almost invariably I want to refer back to... oops! It was erased!

Some of the classrooms at PSU have Lumens DC166 presentation cameras. My STAT551 teach uses the one in that classroom, and it's a pretty nice device. Joyous day! I figured I'd get one of those, and all my problems would be solved. I went to eBay to get one, but they're $200.

The hacker in me took over. When it gets down to it, the thing is really just a webcam and a light. It has some other features, like direct VGA / composite video output, but I don't need any of them because I have a laptop. I decided to build one. What did I build it from? Well, version 0.1 is a webcam and a light. Shocking, I know.

I used it this past Tuesday with Cheese. As you can see, the image quality isn't great. However, I was able to flip back to "erased" equations and drawings at will. Not only that, but I didn't get white-board marker smudges on my hands. The 0.1 test was a complete success.

I need to get a new cam, and I need to add a diffuser and a back "bounce" to the light. I also have some ideas for new software to write for it. I'll dish on that later. Once I get the final hardware built, I'll put up a full howto with pictures.

GLU3 FTW!

2010-01-25T22:45:52Z

I just finished pitching my fledgling GLU3 library to the ARB, and everybody loved it. Quite a few people said that they've hacked up something similar, but much less complete, to get simple demo apps running. A few of the people had functionality not in the library, and it sounds like I may get a few code contributions. It also sounds like it may be included in the OpenGL SDK. Yay me!

For those interested, the doxygen documentation is at:

http://people.freedesktop.org/~idr/glu3

The GIT tree for the code is available at:

git://anongit.freedesktop.org/~idr/glu3

At some point the tree will probably move somewhere that can allow direct commits by people other than me. I'll cross that bridge when I come to it.

Sony Pictures Imageworks releases OSL code and docs

2010-01-13T19:35:06Z

As pointed out in the excellent Real-Time Rendering blog, Sony Pictures Imageworks has released the documentation and source code for their Open Shading Language compiler. It's a slightly different take on shading languages than GLSL / HLSL / Cg. The idea is that instead of generating final colors, as in other SLs, shaders compute information about how a surface / light / whatever interacts. These shaders are then connected into a network, and complex global illumination is then calculated by evaluating the network. At least, that's my understanding from readin the introduction for five minutes.

Pretty cool stuff.

Stairs almost done!

2010-01-08T21:14:30Z

I finally got my uncle out to fix my rickety basement stairs. You may remember that my wife fell down these stairs last August. My uncle Brad does carpentry for a living, and he came up from Stayton a couple times over the last well to fix them. It's almost done, as you can see from the pictures below. All that's left is to install the handrails on both sides.

You can't see it very well in the pictures, but I also got a new door. Amazingly, this one actually opens and closes like a normal door. It doesn't have cracks and holes in it either.

If you need any work done in the Stayton-Salem-Woodburn area, let me know. I'll put you in contact with my uncle. He does really good work.

The last straw!

2010-01-07T05:25:20Z

That was the last frickin' straw! On my way home, two blocks from my house, I broke another spoke. That's four. The bike I have is large. How big is it? It's big enough that when I hang it on the bike rack on the MAX it touches the ground. I find it hard to believe that a company would sell a big that big that can't take the weight of a 6' man. EPIC FAIL.

So... I'm in the market for a new (to me, anyway) bike, and I'm looking for recommendations. Since I have to ride to school (~14 mile round-trip) twice a week, I need to get something soon. I'm a little bit past "casual commuter", but I'm nowhere near those psychos with the clip-shoes and no brakes.

I need something that can carry me and rack full of books and a laptop. The current bike is an 18 speed, but I never use the lowest gear on the front or back. Seriously... if I need those, I may as well get off and walk!

Thoughts?

I am Spartacus!

2009-12-22T05:54:22Z

It is just me, or are the Tiger Woods affairs getting to be like the end of Spartacus? Seriously.

"I am Tiger Woods' mistress!"

"Is anyone here not Tiger Woods' mistress?"

Santa selects a quest...

2009-12-21T21:56:45Z

It occurs to me that Christmas shopping is a lot like the quests in many computer RPGs. How many XP do I get for finding the best deal in town on a toaster?

Jimmy Cameron, his next 3 hour movie, and a silly fox

2009-12-20T06:06:26Z

I just got back from seeing Avatar at Cinetopia. Holy crap. Serious. The movie was so beautiful to behold. It was really, really long, but it didn't feel long. Know what I mean? Anyway, I'm looking forward to all the SIGGRAPH papers about the rendering techniques developed for the movie.

I really like the juxtaposition of the way the Na'vi connected with the trees, pa'li (horses), and ikran (flying creatures) with the way the humans connected with their mechanized walkers and avatar connection machines.

My single nit is that native peoples with bows and arrows never win. The Zulu came close, but pretty much everyone else just got slaughtered.

I also saw Fantastic Mr. Fox this weekend. Oh man... so many lols. Jason Schwartzman seriously made that movie. "I can't go to school. I'm sick." "No you're not." "I have a fever." "No you don't." "Okay."

Farewell Adrian!

2009-12-05T04:16:32Z

So, series finales are usually rubbish. Seinfeld? Cheers? BSG? I'd wipe my bum with those scripts! However, the finale to Monk was exactly what it needed to be. Script writters take notice: this is the model to follow.

L4D2 is shit

2009-11-28T09:45:20Z

I'm going to go out on a limb, and say that L4D2 is worse than the original. A lot of the new weapons are just worthless (the AK-47 as an example), and the new specials are just fucking ridiculous (the charger as an example). The witch in the fucking safe room was the last straw. If you could return things to Steam for a refund, I probably would.

New museum piece

2009-11-09T00:11:54Z

So... I got a new addition for my graphics card museum a week or so ago. I found this on eBay when I was searching for something else entirely.

I haven't installed it in a system yet, so it may not work. Why not? Because I know it doesn't work at all with the r128 driver in Mesa. I might therefore be tempted to hack on that driver. That would be bad.

FatELF

2009-11-04T05:55:06Z

I have to say, I really liked the idea of FatELF. I'm not terribly surprised at the... er... push-back. We've seen this a lot of times in the past. A number of years ago SGI proposed some patches to use a "spare" 32-bits in a per-thread data structure to hold the GL context pointer. The patches were rejected, and the submitters were flamed. Fast forward a few years (and by I a few I mean 5-ish) we have TLS to store this sort of data in a generic way.

What's the point?

Well, some times someone has the right idea to solve a particular problem. It might not be everyone's problem, and it might not be something we (the "royal" we, of course) want to maintain moving forward. However, it might be something useful and there might be a way to generalize it to make it really useful.

How so?

The first idea that idea had about FatELF was to put multiple versions of a code compiled with optimizations for different targets in the same binary. So, put the -march=i686 and -march=core2 code in the same binary. Yeah, GCC has some features that work sort of like this. Last I tried them, it was a pain in the ass and carried some annoying "caveats".

I would also love a solution to the mixed 32-bit / 64-bit distros. Anyone that thinks /lib and /lib64 (or /lib32 of you're Ubuntu) is a good solution needs a kick in the teeth. Seriously. FatELF isn't a solution "out of the box" for that problem (how do you install a 32-bit library into an existing 64-bit library install) yet, but it doesn't seem like an insurmountable problem.

Killing Floor mini review

2009-10-23T22:13:04Z

Steam is having a free trial of Killing Floor this weekend, and I spent some time with it. Let me be frank. At first, I completely hated this game. The first draft of this review had nothing positive to say and was downright mean. I played it for another hour or so after that, and I came to understand it a bit better. As a mindless zombie killing romp, it does a decent job.

There are some interesting game mechanics that add to the interest. I especially game to appreciate the encumbrance / inventory system. Each item has a certain weight, and you can only carry so much. The weights are pretty carefully selected to force some difficult choices. For example, if you pick the Hunting Shotgun, that's the only weapon (other than the knife and 9mm) that you get.

While I'm at it, I really like the Hunting Shotgun. It's one of the better shotguns I've encountered in a game. It reminded me of the old Doom 2 double-barrel shotgun, and that's a good thing.

The use of headshots to prevent creatures from using their special abilities was also clever. However, pretty much all the creatures die within a few seconds of receiving a headshot, so it doesn't turn out to be that useful.

I eventually came to enjoy the interior maps. The welding torch, which is used to secure doors ala Aliens, is really cool. I eventually settled on running through the halls, welding a door shut, then running around behind the creatures that are trying to break through the door. It was very satisfying to unload both barrels on a big group of creatures lined up at a door.

Most of the exterior maps, especially the Farm, failed due to the crummy AI. Those maps basically degrade to running around until all of the creatures are behind you, turning around and picking them off one by one with the rifle. Either the AI needs to be better or something needs to change in those maps.

My main complaints are:

Reload times on most weapons is way, way too long. This is especially true with the 9mm.
When you're reloading, you're completely defenseless. You can't abort the reload to switch weapons, and you can't do any sort of melee attack. You can just stand there and get hacked to pieces. L4D got this right with the "shove."
While I'm complaining about weapons, the AK-47 and the LAW are rubbish. The spread on the AK-47 is so wild that the weapon is almost useless. The one time I got the LAW, I couldn't get it to shoot. The game even goes so far as to mock you by saying, "If you're far enough to get [the LAW], you don't need weapon tips." That would be true if pressing the shoot button made it shoot!
Limited time in the shop between levels. I understand having limited time to get to the shop. That's one of the game mechanics. However, once the entire team has gotten to the shop, the timer should stop. The existing setup punishes people for being unfamiliar with the game. The first few times you're in the shop, it's difficult to know what to buy. The interplay of encumbrance and item weights makes this even more difficult.
One of the Ten Commandments of an FPS is "thou shalt have a crosshair." I understand that one of the main game mechanics is getting head-shots, but lack of a crosshair is still weak. I do have to give them some credit for fixing my other peeve with all other FPS games... you can use the "sights" on any weapon. It used to drive me nuts in Enemy Territory (as an example), that you couldn't use the sights on the M1.
When you die, you get pushed to the next map set and lose all your stuff. Nothing is more frustrating than getting to 2 monsters left on map 3 of 4 and dying. Well... now it's an hour until you get to try that map again.
I like death metal, but the soundtrack was just painful.

Currently the rating on Steam is 71. That's about what I would give it as well. For a $15 game, that's not bad. The problem is that there are a lot of other great games out there, and there are a few really good free games. I'll probably play Killing Floor a bit more this weekend. It may be worth $15, but I'm not sure it's worth my time.

OpenGL tutorials

2009-10-12T07:25:02Z

I just posted two OpenGL tutorials. This is the start of what I hope will be a long series of tutorials. Right now there's just a "Hello, world!" tutorial for the post-OpenGL 3.1 world (i.e., no immediate mode, no fixed-function) and a more in-depth tutorial for vertex shader inputs.

Since I want to produce PDF and HTML output, I'm authoring them in DocBook (or is it SGML? WTF?). It's mostly working out, but there are some things that I just can't seem to get to work right. The most frustrating part is that documentation for all of the SGML toolchains that I can find are crap. It's kind of ironic that the documentation for a document creation tool is so lacking...

My two biggest peeves are the crap figure handling in the PDF output and the crap table formatting in the HTML output. I can fix the HTML problems with CSS, but how is the tool makeing the output so bad in the first place? For the PDFs, seriously, a page break in the middle of a figure? Whose genius plan is that?!?

The other problem that I initial had was the lack of XInclude support in Jade. I "fixed" that using xmllint, but this seems like a fundamental feature to be missing from the tool.

Before anyone comments, I did consider using LaTeX. The main problem I have with LaTeX is the HTML output that it generates make me want to stab somebody. Every single time I come across an academics webpage that has been generated from LaTeX, I shed a lonely tear...

Chicken fight!

2011-01-28T23:11:37Z

I never get tired of watching the "chicken fight" skits on Family Guy. WIN!

Floating-point 'equality' for the lose

2009-09-24T17:11:50Z

Well, isn't that just special? I've been writing some tests for NV_fragment_program_option before merging the asm-shader-rework-2 branch to Mesa master. While doing that, I came across a neat case on shipping drivers on real hardware. These two code sequences produce different results:

    ADDC    R0, R0, |R0|;
    MOV R1 (NE), {1.0};

and

    ADD R0, R0, |R0|;
    SNE R1, R0, {0.0};

I don't think the absolute-value operator has anything to do with it, but that's how my test case was written. Gosh... if the ADDC doesn't set the NE condition code, I'd expect the result in R0 to be equal to zero. Have I gone completely mad?!?

Polish noms cometh...

2009-09-13T21:56:52Z

Just a friendly reminder... the Portland Polish Festival is coming up the weekend between LPC and XDC. It has been getting more and more crowded every year, but it's still fun. How can you say "no" to perogies and potato pancakes? nom nom nom nom...

Hurray!

2009-09-09T22:32:16Z

Hurray for context-free grammars! sigh...

I started implementing support for GL_NV_fragment_program_option to the Mesa shader assembler. I quickly discovered that the grammar for this extension is broken in a pretty fundamental way. They didn't bother to make new keywords, such as LONG, SHORT, or the condition names (e.g., LT) reserved. This means that a Bison parser has to treat the places where these non-reserved reserved words occur as identifiers. That by itself is annoying, but I can work around it.

The real problem is with the KIL instruction. In GL_ARB_fragment_program the KIL instruction takes a swizzled source register as its parameter. The current fragment is discarded if the value of that register is less than zero. GL_NV_fragment_program_option adds a second form that takes a swizzled condition code as a parameter. As a result, the following shader is ambiguous:

!!ARBfp1.0
    OPTION  NV_fragment_program;

    TEMP    GT;
    MOVC    GT, fragment.texcoord[0];
    KIL     GT.xxxx;
    MOV     result.color, fragment.texcoord[1];
    END

What does the KIL do? Does it discard the fragment if X component of GT is less than zero, or does it discard the fragment if the X component of GT is greater than zero?

Strong work guys!

My temptation is to add a new token to the lexer called USED_IDENTIFIER. When the lexer encounters something that it would currently consider to be an IDENTIFIER, it will check the symbol table. If the symbol is already there, it will return USED_IDENTIFIER instead. Then the places that want to use source registers will match USED_IDENTIFIER instead of IDENTIFIER.

However, this complicates error reporting. I don't think I would be able to generate error messages like "undefined variable foo". Instead you'd get some gook like "syntax error, unexpected IDENTIFIER, expecting RESULT or USED_IDENTIFIER". Meh.

The big question is whether or not this will match the behavior of Nvidia's assembler. Of course, with an odd, ambiguous corner case like this, it's possible the behavior of Nvidia's assembler has changed over the years.

First batch of assembly shader fixes pushed

2009-08-21T21:57:49Z

Just a few moments ago I pushed my asm-shader-rework-1 branch to Mesa master. This fixes a couple minor bugs compared to the existing ARB shader assembler, and it improves performance of the assmebler by ~50x. We (Intel) are entering the bug fixing phase of our Q3 release, so I probably won't work on phase 2 for another month or so. When I do, I plan to add support for NV_fragment_program_option next. I'll follow this with support for a couple of the other Nvidia assmebly extensions.

This work has even been mentioned on Phoronix.com.

Thesis work started

2009-08-21T00:06:42Z

After all these years, I finally started working on my master's degree last fall. This summer I got an idea for my thesis, and I've started work. As part of that, I wrote a short white paper describing the project. Basically, I want to compare the performance of texture mapping on a modern multicore CPU with a modern integrated GPU. I also want to see what the bottlenecks are that limit performance on a CPU. I'm pretty sure that discrete GPUs will be around for a few more years, but I feel like the integrated GPUs days are (or should be) numbered. That makes this an important and interesting area to explore.

LPC is coming...

2009-08-20T19:50:44Z

My talk was accepted for Linux Plumbers Conference. LPC was really good last year, so I'm looking forward to it again this year. I'm a bit bummed, though, that LPC and the OpenGL portion of the Khornos face-to-face meeting are at the same time. I can't be in two places at once, and LPC wins.

Virtual cast

2009-08-14T22:48:05Z

Last Sunday night, my wife fell down our basement stairs broke her right leg. This isn't some pansy hair-line fracture. Heavens no! She broke the living daylights out of it! Anyway, Monday morning she had surgery to insert an adamantium "nail" along her tibia. This is in lieu of a hip-to-ankle cast. Tuesday evening she came home from the hospital.

She's doing okay now. Getting her to the potty and only getting 90 minutes of sleep at a time is rough on both of us. Each day she gets a little stronger, and getting up gets a little easier.

The whole point of this is that she's not getting a real cast. That means there's nothing for anybody to sign. What a rip off! So, this is her virtual cast. You can leave messages for her here. If you have any troubles, drop me an e-mail, and I'll sort it out.

SIGGRAPH 2009: Day 4

2011-01-28T23:11:37Z

CRAZY DAY OF RENDERING TALKS!!! AHHHHH!!!

I didn't think Practical Uses of a Ray Tracer for "Cloudy With a Chance of Meatballs" would be interesting to me, and the content wasn't. However, the presenters mentioned that Sony / Imageworks are open-sourcing a bunch of projects, including the shading language used in the movie. Strong work!

There was quite a bit of information in Multi-Layer, Dual-Resolution Screen-Space Ambient Occlusion that I plan to include in my lectures on AO later this summer. Their algorithm use depth peeling, so I'll have to also cover that if I'm going to explain their algorithm. I might skip that bit. We'll see.

RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies was interesting, but it wasn't really what I was expecting. That's the bad part of the two sentence summary of the abstract in the advance program. The focus of this work is BVHs for huge data sets. That is, data sets so large that the full BVH may not fit in main memory. Their example had a BVH of 8GB. Still, it was worth seeing. The part that really impressed me is that the performance hit on small models (i.e., ones that fit in memory without compression) was only ~3%.

The Real Fast Rendering session was, as predicted, full of win.

I have to read the paper for Volumetric Shadow Mapping because there's some bit of the algorithm that I missed. I get the general idea, and I like it. Basically, you trace viewing rays through the (existing) shadow map to determine fogging. Cool stuff.

BVH for Efficient Raytracing of Dynamic Metaballs on GPU earns points for running the presentation from a Linux laptop. There was a shocking lack of Linux at the conference.

I share Naty's skepticism of depth peeling methods. Bucket Depth Peeling provides some promise to improve things. The massive use of MRT (8 targets) and the abuse of the outputs (packing 4 8-bit values in each 32-bit output component) may limit the use of this technique.

Normal Mapping With Low-Frequency Precomputed Visibility built on a bunch of algorithms that I'm completely unfamiliar with. I don't know anything about using spherical harmonics for lighting, for example, so I didn't get a lot out of this talk. Add that to my list of things to learn about before next SIGGRAPH.

After lunch, I listened to a couple papers in the Rendering and Visibility session. An Efficient GPU-Based Approach for Interactive Global Illumination was really impressive. Still, they get less than 10 fps for some relatively simple scenes. It seems like they have a good grasp of the issues they still need to tackle. Maybe by the time they get that done hardware will be fast enough to make this generally useful. (Note: They also use spherical harmonics, so mod+1 for me learning about spherical harmonics.)

Single Scattering in Refractive Media With Triangle Mesh Boundaries was pretty interesting. They've made some reasonable simplifying assumptions for caustics rendering, and they got some good results for ray tracing. It seems like something similar to displacement maps could be used to achieve this faster. Hmm... I'll add that to my list of things to (eventually) research.

Something else I noticed... every single real-time related paper presented results rendered on Nvidia hardware, usually Geforce 280 GTX.

Nit of the day: If you're going to take pictures during a talk, turn off the fake shutter sound on your digital camera. And don't use the *#%$ing flash either.

Mid-day noms

2009-08-07T23:04:57Z

Yay! I got to Mother's for lunch today. I'm just glad I got there before the line got too out of hand. I had to wait outside for a little bit, but not for as long as these people!

Fix bugs!

2009-08-06T23:37:31Z

So... on my way back to the hotel, I saw this huge bug on the sidewalk. WTF is it? Did it eat Tokyo?!?

SIGGRAPH 2009: Day 3

2011-01-28T23:11:37Z

For me, there is one recurring theme every year at SIGGRAPH: I need to take more math classes. Good grief! Anyway... Automatic Pre-Tessellation Culling was really interesting, but I was a bit disappointed that Tomas Akenine-Möller wasn't presenting. This is not to knock Jacob Munkberg, who was a fine presenter. Their idea is pretty straight forward, and I similar to something I've been thinking about for sometime. Basically, analyze the shader to partition it into the parts that calculate the position and the parts that calculate everything else. Run the part that calculates the position, perform culling, and conditionally run the rest.

The idea I had some time ago was to do similar analysis on shaders to pull low-frequency calculations up to higher levels. For example, detect calculations in the vertex shader that only change per primitive group (i.e., calculations that only depend on uniforms) and pull them out of the vertex shader.

Real-Time Hand-Tracking With a Color Glove was good research, but it has a ways to go. They basically store a big-ass database of hand images. At run-time, they search the database for an image matching the image from the camera. This is a gross simplification, but it's the right general idea. They're able to match really well, but it soaks two cores on a quad-core C2D system. Ouch. From some of the discussion after the presentation, I think there's a lot they can do to accelerate the database search. Maybe they'll have a follow-on next year.

Everyone loved Achieving Eye Contact in a One-to-Many 3D Video Teleconferencing System, but it was really hard for me to get excited about it. Yeah, it's really cool technology, but it's just too fragile. By fragile I mean that you have to have a bunch of special hardware setup in a very special way. They had a demo in the e-tech, and that's probably to only instance of this thing that will ever exist. Like a couple people at the session commented "it's just a head in a box", but "it's the best head in the best box".

So, I didn't get to see Tomas Akenine-Möller present today, but I did get to see Ken Perlin present! The UnMousePad is just plain kick-ass. It's a technology for making arbitrary sized multitouch, pressure sensitive input devices. They had 24" (diagonal) versions in the e-tech display. I talked to they guys at the e-tech display, and they're going to have an SDK, with Mac, Windows, and Linux support in a month or so. I think X.org needs to get one for who-t. I talked to the guy that has been working on the API, and I think I may have convinced him to go to XDC.

I took a late lunch because I decided to go to AMD's Next-Generation Graphics: The Hardware and the APIs talk. They were pitching a whole ton of Shader Model 5 stuff that they're wanting to add to GLSL. A lot of the features are mostly useful for video decode. The neat thing is that I think i965 hardware can do a lot of it.

In the afternoon session, Inferred Lighting: Fast Dynamic Lighting and Shadows for Opaque and Translucent Objects was excellent. They came up with an algorithm that, basically, straddles deferred shading and forward shading. I did cringe when he explained that they do alpha materials using screendoors, but it's pretty much the only way to do what they wanted to. It's a cool enough algorithm that I'm going to add it to VGP352 next year.

I was surprisingly interested in the last paper, Heuristics for Continuity Editing of Cinematic Computer-Graphics Scenes. They're system does a really good job, and I'm looking forward to the paper. From the clips they showed, they freely admit that there automated system isn't as good as an Academy Award nominated film editor. lol. In any case, automatically generating instant replays was something that I was thinking about way back when I was working on Dactyl Joust on the Jaguar.

Mother's... yum!

2009-08-06T04:24:56Z

I forgot to mention in my last post... Before I came to New Orleans, I saw an episode of "Tyler's Ultimate" called Ultimate French Quarter. In that episode, he kept talking about this place called Mother's. Three or four times he mentioned how great it was. So, I decided to give it a try.

Holy smokes! It was good! Now, this is not high cuisine, but their baked spaghetti pie really hit the spot. The cabbage and meat (pretty sure it was beef...probably left-over corned beef) that came as a side was to die for. Not only was this one of the best meals that I've had here, but it was also one of the cheapest... second only to my lunch today at Subway.

I'm pretty sure I'm going to have to go there again before I leave NOLA.

SIGGRAPH 2009: Day 2

2011-01-28T23:11:37Z

So, I didn't miss the The Future of Teaching Computer Graphics for Students in Engineering, Science, and Mathematics panel, but I wasn't exactly there on time either. It was both nice and disturbing to hear that other teachers encounter the same problems that I do. Hearing Pete Shirley complain that math is "bad" everywhere in the US was a little surprising, but I guess it shouldn't have been. I have to teach, re-teach, and re-re-teach a lot of math in my graphics sequence. I had thought this problem was localized to the Art Institute, but I guess not.

Panelists from left to right: Dave Shreiner, Pete Shirley, Evan Hart, and Ed Angel.

There were two other highlights of the panel. One was Ed Angel saying, "It will take you longer to get started with [OpenGL] 3.1, ... but they're actually going to have to do something with the math and they're going to be stronger for it." Yeah, I figured that one out too. That's 90% of the reason I stopped teaching fixed-function this year.

The other highlight was the discussion after the panel that Dave Shreiner and I had with Andries van Dam about teaching graphics. Seriously. That's like discussing teaching baseball with Yogi Berra!

The Capture and Display session in the afternoon was a lot more interesting than I thought it would be. Dense Stereo Event Capture for the James Bond Film "Quantum of Solace" was really, really cool. Basically, they used a few of high-speed cameras to record the actors in a free-fall wind tunnel. The multiple images per-frame were then used to create really good models per-frame via a technique called "shrink wrapping." With the approximate models, they could view the scene from new angles and relight it. Too bad none of their work was actually used in the movie.

The big surprise of the session was ILM's Multitrack: A New Visual Tracking Framework for High-End VFX Production. They described a new technique for tracking elements in a video sequence with a moving camera. This is used in VFX, for example, to infer the camera position so that CG elements can be added. I think it might be time for an open-source package to do this. An add-on for Blender, perhaps? I like the idea of using this in a demo to combine video with real-time graphics. drool...

Estimating Specular Roughness From Polarized Second-Order Spherical Gradient Illumination was, aside from the crazy-long name, as interesting as I hoped it would be. The novel thing from their work is that their data can be used to generate parameters from real objects for arbitrary analytic BRDFs. I really want to build one of those geodesic lighting domes used to capture BRDF data. Their technique only requires one camera, so I don't think it would be that hard.

Unfortunately, I had to miss Creating Natural Variations because the OpenGL BoF was at the same time. Since the BoF was at kind of a bad time and SIGGRAPH is smaller this year, I wasn't expecting a good turn out. However, it was standing room only. I suspect the traditional free beer may have helped. Anyway, people seemed generally pleased with the progress that's been made. We had a lot of good questions and comments. One person even asked if we were considering pixel transfer shaders. This was in the old 3dlabs OpenGL2 proposal, but I haven't heard any mention of it since then. It seems almost unnecessary when OpenCL is available. Still... might be worth considering.

nom nom nom

2009-08-05T03:57:40Z

Crawfish ettoufee... nom nom nom nom...

SIGGRAPH 2009: Day 1

2011-01-28T23:11:37Z

I managed to get to the 8:30 course, "Real-Time Global Illumination for Dynamic Scenes", on time. Amazing! It was well worth getting up early, too.

After the course I decided to go through the exhibitor hall. The previous two times that I have gone to SIGGRAPH the exhibitor hall took a couple hours to get through. There have been a ton of booths, and lots of interesting stuff. This time... not so much. I'd say it was somewhere between a third and half the size of 2008. I was particularly disappointed that there was no Disney booth. After seeing the trailer for the new Tron movie, I was really hoping they'd have some cool stuff. /sigh.../

Every year there's some hot technology that dominates most of the booths. The big trend that I noticed this year was stereo displays with optically tracked 3D input devices.

I decided that I didn't want an $8 cheeseburger (fries where $3 extra), so I wandered off for lunch. I ended up at Mulate's. This wasn't too noteworthy except two things. My culinary hero, Alton Brown, went there for his show "Feasting on Asphalt." He raved about the bread pudding. I have to admit it was pretty damn good. This brings me to point #2. A po' boy, a lemonade, and the bread pudding was $27. Yeah, no kidding. It is so expensive to eat in this town.

Since I still had a pile of time before the technical paper session, I wandered through the posters and the emerging technology exhibits. There were a bunch of cool things in each. The coolest posters also have papers to be presented later in the week, so I'll save the write-up for then. I especially liked the "Pull NAVI" in the e-tech. One person wears a helmet with ear clips, and another person operates a joystick. When the joystick is moved, the ear clips tug the ears in that direction... and the person moves in that direction. lol

The "Harmonic Fluids" paper was really interesting, but a lot of the background math was beyond me. The one problem that I had with it was the use of a 16-core system to simulate the fluid and generate the sound. Given that it was so parallelizable, I was surprised that there was no mention of implementing it on a GPU. There was mention of "acceleration" in the "future work" slide, but that was it.

The "Directable, High-Resolution Simulation of Fire on the GPU" presentation blew my freakin' mind. It turns out that this is the fire algorithm used in "Harry Potter and the Half Blood Prince" when Dumbledore burned the inferi. It's an incredibly straightforward algorithm. That's not even the cool part. The cool part is that it was developed using OpenGL Shading Language (OpenGL 2.1 / GLSL 1.20) on the presenters laptop. Yeah, no kidding!

My final nit... it's a steam room outside, but it's a meat locker inside. Seriously guys, it doesn't need to be 67 degrees in the auditoriums!

I finished up the evening with the computer animation festival. There was some really weird stuff this year. For the first time ever there was some real-time animation as well. The highlight was Will Wright (literally) in Fight Night 4 K.O.ing Tyson in the first round. Some of my favorites that I can remember the names of were:

Friends?
Anima
Alma (really, really creepy!)
Project: Alpha

"Silhouettes of Jazz" gets my honorable mention. It was a cute idea, but I would have liked to have seen more done with it. "Unbelievable Four" was also pretty good and quite correctly named.

In one piece!

2011-01-28T23:11:37Z

I waited to post until I actually got to the conference... but I have arrived in one piece with no travel drama! Yay me!

OpenGL 3.2 away!

2010-01-22T15:33:44Z

w00t! OpenGL 3.2 was officially posted today! This is the third OpenGL release in the last 12 months:

OpenGL 3.0 at SIGGRAPH 2008
OpenGL 3.1 at GDC 2009
OpenGL 3.2 at SIGGRAPH 2009

I think at this point we've closed most of the function gap between OpenGL and "the other API." Now that we can expose, either through core GL or through ARB extensions, pretty much all of what the hardware can do, we can focus on just making OpenGL better. This was an intentional decision, and we took a lot of flak for it. Lots of people we pissed that there was no Long's Peak object model, for example. I don't know that we'll ever get that exactly, but I'm hopeful and excited for the future.

Given our steady rate of progress and the positive feedback that we've been seeing, I think the ARB has started to regain some credibility. As much as I liked a lot of the design ideas for Long's Peak, it underscored one of the most important lessons of software development: take small steps. Any large project that tries to do a massive redesign all in one go (see my previous blog entry about my GLSL compiler) is going to get nothing but pain. Big pieces of software have to be redesigned incrementally. Trying to do it all at once fails (always!) because it takes too long and you can't get feedback as to what works / doesn't work.

/me gets off his soapbox... for now...

The OpenGL 3.2 spec is available from the OpenGL registry, and there is an active discussion on the OpenGL message boards.

P.S.: Don't ask me what we are planning because a) nothing is decided yet, and b) I couldn't say anything even if we did.

Rubbish!

2009-07-31T05:38:09Z

Every now and then I get a little discouraged by the state of graphics on Linux. Then I try to relax by listening to some music or watching a video... and I'm reminded of what a total pile of rubbish audio is on Linux. WTF? Why does nothing ever just work? Why do I have to jump through flaming hoops of death to get audio input working? Why can I get sound from my laptops headphone jack but not from the internal speakers? For cryin' out loud guys... get your shit together!

asm-shader-rework-1 away!

2009-07-25T01:44:27Z

I finally pushed my assembly shader (e.g., GL_ARB_vertex_program) re-work branch today. I've been working on this off-and-on for a couple of months now. I finally realized that my grand plan to rewrite the GLSL compiler was doomed to failure. I just couldn't get enough blocks of time to get it all done. I kept having to work on other things (bug fixes). After each break it took a few days (or more) to figure out what I was working on and get back into it. By the time I got back into it, I had to break away to work on other things. FAIL.

So, now I have a new plan.

The areas where I really want to work are optimizing IR and generating final machine code from IR. Phases 1 and 2 of the asm-shader-rework-1 branch support this. I've rewritten the ARB program parser, that's phase 1. Phase 2 is to add support for some of the later Nvidia layered extensions. These extension expose the full instruction set required to support GLSL. That's where the fun beings.

This is the point, phase 3, where I can start experimenting with IRs. I can bridge from the assembly code to an IR and back. Using the full assembly interfaces I can pick apart bits of complex shaders and dump them into the IR. I expect to go through several revisions of the IR before I move to the next phase. GPUs are really different from CPUs, so I expect that an IR that works well here will be different from, say, what GCC uses. I really need a test bed for experimentation.

I don't want to think about what comes next until I get quite a bit more along. My hope is that the current code base will settle down over the next week or two, and I can merge it into master for the Mesa 7.6 release.

The Eagle is blurry.

2009-07-24T23:52:33Z

I was so excited when I heard that NASA's Lunar Reconnaissance Orbiter would orbit the moon close enough to photograph the Apollo landing sites. Not only was I excited to be able to see the sites for myself, but I was excited to, hopefully, silence at least one or two of those ass-hats who believe the landings were faked. But I'm not sure this will convince anyone:

Hmm... maybe the landings were faked. Afterall, Buzz, Neil, and the guys didn't bring back any green cheese...

SIGGRAPH 2009 Preview

2011-01-28T23:11:37Z

Yay me! I get to go to SIGGRAPH again this year. As usual the program looks really good, and there appears to not be enough hours in the day. Here are my picks:

Tuesday

Real-Time Global Illumination for Dynamic Scenes (8:30am - 10:15am)

The odds of me getting to this course on time are low, but I'm very interested to hear what they have to say. This is an area of real-time graphics that I don't really know that much about. I'd like to fix that.

Fluid Simulation (3:45pm - 6:00pm)

I'm pretty curious to hear the results of "Harmonic Fluids". I'm also pretty interested in "Directable, High-Resolution Simulation of Fire on the GPU". The bit about "Simulation resolutions as high as 2048 can be computed in a few hours by parallelizing work among multiple GPUs" (emphasis mine) is a bit scary, though.

Wednesday

The Future of Teaching Computer Graphics for Students in Engineering, Science, and Mathematics (8:30am - 10:15am)
This panel is extremely relevant to my work at the Art Institute. I know three of the four people on the panel, so I know it will be good. However, I'd really like to go to the "Build Your Own 3D Scanner" course that is at the same time. meh.
Capture and Display (1:45pm - 3:30pm)
This session doesn't have a lot that I'm interested in, but "Estimating Specular Roughness From Polarized Second-Order Spherical Gradient Illumination" really caught my attention.
Creating Natural Variations (3:45pm - 6:00pm)
For me, this probably the most interesting session of the whole conference. I'm particularly interested in "Procedural Noise Using Sparse Gabor Convolution" and "Self-Organizing Tree Models for Image Synthesis". Unfortunately, there are a couple papers in the Imaging and Rendering Pipeline session, which occurs at the same time, that I'm also interested in.

Thursday

Rendering Methods and Systems (8:30am - 10:15am)
I cannot miss "Automatic Pre-Tessellation Culling." Seriously. For a real-time graphics enthusiast to miss a SIGGRAPH presentation by Tomas Akenine-Möller is just silly.
Interacting With Hands, Eyes, and Images (10:30am - 12:15pm)
I'm getting fed up with using a mouse to interact with objects in 3-space. Over the last couple years, there have been some interesting developments in this area. "Real-Time Hand-Tracking With a Color Glove" covers one of the more promising (IMHO) areas of current research. "The UnMousePad - An Interpolating Multi-Touch Force-Sensing Input Pad" also seems like it may have some promise.

This is another case where conflicts defeat me! I'd also like to attend "Building Story in Games: No Cut Scenes Required", but it's scheduled at the same time.
3D and the Cinematic in Games (3:45pm - 5:30pm)
Most of the papers in this session aren't too interesting to me, but "Inferred Lighting: Fast Dynamic Lighting and Shadows for Opaque and Translucent Objects" hits one of my favorite topic: shadows. Yeah, I'll be there.

Friday

Friday looks to be the crazy day of rendering overload! w00t!

Rendering (8:30am - 10:15am)
This summer is the first time in my graphics classes that I'm covering ambient occlusion. "Multi-Layer, Dual-Resolution Screen-Space Ambient Occlusion" couldn't come at a better time! It's a good thing that I'm covering AO after SIGGRAPH.

"RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies" should be pretty interesting as well. This is another topic that I intend to cover this summer. I may have to change the reading list for the class.
Real Fast Rendering (10:30am - 12:15pm)
Three of the four talks in this session, "Volumetric Shadow Mapping", "Bucket Depth Peeling", and "Normal Mapping With Low-Frequency Precomputed Visibility", are in areas of high interest for me (apologies to the authors of the fourth paper in the session). Last year there were quite a few shadow rendering papers, but this appears to be the only one (and it's a talk, not a paper) this year.
Rendering and Visibility (1:45pm - 3:30pm)
"Apative Global Visibility Sampling" and "An Efficient GPU-Based Approach for Interactive Global Illumination" seem like the winners in this session.

L4F FTL

2009-12-05T04:33:38Z

I really like the game Left4Dead, but it seems to have the worst on-line community of any game I have ever played. I played Versus mode using "Quick Start" (because all my L4D friends are away on vacation) for a hour tonight. I that time I saw no less than 15 rage quits, 10 TKers, and was vote-kicked, for no apparent reason 4 times. It was pretty bad.

Donerail

2009-12-20T06:12:33Z

I went and saw my friend's brother's band, Donerail, play last night. It was the first time I've seen them play, and they were pretty good. Ending with "Mother" was a bit silly. :P I was hoping to see Dmitri there, but I understand why he didn't come. I'll probably post some pics later...

Got an A!

2009-06-18T03:39:49Z

Somehow, and I really don't know how, I got an A in my Theory of Computation class. Given how poorly I know I did on the final, this is more than just a little surprising. NO COMPLAINTS HERE!!!

Cat barf at dawn

2009-06-16T17:44:55Z

There are just so few things in life more awesome the being woken up at 4AM by your cat barfing on you. Seriously.

Return of the BLOG

2009-03-17T05:35:39Z

So... my blog is back, and things are very different. I had been using some blog software called Poster. I liked it. It was dead simple and mostly did what I wanted. However, I had some spam problems. I hated it. It was annoying and mostly made me hate bloging. Poster had a built-in captcha, but I could never get it to work on the fdo server. It seem to require the mcrypt package for PHP, but even after installing that (and some following PHP fail), it didn't work.

At keithp's urging, I have decided to join the cool kids and use ikiwiki. To be honest, the jury is still out on the ikiwiki transition. It works, and it has a giant pile of features, but it has a somewhat steeper learning curve. I'll figure it out...it will just take more than 20 minutes.

One thing that I do like about ikiwiki is that I can use a regular text editor and spell checker to write blog posting. Death to browser based editors! Death to "you were idle for 20 minutes while writing that post, please log back in while I lose everything you wrote"!

I have moved over all of my postings, with correct dates, from my old blog. The comments have, sadly, been lost. Not counting the spam, there were only about 10 comments total, so it's not a significant loss.

I has sad.

2009-02-05T23:56:05Z

Today was the conclusion of a completely miserable weekend.

Last week we noticed that Fancy Feet, one of our cats, wasn't really eating. If we gave her some canned food mixed with dry, she would eat a little bit. We thought she was just being finicky...you know, a cat. On Thursday she stopped eating almost altogether. If we gave her just canned food she would lick some of the juice, but that was it. We started measuring her consumption on Thursday. On Thursday and Friday combined she ate about half an ounce of food.

On Saturday morning we took her to Northwest Veterinary Specialists. She was really dehydrated and had a pre-existing heart murmur. She stayed there overnight with an IV to rehydrate. She continued to not eat. Neither my wife or I really slept at all Saturday night. I think we finally got to bed around 3:30AM. The anxiety of not knowing what was wrong with Fancy was just eating us up.

We brought her home on Sunday. We made a plan to take her to our regular vet on Monday for an abdominal ultrasound. Around 11:30PM she started breathing really heavily and in an odd manner. We took another trip to NWVS. They didn't find anything (new) wrong with her. An x-ray showed that her heart was quite abnormally shaped and her lymph nodes were enlarged. We finally got back home with Fancy around 3:00AM.

That brings us to today. "Giant pile of suck" doesn't even begin to cover it. We dropped her off out our regular vet as soon as they opened. We knew that they were going to have to fit her into their full schedule, so we wanted to get her there early. She was finally able to get a chest echo around noon and an abdominal ultrasound around 2:30. The ultrasound showed a number of unmistakable spots on her liver: cancer.

She had been really miserable for the last few days. Usually, no matter how agitated she was, if we pet her and kissed her on the top of the head enough she would eventually start purring. We hadn't been able to get her to purr since Saturday afternoon. The only thing left to do was make that horrible, painful choice that almost every pet owner has to make at some point.

We're going to miss her a lot.

That's Fancy on the left. The kitty on the right is Minnie.

Out with the old...

2009-02-05T23:56:05Z

Everyone and their uncle has something to say about the election tonight, so I'll be brief... Today is a great day for America.

Where art thou, Delphi3D.net?

2009-03-17T06:37:15Z

Oh nos! Something seems to have gone wrong with Delphi3D.net! All I get is "403 Forbidden". There haven't been any updates for years, but the database of which card / driver combinations support which OpenGL versions / extensions has been really, really useful to me (and others) over the years.

Any ideas what the heck happened?

SIGGARPH 2008: Day 4

2011-01-28T23:11:37Z

Meh. This trip is making me feel old. Each day I feel more and more exhausted. This morning I woke up in plenty time to get to the 8:30 session, but I just didn't feel like going...and slept for another hour-and-a-half instead. After getting to the convention center, I took a long lunch and a walk down Figueroa Street. El Pollo Loco is the only fast food restaurant I have ever been to that had horchatta. Too bad it was horrible horchatta.

The painting and sketching session was great. It is the only session that I have attended that I think keithp or cworth would have enjoyed. Both "Diffusion Curves: A Vector Representation for Smooth-Shaded Images" and "Real-Time Gradient-Domain Painting" seemed right up cworth's alley. I think the presenter of the second paper, Jim McCann, may be a long-lost cousin of anholt. Their sample application is also available on-line.

"Feedback Control of Cumuliform Cloud Formation Based on Computational Fluid Dynamics" wasn't exactly what I was expecting. (What's the deal with crazy-long names of papers?!?) The presented algorithm was able to generate plausible clouds constrained to a 2D contour. The problem that I had with it was that the sequence of cloud generation was not plausible. I don't think that was a goal of their algorithm, but it does seem like a useful feature. Anyway...I don't want to bash their work because it was good work.

"Shading-Based Surface Editing" presented a really interesting tool. Basically, the artist paints shading (darker areas) on a lit 3D model. The algorithm then rotates surfaces under the stroke to match the shading. The presenter pointed out that this tool is really useful for artists that are already familiar with shading in 2D drawing. He mentioned in passing that it could be useful to teach shading. I think that particular point should be explored further. I can envision a sort of feed-back based expert system to teach shading.

The first half of the last session wasn't too interesting to me...and I didn't pay that much attention.

"Interactive Visual Editing of Grammars for Procedural Architecture" did catch my interest. Though, it wasn't so much with the topic of the paper. I hadn't realized that grammar based generation of geometry had gotten so sophisticated. It has come a long way since Logo! (heh...maybe I am as old as this trip is making me feel).

I'm such a trooper! I stayed for "Interactive Procedural Street Modeling"...the last technical paper of SIGGRAPH 2008. The idea is really simple, but it produces very effective results. The user draws some guiding structures on the blank map. A tensor field is generated from those guiding structures. The user can edit that tensor field by adding noise, creating or moving guiding structures, etc. Once the user is satisfied, streets are generated at semi-random positions within the tensor field.

It was cool to see a paper about designing procedural buildings immediately followed by a paper about designing procedural cities...where those buildings might be.

I'll probably do an update about the poster sessions after I get back. A couple of them were really cool, so they deserve some comment.

SIGGARPH 2008: Day 3

2011-01-28T23:11:37Z

The morning session, "Teaching Computer Graphics in Context in Computer Science," was not at all what I was expecting. It was about teaching graphics in contexts where graphics are actually used (i.e., scientific visualization). Since I'm teaching graphics to game programmers in a game programming department, this isn't really an issue for me. Meh.

At 10:30 I blew off all the technical sessions and went to the computer animation festival. Holy smokes...the Nokia Theater is impressive! The place is huge, and the screen looked great. Oh, and the animation was pretty cool too. I especially enjoyed "Our Wonderful Nature," "Oktapodi," and "Boldies." I couldn't find a better link, sorry. The excerpts from the movie "Dai Nipponjin" were good enough that I'll have to see if Netflix has the movie.

After lunch I went to the "Beyond Programmable Shading: In Action" session. The most interesting bit was Jon Olick's (Id Software) talk about parallel programming in games. I was especially interested in the bit about ray casting and voxels in games. The demo running at 60 - 30 fps of a 7 million polygon model directly exported from Z Brush blew me away. The progressive levels of detail in the model were just awesome. You could zoom all the way in to see finger prints on the character's hand.

In the final afternoon session, the first talk that I saw "Single Image Dehazing," was cool, but way, way over my head. I am reminded that I really need some more undergrad math. teh suck.

The next paper, "High-Quality Motion Deblurring from a Single Image," also contained a lot of math that was beyond me, but I got a lot of the general ideas. I don't think I can summarize it in a few sentences. The purpose is to deblur images where either the camera or the subject was moving during exposure. The results that they achieved were quite good. Several of the source images were completely unintelligible, but the deblurred images looked great.

They said that their software is available, so I'll have to take a look at it. Maybe after I get back home I'll try it on one of my pictures from yesterday.

~~The SIGGRAPH reception is at the Dodger's game tonight, so I'll probably update this entry after the game...it will depend on how late it goes / how tired I am.~~

We went to the game, but we left at the seventh inning stretch. Rose had a horrible headache, and the noise (and a couple annoying people behind us) was just too much. We did get to see a homerun go over the fence pretty close to us in the 5th (I think).

While the game was fun, getting into and out of the parking lot was a giant pile of suck. There are no useful signs anywhere, so you have no idea where to park to be close to your seats. As luck would have it, we parked, literally, at the exact opposite end of the stadium from the SIGGRAPH reception. Because the stadium is built on a hill, about 80% distance back to the car was up long stretches of stairs. But wait, there's more! The lot is partitioned into smaller parking areas by number. We were parked in area 11. However, once we got around to the correct side of the stadium we could only find parking areas with letters. We were by area P. Of course there were no signs or other directions. After wandering around for more than 10 minutes, I found someone to ask. We had to go through a non-obvious gate through a hedge and down a hill to get to area 11. Genius. Pure genius.

I did get a couple nice pictures of LA from the lot. Other than that, I'm seriously getting tired of LA. I overheard someone at the conference make a keen observation, "Everything in LA is 10 miles from everything else. It's kind of stupid." Well said.

SIGGARPH 2008: Day 2

2011-01-28T23:11:37Z

Add one more nit to pick with the iPhone: turning off the ringer volume also turns of the alarm clock volume. Fail. So, I got up late today and missed the whole first technical paper session.

I ended up going to the Nvidia tech talk about rendering realistic hair in real-time. That was actually quite interesting. Unfortunately a lot of the details of the algorithm presented depend on new DX11 shader stages. Still, pretty much all of it could be done with multiple passes on DX10 or OpenGL 3.0.

Since I was at the Nvidia sessions, I only caught the last paper, "Modeling Anisotropic Surface Reflectance With Example-Based Microfacet Synthesis," in this session. I was really impressed with the results they were able to achieve with a really simple BRDF measurement rig. Instead of the usual geodesic dome with a dozen or more cameras and scores of lights, they had a single camera with 20 or so lights on a moving track. You can't really tell from the picture, but on the big screen it looked like it was build from Legos.

Seriously. I could build that rig in my basement. The real magic is in the algorithm the extrapolates the "missing" data from the measured data. There are, of course, some types of materials where it fails, but for a lot of stuff it works really well.

The two shadow mapping papers, as predicted, were the most interesting to me, even though I missed the entire first paper. Specifically, "Resolution Matched Shadow Maps" was a great paper that was very well presented. I had avoided hierarchical shadow map techniques in VGP353 specifically because of the frame-to-frame variability. This effectively makes these techniques useless for games. However, these guys have managed to eliminate that fault, speed up the algorithm, and make it easier to implement. Can it even be real?

In a way, I feel bad for the researchers from "Logarithmic Perspective Shadow Maps." Their algorithm is very useful in theory, but it relies on a rasterization primitive (logarithmic rasterization) that will likely never be implemented. Once hardware is fast enough to implement their technique generally, it will be fast enough to do things like "Resolution Matched Shadow Maps" at full speed. This will make their technique irrelevant.

I missed the first few minutes (this is my theme for today) of "Multiresolution Texture Synthesis," but I got a lot out of it. The technique uses "exmplar" images to roughly describe the synthesized texture at multiple levels of details. These exemplars are connected in a graph that can contain cycles. This allows textures with infinite detail. There was an example, that reminded me of some infinite zoomer demos on the Amiga, where an image of sand was used to create an infinite zoom. Very, very cool.

"Inverse Texture Synthesis" is a very clever idea. Most texture synthesis algorithms take some sort of sample texture (some algorithms call it an exemplar or an epitome) and use that to generate a larger image. Usually the sample texture is cut, either by hand or algorithmically, from an original texture. This algorithm starts with the larger image, generates a novel sample texture, and uses that to generate a alrger texture. The sample texture is usually not directly cut from the original texture, but it is still representitive of the whole original. This is generated using a "control map" that describes different regions of the texture. One of the examples is a "ripeness" control map for a banana that corresponds to black versus yellow regions of the banana.

The really cool thing about this is that it allows an artist to generate a novel control map for an object. A new texture is generated using the sample texture and the control map that matches what the artist expects. (That was worded poorly, but I think you get what I mean.)

"Lapped Solid Textures" was also a nice advancement. It probably not as directly useful to me, though. I hope to see games use this technique to make objects "solid." The other interesting thing about this paper is that the author suggests a number of areas further research that would be within the reach of undergrads (wink, wink, nudge, nudge). One of those areas being to improve the user interface for editing the texture exemplars used in this approach. This differs from the 2D patched used by Hoppe, et al because they are volumetric.

In the final paper of the session, "Anisotropic Noise" addresses one of the issues with noise that has bothered me for years. It is pretty much impossible correctly filter noise that is generated from textures. Octave truncation works, but it always ends up with textures that are both under-sampled and over-sampled. FAIL + FAIL. Using some off-line processing to generate some noise "tiles," correctly anisotropically filetered noise textures can be generated. The hard part is the off-line processing, and the real-time processing is trivially higher than octave truncation.

As an added bonus, this algorithm can fix "texture distortion." Imagine a terrain where the assigned texture coordinates are the X/Y values. Areas with steep slopes have more texels than flat areas, and this results in stretching. Using the same anisotropic technique can fix this problem. WIN + WIN.

The OpenGL BoF went really well, I think. Nobody showed up with torches or pitchforks. Of course, the free beer may have helped. The most useful part of it for me was the mingling period after all the presentations. I talked with quite a few people and, contrary to the /. reports, nobody was furious. Whew!

EDIT: Added links to most of the papers.

SIGGRAPH 2008: Day 1

2011-01-28T23:11:37Z

In spite of various travel failure, I managed to get to the Convention Center by about 7:50AM. Registration opened at 8:00, and I was done by 8:15...that even includes the time it took me to go back and get my conference badge. I was originally given someone else's badge. Oops.

While I was waiting in line, I took a quick peek at /. on my phone. The story about developer reaction to OpenGL 3.0 was depressing, at best. I knew that people were going to be disappointed and upset, but I am a little surprised at the level of anger that people seem to be expressing. I can only hope that this is being over exaggerated on /.

One other random thing...I took a bus to downtown (the cab from downtown to the hotel was $50 yesterday). It was an express "commuter" bus. The vast majority of the people on it were 30-something / 40-something women. In the front part of the bus there were 11 women to 1 man (me). I didn't take a census of the rest of the bus, but the gender distribution appeared to be similarly skewed. Is it my imagination, or does that seem odd?

I was able to make it to the first paper session. In a lot of ways, the material in "Factoring Repeated Content Within and Among Images" reminded me of MPEG macro blocks and motion vectors. Their technique applies to still images, however. For certain types of images, they are able to achieve very high quality at very good compression ratios. In particular, images with very high frequency information (they used an image of zebras standing in grass) tend to not work well. The other advantage of their technique is that decompression can be very easily implemented in a fragment shader.

The interactive photo tourism software presented next was, I have to admit, one of the coolest things I've ever seen. I especially like the ability to use "community" photos to find paths between sequences of personal photos to create smooth transitions. The vacation photo slide show will never be the same!

I was robbed! Michael Abrash wasn't one of the presenters of the Larrabee paper. We got Larry Seiler instead (no offense, Larry). That's the end of the bad news. Let me say this now: Larrabee is going to change everything. I'm still a bit in shock at how awesome the architecture is. Having worked on Cell, I believe that Larrabee will be everything that Cell should have been.

Larrabee fixes two significant limitations of the Cell architecture with respect to implementing a "standard" graphics pipeline.

A normal memory architecture. Each core accesses memory via L2 caches is the same programming model that we've been using forever. None of this local storage, software-managed cache nonsense.
A hardware texture unit. One of the areas that I was most worried about with porting Mesa to Cell was texture mapping. The way that textures are addressed and accessed was going to take a lot of instructions on Cell. On Larrabee, they just have a freakin' texture unit that can, as the Larry said, "support thousands of in-flight texture accesses" to hide latency.

Of course, no products, timelines, clock speeds, etc. were announced. I don't know any of that either, so please don't ask.

I'm filled with a variety of emotions right now. On the one hand I'm really, really excited for Larrabee and the opportunities it will bring. I'm also even more disappointed that I already was about Cell. The window for someone to create an OpenGL implementation for Cell is now closed. Sure, they could do it, but nobody would care. Opportunity lost. sigh

The surprise in the last session was the last paper. I wasn't expecting much from "Real-Time Rendering of Textures With Feature Curves," but there was some good bits there. Basically, they define a normal-map using specially encoded Bezier curves for embossing / engravings. The fragment shader then uses this information to generate normals that preserve the discontinuity in the "trench" of the engraving. Using a normal-map texture when there is a discontinuity can result in some off artifacts in close-up views. I'll probably mention> this work next year in VGP352. I think it will be a bit beyond the abilities of my students to implement it. The algorithm has a number of complex details.

The various hair rendering papers were interesting...but interesting to me in the same way as quantum physics is interesting. That is, it's good to know that people are working on it, and it's good to hear about it, but it's not generally useful in my day-to-day life.

I went and saw most of the expo floor between sessions. It wasn't really that great. About every 4th booth was for an art school. Of course, The Art Institute was there. There were also a lot of "3D printer" booths. Yippie. Most disappointing of all...there weren't any good booth hand-outs. I take that back. Intel was giving out cool USB hubs, but they wouldn't give me one because I work there. Fail.

I plan to finish the expo floor tomorrow. I will also try to look at the rest of the posters. I looked at quite a few today as they are spread all around the conference center. I've written enough for one day, so I'll save the poster details for later. There are some cool posters...like the guy doing audio processing and an Nvidia GPU and audio output from the VGA port.

EDIT: I think I fixed the formatting failure.

And let the travel drama begin!

2011-01-28T23:11:37Z

Memo to myself: only stay in hotels with negotiated rates, no matter how far they are from the convention. Why? Because you don't negotiate with kidnappers or crap hotels.

The hotel that I originally booked turned out to be all kinds of crap. The place looked nice on the inside, but look can be oh-so deceiving. They didn't have a room available with a private bathroom. Uhm...what? I called Amex and got a different hotel (10 miles from the convention center...fail), and took a cab over. The cabbie told me that the city give homeless people vouchers to stay at that hotel. After seeing some of the people that wandered into that place while I was on hold with Amex, I believe him! Truth be told, I think it's a good thing they didn't have a room available!

All that is behind me now. I'm going for dinner in a bit, and I'm going to the conference in the morning.

So, boys and girls, if Amex doesn't like a hotel, you probably won't either. And, apparently, don't travel with me either. I'm bad luck.

SIGGRAPH or bust!

2011-01-28T23:11:37Z

This year was the first time since 1998 that I went to Europe. It will be the first time since 2004 that I will go to SIGGRAPH. Yay me!

The program looks really good this year. Here's how a conference like this works for me. I plan a bunch of stuff to go see, get really overwhelmed, and miss a bunch of good stuff. :P I think the rule, especially at SIGGRAPH, is that if you're not overwhelmed, you're not doing it right! Anyway, here's the plan so far...

Tuesday

Image Collections & Video (8:30am - 10:15am)
Truth be told, I probably won't make it to this session. I'll probably either still be asleep or busy with registration and all that. If I do make it, I'm most interested in "Factoring Repeated Content Within and Among Images."
Parallelism (10:30am - 12:15pm)
There is no way that I'm going to miss a chance to see Michael Abrash talk. Back in the early to mid 90's when he was being published in Dr. Dobb's Journal and working on Quake, I totally idolized him and hung on his every word. In the graphics classes that I teach, I still quote, "If it looks good, it is good." Combined with seeing Iron Maiden in concert a couple months ago, this is turning out to be a summer of re-lived youth. Now, where's my Amiga...
Rendering Materials (1:45pm - 3:30pm)
This is what I love about SIGGRAPH! I consider myself to be "skilled in the art." I try to keep up with new rendering techniques. Then I see a paper titled "Realistic Rendering of Birefringency in Uniaxial Crystals." I have no idea what that even means! I am so there!
Hair and Realistic Rendering (3:45pm - 5:30pm)
"Dual Scattering Approximation for Fast Multiple Scattering in Hair" seems to be the only paper in this session that focuses on real-time rendering. Last year in VGP352 (Lighting and Shading) I covered a couple fur shaders (fins-and-shells and the fakefur BRDF), so it might be time to add some decent hair rendering.

Wednesday

Real-Time Rendering (8:30am - 10:15am)
I have to see "Real-Time, All-Frequency Shadows in Dynamic Scenes." Over the past years I have assigned readings from other papers by these authors in VGP353 (Shadows). I just might have to add this one to the list...

Nvidia has some tech sessions between 9:00am and 11:00am that look really interesting too. So many things to see!
Faces & Reflectance (10:30am - 12:15pm)
"Face Swapping: Automatically Replacing Faces in Photographs" sounds really interesting. This has popped up a couple times in the tech news lately, so it's a very timely issue. I expect this to be a pretty full session.

We spend a lot of time talking about BRDFs in VGP352, so "Modeling Anisotropic Surface Reflectance With Example-Based Microfacet Synthesis" also really caught my eye.
Global Illumination (1:45pm - 3:30pm)
Two papers about shadow maps in one session? The Shape Analysis session didn't stand a chance!
Texture (3:45pm - 5:30pm)
This one was a close call. There are a few papers in Jiggly Fluids that sound interesting, but I don't think I have a strong enough background in the area to get much out of them.

The texture synthesis papers, especially "Inverse Texture Synthesis" by Yi-Li Wei, et. al. intrigue me. I saw Yi-Li present Tile-Based Texture Mapping on Graphics Hardware at SIGGRAPH 2004. It was the most memorable, if not favorite, presentation that year.

"Anisotropic Noise" is also a must-see. I need to beef-up the coverage of noise in VGP352, and this might help.
OpenGL BoF (6:00pm - 8:00pm)
This is the whole reason Intel is sending me to SIGGRAPH. Will there be a big announcement at the BoF? Well...you'll just have to show up to find out, won't you?

Thursday

Teaching Computer Graphics in Context in Computer Science (9:00am - 10:00am)
TBD. (10:30am - 12:15pm)
This one is a toss up. There are a couple papers in both Hair, Rods & Cloth and Perception & Hallucination that sound interesting, but nothing really jumps out at me. That probably means that I won't go to either. Expo floor, maybe?
TBD. (1:45pm - 3:30)
Meh. I might go to AMD's "GPU-Accelerated Video Encoding: State of the Art" from 1:00pm to 2:30pm.
Deblurring & Dehazing (3:45pm - 5:30pm)
The two papers about motion deblurring of images sound interesting.

Friday

Shape Acquisition (8:30am - 10:15am)
In a previous life, I was very interested in archeology. I even went on a dig of an old Roman town (Leptiminus) in Tunisia. Because of that, "A System for High-Volume Acquisition and Matching of Fresco Fragments: Reassembling Theran Wall Paintings" caught my eye. I might not stay for the rest of the papers in the session.
TBD. (10:30am - 12:15pm)
I don't know what to do here. The papers in the Differential Equations session all sound like they're over my head, and the papers in the NPR & Deformation session don't sound that interesting to me.
Painting & Sketching (1:45pm - 3:30pm)
Cloud rendering is an area that has always interested me but that I have not gotten into. "Feedback Control of Cumuliform Cloud Formation Based on Computational Fluid Dynamics" sounds like it will present some interesting work in this area. None of the other papers in the session sound that interesting to me, though.
Procedural Modeling & Design (3:45pm - 5:30pm)
Poor saps! Presenting the in the last session of the last day is always a big lose. I have to see "Interactive Procedural Street Modeling." Three of the authors are local boys from Oregon State University. Go Beavers!

Whew! I'm tired already!

Love the media

2011-01-28T23:11:37Z

I guess I must be awesomely famous or something (probably "or something"). My new job has already been mentioned on Phoronix.com. Unfortunately, the work that I will be doing to parallelize Mesa won't be for anything as glamorous as Larrabee.

In fact, it will be for the complete opposite end of the spectrum. We're seeing more and more chips, like Intel's own Atom, that trade wide, out-of-order pipelines for simpler, in-order cores with multiple threads per core. On those types of architectures, especially when hardware TNL is not available, Mesa's performance is really, really bad.

There is room for a lot of improvement even on more traditional systems with hardware TNL and processors with good single-threaded performance. It is easy to find apps where lot of time is spent in the app, a lot of time is spent in the driver, and only one CPU is utilized. Sure, the app developer could multi-thread the app, but why? That means multi-threaded optimization needs to be done in N places (for N apps) instead of just one.

Anyway...I guess I should get back to work now...

Pictures recovered!

2009-03-17T06:37:15Z

As I mentioned in my previous post, my camera and laptop were stolen while I was recently travelling. During our trip, both my wife and I had been copying pictures off our cameras onto the laptop. Once copied to the laptop, the pictures were deleted off the cameras. So...even though my wife's camera wasn't stolen, we still lost all those pictures. Or so we thought.

Since cameras use FAT32 file systems, I knew it was possible the deleted pictures could be save. I had her switch to a secondary memory card for the rest of the trip. I did a little searching, and I found a program called PhotoRec. PhotoRec FTW!!! It managed to find 201 pictures that were deleted!

The bad news is that the value of the stolen items is less than my insurance deductible, so I get the shaft. We booked our trip with Amex, so we're going to follow up there...I could have sworn that they had some sort of "automatic" travel insurance, but I could be wrong.

Message of the day: lock the door!

2009-03-17T06:37:15Z

So...I'm still off on vacation. I'm in Rome now. My wife already posted something to her blog, but I have a rant of my own. On the train from Paris to Rome, someone broke into our cabin and stole my laptop and camera. The laptop was her old G4 PowerBook and the camera wasn't too expensive either, so I'm not too upset about that. However, I lost all of my pictures from the first 6 days of our vacation. I had some really good photos from Paris, especially the tripod shots from the catacombs.

Stop reading if you're Italian.

Once we got to Rome, it was like arriving in a 3rd world country. We either went to or called 4 police stations to report the theft, and they were all...closed. Closed?!?! WTF?!? We finally got to an open police station today, and there was a couple from England who and been robbed (1.000€!!!) on the same train.

I get the distinct impression that the train conductors, who only speak Italian, are in on it. The didn't tell us to lock the doors or even tell us that there were locks. Since train theft is obviously common, it seems obvious to warn people. Not everyone rides these trains all the time. There shouldn't be anyone getting on or off the train in the night (at border stops, etc.), so they might also check people there.

Needless to say, I was pretty pissed all day yesterday. Rome may have been a great nation, but Italy not so much.

Good-bye IBM. Hello Intel!

2009-02-05T23:29:27Z

As some folks are likely aware, today was my last day at IBM. I was previously at Sequent, who was bought by IBM, since 1997. I've been working with many of the same people for 11 years. Am I still a young-un if I think 11 years is a hella long time to work at one place?

I really enjoyed working in IBM's Linux Technology Center. It is a unique and incredible working environment. I highly recommend the LTC for folks interested in any aspect of server related Linux work. However, IBM isn't a graphics company these days, so the advancement opportunities for a graphics specialist are limited. At many times over the years there wasn't enough "fundable" graphics work, so I had to work on other things. Faced with the choice of changing my technical focus or move on, I have decided to move on.

Where am I going? To Intel, of course. I'll be joining keithp, anholt, and jbarnes at Intel. It seems they have a lot of graphics work to do these days, and they have no shortage in sight. I'm really excited to join their team. I've already been going over my Mesa "to do" to see what I might be able to tackle. There are a lot of choices.

I'll be starting at Intel on 6/30. Between now and then I will be vacationing with my wife in Europe. I'm taking a laptop, but I don't know how often I'll be able to / want to check e-mail. On the way to the Netherlands (our first stop), I have a 12 hour) lay-over in Houston. I sure hope they have free wifi...ugh...

Iron Maiden? Excellent!

2009-12-20T06:12:33Z

I can now comfortably die with a life complete. On Monday, June 2nd, I saw Iron Maiden perform live at the White River Amphitheater near Seattle. I have, literally, been waiting 22 years to see them live. When I was in middle school and high school and they came to Portland for Somewhere In Time and Seventh Son of a Seventh Son, I was broke. When they came to Portland in 1996 for The X Factor, they canceled at the last minute.

This show was, basically, a re-mix of all their class tours from the 80's and early 90's. They even had the giant Eddie mummy with sparks shooting from his eyes from the World Slavery Tour. Hopefully without sounding like too much of an old dork, it was fucking awesome!

Game rant

2009-12-05T04:33:38Z

I recently purchased Mario Kart for the Wii. It's a hella good time. However, it contains on of those mis-features of console games that makes me hate consoles. Why do I have to play the single-player game to "unlock" 50% of the content for multi-player? I paid for 100% of the content, so I'd like to be able to play it...without having to pay for it again by playing to boring-ass single-player game. kthnks.

Unlocking parts of the game was cool when it was unlocking a bonus level or a bonus character. Having to unlock a large portion of the regular game is just insulting.

Beta release...finally!

2009-02-05T23:22:25Z

Yesterday I finally made a beta release of the XP10 driver. The driver uses native mode setting (instead of calling the BIOS), RANDR 1.2 (thanks to keithp and anholt). It currently only supports the VGA output, but that should be resolved shortly. It also still has the color byte-ordering issue on big-endian. In spite of all that, I think that it's pretty solid on x86.

Now, if I could just get a hold of ajax to get this in X.org 7.4 and Fedora 9...

Har-har-har!

2009-02-05T23:19:46Z

Dear Mr. Weather,

We received your April Fool's Day joke a bit early this year. Thank you for reminding us that global warming means weird weather, not hot weather. That said, may we please have spring back FFS?!?!?!

Reason for all the XP10 love

2011-01-28T23:11:37Z

This week at POWER.org's Power Architecture Dev Con '07 IBM showed a system that is known internally as Bimini. At the conference it was shown with X running doing a continuous loop of kernel compiles. It's a 4-way PowerPC 970MP (2 CPUs, 2 cores per CPU) system targeted at developers. It has a PCI-Express x16 slot, and that slot ships filled with an XP10 card.

All of this XGI XP10 work that I have been doing over the last few months has been for this system. I put in some long hours last week trying to get the driver into shape for this demo, and I'm pretty pleased with the result. There is, however, still quite a bit of work to be done. The existing driver does most things (mode setting, DDC, DPMS, etc.) using BIOS calls. Obviously, that doesn't work on PowerPC! In my local tree I have single-head CRT mode setting working without the BIOS, but there's a lot of ugliness there...it also doesn't save / restore the console mode.

If you've looked through the published docs for XP10 at all, you've probably noticed that there is a lot of information about mode setting missing. I'm (painfully) aware of that, and I'm working with XGI to get that resolved.

XGI driver 1.5.0 release

2011-01-28T23:11:37Z

As per the message sent to the xorg-annouse list, I've just released version 1.5.0 of the XGI driver. This is the driver for the V3XT, Z7, and various releated chips.

I should also have a libpciaccess release out pretty soon.

I'm hoping to get a release for the XP10 out soon, but I'm not sure it will make it out in time for the X.org 7.3 release. We'll see...

DRM fences for XP10

2009-02-05T23:06:11Z

It looks like DRM fences are working on XP10. Using fences instead of the scheme previously used in the DDX simplified the code a lot. Hopefully TTM support for the PCI-e GART will be as easy to implement as fences were. Somehow I doubt it.

'Final' XP10 DRM bug fixed!

2009-02-05T23:03:42Z

Earlier this week I managed to fix the last known bug in the XP10 DRM. I can now restart the X-server as many times as I like, and acceleration keeps working. I'm just waiting to see if benh and airlied have any review comments before I bump the version to 1.0.0 and merge to trunk.

Acceleration for XP10

2011-01-28T23:11:37Z

While my wife was spending the whole Saturday reading Harry Potter, I was spending the whole Saturday trying to get acceleration working on XP10. I leave it as an exercise for the reader to determine which of us is the bigger geek. In any case, it works now. DRM changes are pushed to xgi-0-0-2 branch and DDX changes are pushed to HEAD.

Next week I get to see if it works on 64-bit if it's still broken. I've changed so many of the internal types to the "correct" things that I suspect it might Just Work. I think I hear Nelson laughing at me somewhere...

I'm in your kernel module, converting to DRM!

2011-01-28T23:11:37Z

Sorry about the title. I've obviously spent too much time on fark.

In any case, the DRM xgi-0-0-2 branch contains a version of the XP10 (aka Volari 8300) kernel module converted to the DRM infrastructure. Since most of the code in the driver supplied by XGI duplicated existing infrastructure, this nets a reduction of ~2,700 lines of code. That reduces the size of the kernel module (source) by nearly 50%.

In addition, the HEAD of xf86-video-xgixp (the DDX for the XP10) has been modified to use the DRM-based kernel module instead of the XGI supplied monolithic kernel module.

Baring any unforseen objections by other DRM folks, I'm going to merge the xgi-0-0-2 branch into DRM trunk on Friday. This means that it should find its way into a mainline kernel soon-ish.

w00t!

XG40 DRM support in mainline!

2011-01-28T23:11:37Z

I just received notice that my (trivial) patch to add support for XG40 chips (as used in Volari V3EX, V3XT, V5, and V8 cards) is in the mainline tree. In a practical sense, what does this mean? Well, if you have one of those cards you can use the open DRM, open DDX (from fd.o GIT) with the closed DRI.

For those who haven't been keeping up, XGI cannot open the code for the DRI driver. It uses a lot of code license from SGI. However, this does provide us another step towards creating an open DRI driver. The data books are in fd.o bugzilla.

Start hacking!

First post... w00t!

2009-02-05T22:49:24Z

Hurray for me. After all these years on teh intarweb, I have a blog. I have no intention of chronicling my life or some other boring crap like that. Instead, I intend to use this as a forum to communicate information about various open source projects that I develop. This will primarily cover my work on Mesa, X.org X-server, the MGA driver for X.org, and the various XGI drivers for X.org. There may be other stuff from time to time, but I suspect that these are the topics most likely to interest anyone.