Author Archives: Eric

Seven Things for July 26th, 2011

The harddrive on my main computer died, which has the odd effect of making me have more time for blogging (and less for screwing around on random stuff). So, seven things:
  • First, if you’re going to HPG 2011, I’ll save you five minutes of searching for where it is: it’s at the Goldcorp Centre for the Arts, Google map here. Note also that things don’t start until 1:30 on Friday.
  • SIGGRAPH parties? I know nothing, except that the official SIGGRAPH reception is 9 to 11 PM Monday at the convention center, and the ACM SIGGRAPH Chapters Party is 8:30 PM to 2 AM on, oh, Monday again. Odd scheduling.
  • Timothy Lottes cannot be stopped: FXAA 3.11 is out (with improvements for thin lines), and 3.12 will soon appear. Note that the shader has a signature change, so your calling shader code will have to change, too.
  • At the Motorola developer site there’s a quick summary of various image compression types used for mobile phones and PCs.
  • Sebastien Hillaire implement the God Rays effect from GPU Gems 3, showing results and problems. Code and executable available for download.
  • I’ve been enjoying some worthwhile articles on patents and copyrights lately, both new and old. Worth a mention: Myrhvold madness; a comic (a bit old but useful) on copyright – a good overview; The Public Domain, a free book by a law professor who helped establish Creative Commons; the July 2011 CACM (behind the paywall, though) had a nice article on why the U.S. dropped “opt-in” copyright back in 1989 (blame Europe). Best idea gleaned, from The Public Domain: the length of copyright is meant to motivate people to create works for payment, so a retroactive increase in the length of copyright  (e.g., to protect Mickey Mouse) makes no sense – it creates no motivation for works already created.
  • Polygon Pictures’ office corridor would be a bad place to be if you worked way too many hours. Otherwise, nice!

FXAA Rules, OK?

So there are those people out there that punch other people’s punchlines. Someone’s three quarters of the way through telling a joke, and a listener says, “oh, right, this one ends ‘to get to the other side'”. You don’t want to be that guy, but that’s a little bit how I feel writing about FXAA, given that there’s a whole course at SIGGRAPH next month about these sorts of antialiasing techniques. I blame Morgan McGuire’s Twitter feed, as he (and 17 others) retweeted Timothy Lottes’ posting that he had released shader code for FXAA. I’d seen FXAA mentioned before, NVIDIA put it in their DirectX 11 SDK. Which, frankly, is sadly misleading – the implication is that it works only on GTX 200-level hardware and above, when in fact it works on DirectX 9 shader model 3.0 hardware, GLSL 1.20, XBox 360, and Playstation 3, to name a few, and is optimized in various ways for newer GPUs. Anyway, seeing this shader code available, I was interested to try it out. Morgan mentioning that he liked it a lot got me a lot more interested. A few hours later…

So what the heck am I blathering about? To start, there are a number of these ??AA methods that are based on post-processing a color (and sometimes, also normal and depth) buffer. MLAA, morphological antialiasing, was the first used for 3D images, back in 2009. The basic idea is “find edges and smooth them”. The devil’s in the details, which is what the SIGGRAPH course will delve into (and I’ll certainly attend): how wide an area do you search to try to find a straight edge? how do you deal with curves and corners? how do you avoid oversmoothing thin edges, blurring them twice? how does it look frame to frame? and, most important if you want to use it interactively, how do you do this efficiently?

I’ve wanted an MLAA-like solution for two years, since before HPG 2009 when I noticed the MLAA paper on Ke-Sen’s pages and talked to Alexander Reshetov about it (who was very helpful and forthcoming). I even got a junior programmer to attempt to implement it in a shader, but the implementation was quite slow (due to a very wide search area) and ultimately flawed, and we didn’t have time to get back to it. Last year at SIGGRAPH there was a talk by a group in France, led by Venceslas Biri and Adrien Herubel, about implementing MLAA on the GPU, and they released source code. I spent a bit of time with their code, but it was developed on Linux and I had some problems getting it to work on Windows properly. My “I’ll just take a few hours and see where I get” time was gone, and still no easy solution. There were some other interesting bits out there, like the article in GPU Pro 2, Practical Morphological Anti-Aliasing, with even a github project, but there were different versions for DX9 and 10 (and not OpenGL), lots of files involved, and I didn’t want to get involved. Even Humus had a code sample, but I was still a bit shy to committing more time. (Also, his needs geometric information, and I wanted to antialias NPR edges formed by dilation, i.e., image processing, which have no underlying geometry).

