Minimizing the ray payload for GPU was definitely part of why we didn't add that. (Though it does pain me sometimes that we don't have it in there.)
And, PBR being a textbook, we do save some things for exercises and I believe that is one of them; I think it's a nice project.
A final reason is book length: we generally don't add features that aren't described in the book and we're about at the page limit, length wise. So to add this, we'd have to cut something else...
If this is what you’re asking: there are (perhaps too discreet) links at the bottom of each page to Amazon and MIT Press to purchase the physical book.
In the 4th edition, there's no support for RGB rendering--it's always and only spectral.
And admittedly the spectral rendering option in earlier editions wasn't great. We didn't always correctly distinguish between illuminants and reflectances, used a fixed binning of wavelength ranges (vs stochastically sampling wavelengths), and had a fine-but-not-state-of-the-art RGB -> Spectrum conversion algorithm. All of that is much better / state of the art in the 4th edition.
The physical book was published 6 months ago, and per agreement with the publisher, the contents are now freely available online as well.
The book's blurb:
Photorealistic computer graphics are ubiquitous in today's world, widely used in movies and video games as well as product design and architecture. Physically based approaches to rendering, where an accurate modeling of the physics of light scattering is at the heart of image synthesis, offer both visual realism and predictability. Now in a comprehensively updated new edition, this best-selling computer graphics textbook sets the standard for physically based rendering in the industry and the field.
Physically Based Rendering describes both the mathematical theory behind a modern photorealistic rendering system and its practical implementation. A method known as literate programming combines human-readable documentation and source code into a single reference that is specifically designed to aid comprehension. The book's leading-edge algorithms, software, and ideas—including new material on GPU ray tracing—equip the reader to design and employ a full-featured rendering system capable of creating stunning imagery. This essential text represents the future of real-time graphics.
The author team of Matt Pharr, Greg Humphreys, and Pat Hanrahan garnered a 2014 Academy Award for Scientific and Technical Achievement from the Academy of Motion Picture Arts and Sciences based on impact the first and second editions of the book had on how movies are made. The Academy called the book a “widely adopted practical roadmap for most physically based shading and lighting systems used in film production.”
Of the book, Donald Knuth wrote “This book has deservedly won an Academy Award. I believe it should also be nominated for a Pulitzer Prize.”
> I would expect a shader could do a credible job of emulating all of these.
The key is that it is necessary to know the coherence of the light arriving at the surface in order for a shader to accurately model reflection. (See Figure 13 in the paper for an example that shows how this matters.) Otherwise a shader would have to make up a guess about the light's coherence.
The main contribution of the paper is a much more efficient approach than was known before for finding light's coherence, even in the presence of complex light transport (multiple reflections, etc), and one that further allows the application of traditional ray-optics computer graphics techniques for sampling light paths through the scene. (For example, previously if one wanted to track coherence, it was necessary to sample light paths starting from the light sources rather than from the camera, as is done in path tracing.)
First, the cost is 2 FMAs * the cost of generating 2 random numbers * the number of rejection sampling iterations. On average, you reject (4-pi)/4 ~= 0.25 of the time. However, if you're running on a GPU in a warp (or the equivalent) of 32 threads, then you pay the cost of the maximum number of rejections over all the threads.
The bigger issue is that a direct mapping from [0,1]^2 to the disk, as is described in this tweet, if you have well-distributed uniform samples in [0,1]^2, you get well-distributed samples on the disk. Thus, stratified or low discrepancy samples in [0,1]^2 end up being well distributed on the disk. In turn, this generally gives benefits in terms of error with Monte Carlo integration of functions over the disk.
FWIW that algorithm for uniform floating-point sampling in [0,1] is actually originally due to: Walker, Alastair J. “Fast generation of uniformly distributed pseudorandom numbers with floating-point representation.” Electronics Letters 10 (1974): 533-534.
> Are there alternative tools that focus on rewriting code to maximise performance while keeping error below some configurable bound?
There are! See followup work by @pavpanchekha and others on "Pherbie", which finds a set of Pareto-optimal rewritings of a program so that it's possible to trade-off error and performance: https://ztatlock.net/pubs/2021-arith-pherbie/paper.pdf.
Yeah, about that prediction... Progress continues, but Fall 2021 is more likely for an online edition and then printed copies in the first half of 2022. (I suppose we should update the website.)
> It’s good for linear algebra with long vectors and large matrices, but SIMD is useful for many other things besides that
The main goal in ispc's design was to support SPMD (single program multiple data) programming, which is more general than pure SIMD. Handling the relatively easy cases of (dense) linear algebra that are easily expressed in SIMD wasn't a focus as it's pretty easy to do in other ways.
Rather, ispc is focused on making it easy to write code with divergent control flow over the vector lanes. This is especially painful to do in intrinsics, especially in the presence of nested divergent control flow. If you don't have that, you might as well use explicit SIMD, though perhaps via something like Eigen in order to avoid all of the ugliness of manual use of intrinsics.
> I’m pretty sure manually written SSE2 or AVX2 code (inner loop doing _mm_cmpeq_epi8 and _mm_sub_epi8, outer one doing _mm_sad_epu8 and _mm_add_epi64)
ispc is focused on 32-byte datatypes, so I'm sure that is true. I suspect it would be a more pleasant experience than intrinsics for a reduction operation of that sort over 32-bit datatypes, however.
No, the actual publisher (Elsevier) printed a batch of terrible quality books. This led to our ending our relationship with them. We are in the midst of finding a new publisher for the 4th edition; not repeating that disaster is of great importance to us...
My trusty copy of "What's Where in the Apple", which includes a catalog of where everything is in memory, says that the routine to write the VTOC from its in-memory buffer to disk starts at $AFF8.