Won Chun's talk, Google Body: 3D Human Anatomy in the Browser, was a modified version of a similar talk from WebGL Camp 3. He discussed the mesh compression and WebGL rendering used in Google Body. My favorite part was how vertex cache optimization, which is used to optimize rendering, also helped improve compression by increasing coherence. There was lots of other goodness like how rendering with
floatvertex components was faster than using
shortcomponents even though floats require more data. Won's compression code is now open source.
Cyril Crassin gave a very impressive talk titled Interactive Indirect Illumination Using Voxel Cone Tracing: An Insight. It showed fast, approximate, two-bounce global illumination by grouping coherent rays of reflected light in a pre-integrated cone. I obviously do not work in GI, but if you do, this talk is definitively worth checking out.
Another very impressive talk was Out-of-Core GPU Ray Tracing of Complex Scenes presented by Kirill Garanzha. They interactively rendered the Boeing 777 model, a classic "massive model", on an NVIDIA GeForce GTX 480 at 1024x768. For many views, it looked like it was 200-300 ms per frame with a cache size of 21% of the model (360 million polygons). I'm pretty sure only diffuse shading was used, but even so, this is outstanding work.
One course I never miss at SIGGRAPH is Beyond Programmable Shading. A lot of material from this SIGGRAPH course makes its way into our course at Penn. I wasn't able to make all the sessions this year, but I will certainly catch the rest on SIGGRAPH Encore.
A major course theme was system-on-a-chip (SOC), where both CPU and GPU cores are on the same chip. This has the benefit of eliminating the system bus between the CPU and GPU, which is often a bottleneck.
I really enjoyed the panel What Is the Right Cross-Platform Abstraction Level for Real-Time 3D Rendering? with David Blythe, Chas Boyd, Mike Houston, Raja Koduri, Henry Moreton, and Peter-Pike Sloan. They discussed the tension between application developers, middleware developers, OS developers, and hardware vendors when it comes to APIs like Direct3D and OpenGL. It was generally accepted that D3D/OpenGL are at the right level of abstraction, but need tweaking. Various ideas were discussed, including shorter specs; merging compute and rendering APIs; new APIs for system-on-a-chip; and even having one low-level rendering API and multiple high-level rendering APIs, with the argument that there are many abstractions (programming languages) that do the same thing: change the CPU's instruction pointer.
My favorite part about the panel was the discussion on what goes on in the driver. There is significant pressure for hardware vendors to do well on game benchmarks so many hacks are added to optimize for specific games. The games may not be using best practices, so they are "rewritten in the driver" making the driver really bloated - what a mess. This reminds me of the special allocator mode added to Windows 95 to workaround a bug in SimCity, who was using memory right after it was freed.
All of these game-specific hacks (I almost called them optimizations) lead to non-obvious fast-paths. What vertex-format should I use? As an application developer, I don't know. Well, I sort of know, but when killer-next-gen-game comes out, which uses double-precision texture coordinates, should I also switch to make my application run faster? Introducing a low-level rendering API would fix many of these problems and remove the bloat from the drivers.
Another interesting topic in this discussion was why closed-source drivers are higher quality than open-source drivers. The reasons are quite understandable: closed-source drivers can hide hardware bugs, hide intellectual property that isn't patented, and hide third-party code. It also sounds like there are a lot less open-source developers (40-to-1?) and changes in the Linux kernel can affect the drivers.
Every year, the Beyond Programmable Shading ends with a thought-provoking panel, but this panel was by far the best one!
Full SIGGRAPH Trip Report: day one | two | three | four | five