Then the FXAA shader code was released: well-commented, with clear integration instructions, just needs a color buffer, and all in one shader file. FXAA is not the solution to all of life’s problems (or is it?), but for me, it’s wonderful. It took me all of an hour to fold into our system as a shader (and then another three debugging why the heck it wasn’t registering properly – our shader system turns out to be very particular about path names). The code runs on just about everything and has extensive comments. There are control knobs for the fiddlers out there, but I haven’t messed with these – it looks great out of the box to me.

So, after all that breathless buildup, here’s the punchline:

On the left is your typical jaggy image, on the right is FXAA. Sure, it’s not perfect – nearly-vertical lines can look considerably better with a wider edge search area (as seen in MLAA), dropouts could be picked up by supersampling or MSAA, thin lines can have problems – but this shader gives a huge improvement with no extra samples, and just one pretty-quick pass (plus – full disclosure – a preprocess of computing the luminance/luma (grayscale) and shoving it in the alpha channel). Less than 1 millisecond cost per frame on a GTX 480? Works on sRGB and linear? Code’s in the public domain? Sign me up!

See lots more examples on Timoty Lottes’ page. Read his whitepaper for algorithm details and his newer posts for tweaks and improvements. An easy-to-use demo of an earlier version of his shader can be downloaded here – just hit the space bar to toggle FXAA on and off. Enjoy!

How to make money with your GPU

You’ve probably heard about bitcoins by now, the currency of cryptoanarchist libertarian computer geeks or something. It turns out that GPUs are particularly good at mining bitcoins, compared to CPUs: check out this chart – the key factor is Mhash/sec (though Mhash/Joule is also an entertaining concept). The most interesting page (for me) at the site is their explanation of why a GPU is (so much) faster than a CPU for this task. Not a shocker for anyone reading this blog; we all know that GPGPU can rip through certain tasks at amazing speeds. What’s more interesting to me is how and why one IHV’s GPUs are considerably faster than the other’s. I won’t spoil the surprise here, see the page to learn more.

Loosening of ACM’s copyright policy

We’ve talked about this before, how ACM’s copyright policy stated that they, not you, control the copyright of any images you publish in their journals, proceedings, or other publications. For example, if your hometown newspaper wants to publish a story of “local boy makes good” and wish to include samples of your work, they needed to ask the ACM for permission (and pay the ACM $28 per image). Not a huge problem, but it’s a bureaucratic roadblock for a reasonable request. Researchers are usually surprised to hear they have lost this right.

While it was possible to be assertive and push to retain copyright to your images (or even article) and just grant ACM unlimited permission – certainly firms such as Pixar and Disney have done so with their content – the default was to give the ACM this copyright control.

James O’Brien brought it to our attention that this policy has been revised, and I asked Stephen Spencer (SIGGRAPH’s Director of Publications) for details. His explanation follows.

ACM has recently changed its copyright policy to include the option, under certain circumstances, of retaining copyright on embedded content in material published by ACM. Embedded content can now fall into one of three categories: copyright of the content is transferred to ACM as part of the rest of the paper (the default), the content is “third-party” material (not created by the author(s)), or the content is considered an “artistic image.”

The revised copyright form includes this definition of “artistic images”:

“An exception to copyright transfer is allowed for images or figures in your paper which have ‘independent artistic value.’ You or your employer may retain copyright to the artistic images or figures which you created for some purpose other than to illustrate a point in this paper and which you wish to exploit in other contexts.”

The ACM Copyright Policy page also documents this change in policy.

ACM’s electronic copyright system is being updated to implement this change; authors who wish to declare one or more pieces of embedded content in their papers as “artistic images” should contact Stephen Spencer (at <spencer@cs.washington.edu>) to receive a PDF version of the revised copyright form.

The copyright form includes instructions for declaring embedded content as “artistic images,” both in your paper and on the copyright form.

—-

Note that this change is “going forward”; if you have already given ACM the copyright, you cannot get it back. Understandable, as otherwise there could be a flood of requests for recategorization.

I’m happy to see this change, it is a good step in the right direction.

OpenGL Insights: Call For Authors

Here’s a book CFP, proposals due right after SIGGRAPH. I have to admit, I was a little skeptical when I heard of this as a book idea. However, OpenGL truly is undergoing a resurgence as of late. Not so much on desktops and laptops, though more games are indeed getting made for Macs. Marc DeLoura has a good article on engines in “Game Developer,” May 2011, noting that 15% of traditional “big game” developers plan on Mac version of their games, vs. a mere 2% in 2009. As it is, most every serious game engine is cross-platform, so OpenGL’s special features (and bugs) are not so vital to engine users. Rather, the handheld market is where OpenGL is the only game in town. So, knowing how to make this API sing is pretty vital if you’re working in that area.

