09-30-10 - Coder News

Ignacio wrote a nice article on GPU radiosity via hemicubes . I always wanted to try that, I'm jealous.

I suspect that you could be faster & higher quality now by doing GPU ray tracing instead of render-to-textures. The big speed advantage of GPU ray tracing would come from the fact that you can make the rays to sample into your lightmaps for lots of lightmap texels and run them all in one big batch. Quality comes from the fact that you can use all the fancy raytracing techniques for sampling, monte carlo methods, etc. and it's rather easier to do variable-resolution sampling (eg. start with 50 rays per lightmap texel and add more if there's high variance). In fact, you could set up all the rays to sample into your lightmap texels for your whole world, and then run N bounces by justing firing the whole gigantic batch N times. Of course the disadvantage to this is you have to implement your whole renderer twice, once as a raytracer and once for normal rendering, avoiding that is the whole point of using the hemicube render to texture method.

Was talking to Dave and randomly mentioned that I thought the new Rvalue references were not that interesting because you can basically do everything they give you using RVO and swaps. But then I did some more reading and have changed my mind. Rvalue references are awesome!

Want Speed Pass by Value. � C++Next (Dave Abrahams series on value semantics)
C++ Rvalue References Explained (good intro)
A Brief Introduction to Rvalue References (Howard E. Hinnant, Bjarne Stroustrup, and Bronek Kozicki)
Rvalue References C++0x Features in VC10, Part 2 - Visual C++ Team Blog - Site Home - MSDN Blogs
rvalue reference (the proposal document)
InformIT C++ Reference Guide The rvalue Reference Proposal, Part I

Basically it lets you write templates that know an object is a temporary, so you can mutate it or move from it without making a copy. I think one problem we sometime have as coders is that we think about our existing code and think "bah I don't need that" , but it's only because we have been so conditioned not to write code in that way because we don't have the right tools. C++0x makes it possible to do things in templates that you always wished you could do. That doesn't necessarily mean doing lots more complicated things, it means doing the little things and getting them exactly right. "auto" , "decltype" , "[[base_check]]", etc. all look pretty handy.


blq said...

Not quite on topic, and perhaps you've already heard about it but what do you think about the new Google image (compression) format, WebP?
...blogpost hint :)

cbloom said...

I'd like some more information, but my first reaction is that they are exaggerating the benefits and it sort of sucks to be introducing yet another format which is not feature-rich or a big improvement.

The VP8 I-frame codec is something like 10 years old, and results that I've seen for it are not compelling vs. JPEG. (it's significantly worse than H264's I frames for example, and even that only barely beat JPEG in the working band of JPEG; if you try to push JPEG to sizes it isn't supposed to handle then H264 looks a lot better)

Also comparing size vs. baseline JPEG is rather unfair, you should compare vs. Stuffit repacked JPEG or something modern like that which uses the same JPEG DCT coefficients but puts a better entropy coder on the back end.

won3d said...

More infos here:


cbloom said...

Wait what?

That looks like a classic example of using lots of statistics to make something look rigorous when it's completely not.

They're re-jpegging jpegs? Why are they using PSNR to study perceptual image formats? How about some actual modern coders in the study? How about doing some human visual tests if you're gonna be serious?

Jeff Roberts said...

Dude, if you can't read the Rvalue References Explained paper without realizing that C++ is done, done, done, then you are crazy with a capital C. I mean:

"So as you can see, in order to really use rvalue references and move semantics in an optimal way, you need to fully understand and take into account today's compilers' "special effects" such as return value optimization and copy elision.... The details get pretty subtle."


"C++0x, by contrast, introduces the following reference collapsing rules:

* A& & becomes A&
* A& && becomes A&
* A&& & becomes A&
* A&& && becomes A&&


"the argument of the factory function gets passed on to A's constructor through two levels of indirection, both by reference. Moreover, A's constructor sees as its argument an expression that is declared as an rvalue reference and does not have a name. By the no-name rule, such a thing is an rvalue. Therefore, A's constructor gets called on an rvalue. This means that the forwarding preserves any move semantics that would have taken place if the factory wrapper were not present.

Note that for the forwarding to preserve move semantics, it was necessary to explicitly specify Arg as the template argument of std::forward. Had we not done this, std::forward would have deduced its template argument to be X&, because its argument, having a name, is an lvalue. Therefore, the actual implementation of std::forward adds a little extra code whose only effect is to force clients to explicitly specify the template argument..."

They are done. They are all fired.

frog said...

I've been using R-value references in VS2010 for awhile now(along with those other features you mentioned), and have found them very useful. Once you start using them they are fairly simple to understand.
The most useful new C++0x feature for me has been lambda, lets you write some very functional style code without all the verbosity of C++ 03.

Tom Forsyth said...

I made it to page 4 of Becker's explanation just fine. Then this:

"std::move is a very simple function. Unfortunately, though, I cannot show you the implementation yet. We'll come back to it later."

I'm going to need a bigger boat.

old rants