Matt Pharr

Baseline for that scene with no area lights: CPU 298MB, GPU 2525 MB. So, CPU is still using about 800 bytes / light, GPU is using ~1180.

...and the light BVH is using 300 bytes / light. Changing the `Image` member of `DiffuseAreaLight` to an `Image *` would save 200 bytes / light. For reasons unclear, reported...

Ah, that's interesting about wildcards. ISTR that on Windows applications have to expand those themselves, while pbrt assumes that the shell does it. I can look into that at some...

I'm no expert on Windows command line processing, but the issue may be that pbrt gets the arguments on Windows via `GetCommandLineW()` (https://github.com/mmp/pbrt-v4/blob/07d4749cf1cb0244d32a030819dbf6fce93cdd6b/src/pbrt/util/args.cpp#L18); maybe the `setargv.obj`/`wsetargv.obj` trick doesn't apply in...

Thanks for working on this! I just pushed an update to the CMakeLists.txt file (in 995d9e0c2c7094361f6f20cc900ddff7e84af977) that addresses the second issue (in a slightly different way). I am curious why...

Pixels are indeed square. It uses a standard perspective projection with the specified FOV.

@pierremoreau those times were on Linux (3090) and Windows (2080), indeed. I should add that I was rendering with 64spp for those, which probably explains your timings! Nevertheless, your stats...

Hm, interesting... For crown with `--spp 64`, I am seeing 6.6s on Linux with a 3090 and 12.7s in Windows with a 2080 Ti--that's roughly what I'd expect given those...

Also, OptiX validation only has about a 5% perf. impact on Linux, which presumably explains why I didn't notice any issues when I enabled it (when the Windows GPU path...

This is "interesting" in your numbers: ``` Reset queues before tracing rays 12928 launches 1880.37 ms / 6.1% (avg 0.145, min 0.003, max 11.623) ``` (And 7.2% in your second...