The editors: Patrick Cozzi you probably don’t know (yet), though I did point earlier to a poster for this year’s SIGGRAPH that he coauthored (it’s a clever technique). Among other things, he’s first author on a book that’s not out yet, but will be by SIGGRAPH: 3D Engine Design for Virtual Globes (you can download book samples and the code). Christophe Riccio you may have heard of if you work with the OpenGL SDK. He maintains the OpenGL Samples, GLM (math), and GLI (imaging). These guys look like good people for the job: energetic and intelligent. So, here’s the CFP – you can comment on it at their blog. Me, just reading their list of topics of interest, I’ll get a copy even if they get articles on just a very few of these. If $50 (or whatever) saves us a day of going down a wrong path, it’s worth it.

It is with great enthusiasm that we invite you to contribute to OpenGL Insights, a book containing original articles on OpenGL, OpenGL ES, and WebGL techniques by the OpenGL community and for the OpenGL community: from game programmers to web developers to researchers. OpenGL Insights will be published by A K Peters, Ltd. / CRC Press in time for SIGGRAPH 2012.

Given the wide array of OpenGL platforms, from Mac desktops to Android phones to web browsers, we invite you to submit article proposals on all aspects of OpenGL development, including performance tuning, recent GL features/extensions, application architecture, vendor-specific techniques, WebGL, and interoperability with other APIs. We are interested in proposals based on your unique real-world experience using OpenGL. Some ideas include:

  • OpenGL performance, for example:
    • Best performance practices for using vertex buffers
    • Best performance practices for texture streaming
    • Performance and memory profiling techniques
    • 64-bit performance considerations
    • Multithreading with OpenGL
  • Modern OpenGL 3 and 4 programming, for example:
    • Introduction to tessellation
    • Image load and store
    • Programmable multisampling
    • Using shader subroutines effectively
    • Managing uniform data
    • Strategies for debugging OpenGL applications
  • Application architecture, for example:
    • Porting between Direct3D and OpenGL
    • Writing portable code between OpenGL, OpenGL ES, and WebGL
    • Designing an OpenGL-based graphics engine
    • A testing framework for OpenGL applications
    • Shader architecture best practices, e.g., shader binaries and separate shaders
    • Cross-platform programming with OpenGL
    • Tools, libraries
  • Vendor-specific techniques, for example:
    • Understanding and optimizing for specific hardware and driver implementations: AMD, Apple, ARM, Imagination Technologies, Intel, NVIDIA, Qualcomm, S3 Graphics, etc.
    • Bindless Graphics: GL_NV_shader_buffer_load and GL_NV_vertex_buffer_unified_memory
    • How VAO works on AMD drivers
    • Taking advantage of deferred tile rendering on PowerVR
    • How GLSL compiler works
    • Understanding multithreaded OpenGL drivers
  • OpenGL ES, for example:
    • Best practices for targeting both desktop and mobile devices
    • Targeting multiple mobile device platforms
    • Developing with power consumption in mind
    • Differences between desktop and mobile devices
  • WebGL, for example:
    • Introduction to WebGL for web developers
    • Introduction to WebGL for OpenGL developers
    • Optimizing WebGL applications
    • Writing large-scale software in JavaScript
    • Understanding web browser implementations of WebGL
    • WebGL interoperability with WebCL
  • Interoperability, for example:
    • Hybrid OpenGL and OpenCL/CUDA rendering pipelines
    • Working with both OpenGL and Direct3D
    • OpenGL interoperability with OpenCL and CUDA
  • Inspirational thoughts and experiences:
    • OpenGL’s 20th anniversary: history and evolution
    • ARB members and OpenGL developers interviews
    • OpenGL software making of
    • Daily programmer experiences with OpenGL

These are, of course, examples. Please don’t feel limited to these areas.

The planned schedule is:

August 15, 2011 Proposals due
September 1, 2011 Authors selected
November 1, 2011 Articles due
December 1, 2011 Peer review feedback due
December 15, 2011 Revised articles due, all articles sent to publisher
January 1, 2012 Supplemental material due, e.g., videos, source code, etc.
SIGGRAPH 2012 Book released

Please send proposals to editors@openglinsights.com using this example proposal as a template by August 15th.

Proposals should include the title, your name and affiliation, a one-page abstract, and anything else you feel helps convey your article such as related images or references. Proposals must demonstrate the author’s real-world OpenGL experience and ability to write clearly. Proposals can have multiple authors, and a single author can submit multiple proposals. There is no required article length, but we expect most articles will be 5-20 pages. Example code can be written in any language on any platform.

