The global illumination tech used on monsters university was just standard path tracing with physically-plausible sharers - the first time pixar had used that instead of radiosity caching. Other studios have been using path tracing for years before - pixars lighters are very good however, so the results are very good.
As the original author of that benchmark, I should point out that that was LLVM SVN (unreleased) against GCC 4.8 & 4.9 - I couldn't get GCC 5.0 SVN to build, so it's possible 5.0 will be faster again than LLVM in certain situations.
However, I would also say that generally I've found LLVM is now producing faster code than GCC in most code I've tested both compilers with.
That is very interesting, because LLVM developers themselves admit LLVM generates slower code than GCC (in average). This is plain if you read LLVM Developers' Meeting talks.
I think it is completely possible that LLVM developers are using wrong benchmarks. Benchmarks are mostly SPEC and some large Google C++ codebases; in some sense both are quite atypical. But then, entire problem is to understand how typical codebases look like.
I can hopefully settle this (as a developer of both).
Assuming we stick to x86/x64, nowadays (literally, let's say as of January 2015) GCC and LLVM are within the noise for most people on most code (IE 1-2% of each other).
You can certainly find benchmarks were LLVM does badly. Some are important to some people, some aren't.
It is harder to find benchmarks where GCC does badly.
Small benchmarks can go either way, but for large codebase (especially C++) inliner is more important than just about anything else. So GCC wins, because it has better inliner.
There are many measures of benchmark sizes. One important measure is size of codes that account for 99% of execution time. If your codebase is a million lines but your hotspot is a thousand lines, benchmark result is sensitive to optimization quirks and in some sense benchmark is small.
Would GeometryInstances go directly into an acceleration structure? Surely objects which point to the geometryinstance and each have a worldspace transform are what go in the scene level acceleration structure...
Generally it's advisable to templatize acceleration structures so they can natively cope with triangles, objects and possibly other primitives (spheres and curves) separately.
Right, the instances go into a scene level acceleration structure and for each triangle mesh we build an object level acceleration structure on the triangles. I was planning to do something like a BVH<T: Geometry> so then I don't need a separate BVH type for instances and triangles, since Instance implements the Geometry trait. I'm not sure if there's a better alternative that would help get around the DifferentialGeometry issue since in this case the instance members of geometry types (Spheres, Triangles) and Instances must have the same signature.
Rather ironically, Arnold's standard shader still has bugs meaning its Cook-Torrance microfacet model isn't completely energy conserving at glancing angles...
Interesting. It's been around long enough you'd think they would have worked out those details. I just linked it because I felt it gave the clearest explanation of the concept.
I guess that depends on your definition of 'easily' - you can provide custom allocator s fairly easily. What's more problematic are things like the memory usage patterns of std::vector and std::string. Once you know how they work you can avoid the pitfalls or use custom alternatives.
Things like alignment support didn't come out in g++ until 4.8 [1] but now you could start actually do most of what the EASTL is doing aside from the access to private members
Games and other high performance users generally used to stay away from the STL. Sony had their own version of STL which addressed some of these issues.
You can get around a lot of these issues by reserving the size needed up front, or using a custom allocator with std::vector. Not as easy, but still doable.
The reallocation issue isn't fixable this way however...
- re layout: yes, at the moment there's a widget_matrix which can help with positioning, but I'm also keen to add slightly more friendly functionality into the ui_context: i.e. uic.add_widget(direction, padding, |position|{ /* widget::draw... */ }) or something along these lines. I'm totally open to other suggestions and inspiration too :)
- re draw: this function is actually the only instance of code required for the widget (hence the "immediate-mode"ness), so I'm not too sure what else could be abstracted away (other than some args)!