Please feel free to contact us for additional discussion. We’re looking forward to putting together a valuable book for the OpenGL community.

Thanks,

Patrick Cozzi and Christophe Riccio, Editors

www.openglinsights.com

I want this to be the best book ever

I just learned of a new book coming out: “Real-Time Shadows“, by an excellent group of researchers (a little more info here). I assume this book will be based on the authors’ 148-page “Casting Shadows in Real Time” course notes and related publications. This subject deserves its own book. There are enough interesting principles and so many variants and subtleties that I’m happy to hear this topic will get thorough coverage. Our book page is updated.

Looking around at other book-related resources, I noticed some interesting bits. John Vince’s “Geometry for Computer Graphics: Formulae, Examples and Proofs“, from 2005, has been reissued in a softcover edition. It’s pricey, as Springer books can be, and weighs in at just 364 pages, but it’s an information-packed volume. It’s a kind of book you rarely see now, one with a dense collection of formulae, like CRC Press used to specialize in. Google Books sample here. Some of it’s pretty tangential to computer graphics – normally I don’t need proofs about things like the opposite angles of a parallelogram being equal – but it’s fun to page through: “Someday I’d love to find a use for that coiled ring equation”. Whether you’ll ever need 1/100th of the information in this book depends on you. It seems like a good fit for demoscene programmers who want procedural functions and model generation, for example. Anyway, something to see if your university library has, just to page through and know it exists.

Speaking of geometric resources, I was sad to see the site geometryalgorithms.com appears to be defunct. What’s key to remember in such cases is that there’s the Wayback Machine. Just put in a dead URL and more times than not this site will have a copy. So the Geometry Algorithms site lives on here! Luckily, math doesn’t really rot, so the articles are still worthwhile. The bad news is that a few of the figures are missing.

For technical book authors, I ran across this interesting little tool: Detexify2. Draw the symbol you need, it will show you likely matches and what LaTeX you need. I’ve found it’s pretty accurate, though seemed to have problems with “not equals” half the time I drew that symbol as a test. Anyway, it’s probably no more efficient than just looking it up here or here, but is more fun.

Last resource for the (mothers’) day: so you want to explain the basics of computer graphics to your mom. Frédo Durand’s six page introduction is not a bad place to start. At the least, you can use the figures at the end to explain ideas.

Emerald, Jade, and ummm, Diopside?

Many moons ago when the world was young(er), Jim Arvo asked a few other graphics guys what we thought the next volume of “Graphics Gems” should be. After batting around “More Graphics Gems”, “Son of Graphics Gems”, “Revenge of the Graphics Gems” and other alternatives, he finally went with the consensus: number them, even though the first one is not numbered “1”. This is now the norm: GPU Gems, Game Programming Gems, Game Development Tools have all gone this route. The ShaderX/GPU Pro series(es) have gone with pushing the numeral up top, e.g., ShaderX3. Which I guess is officially read as “ShaderX cubed,” but of course everyone calls it “ShaderX Three.” Some have gone a different route, like the “Jim Blinn’s Corner” books were differentiated by the subtitles and by strikingly different cover colors.

Along the way there has been the occasional rough patch with book titles. For example, ShaderX2 is actually two very different books, “Introductions and Tutorials” and “Tips and Tricks.” The “Best of Game Programming Gems” book is excerpted from the first six books, leaving the seventh and eighth in a funny state – “what am I, chopped liver?” There seems to be a tiny hint that there will be a ninth volume, but there’s not a whiff of any call for participation elsewhere, e.g. not on the official series page.

I bring up this topic of naming because there’s now a new axis being developed: gem names. I noticed this a few months ago, and in updating the book page today, it’s official: the new GPU Computing Gems series truly is going with calling their first volume Emerald, the second volume Jade. Or is it vice versa? I honestly had to check.

I have to question this naming concept a bit, especially given the gems’ colors, but I guess the damage is done. “You know, the GPU Computing Gems book edited by Hwu, the one named after a green gem, with the green molecular structure on the cover, came out in 2011?” That accurately describes both volumes. When I first ran across this pair of books, I thought it was a bug or misprint, that there was only one book but with two slightly-different entries, sort of like “Harry Potter and the Philosopher’s/Sorceror’s Stone”. I’m not a marketing genius, but this naming scheme so far is not working for me. Which is a pity, as it does a disservice to the contributors by confusing the message. So, yes, there really are two different volumes, with Emerald out now and Jade coming out in August.