- 29 7月, 2021 2 次提交
-
-
由 Matt Pharr 提交于
-
由 Matt Pharr 提交于
The previous implementation repeatedly assumed that Allocators were thread safe; this is not required for std::pmr allocators, but happened to be the case when the default allocator is used on the CPU (since new/delete are thread safe.) For the GPU, the CUDATrackedMemoryResource was also thread-safe, but it also included some per-thread caching that doesn't really belong in a memory resource. Therefore, the WavefrontPathIntegrator (and friends) now no longer assume that allocators are thread-safe, but instead explicitly use per-thread allocators in parallel code. CUDATrackedMemoryResource is simplified to be just a memory resource, and now we use a std::pmr::monotonic_buffer_resource when we actually want chunked allocation.
-
- 22 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 21 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
Issue #131.
-
- 20 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 14 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
This way, we can not increment the ray depth when it passes through a surface that markes the boundary between different media, matching the behavior of the regular CPU path. In particular, this fixes some undesirable noise in the wavefront integrator (and different behavior from the regular CPU path) that was due to the ray depth being incorrectly tracked in scenes with participating media and then Russian roulette inadvertently being applied after the very first surface intersection.
-
- 13 5月, 2021 2 次提交
-
-
由 Matt Pharr 提交于
In turn, this gives us valid dzdx and dzdy values with GBuffer film.
-
由 Matt Pharr 提交于
Now a MultiWorkQueue templated on the phase function type is used for enqueuing work items for sampling direct/indirect lighting in media. With Henyey-Greenstein as the only phase function currently available, this reduces to the previous behavior, but it makes it easier to add new phase functions in the future. Also piped through time in a few places it was missing in the medium-related work queues.
-
- 06 5月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
Assorted cleanups; no functional changes.
-
- 03 5月, 2021 2 次提交
-
-
由 Matt Pharr 提交于
-
由 Matt Pharr 提交于
* Generalize GPU rendering path to run on both CPU and GPU Now we have a WavefrontIntegrator that can both run on the CPU (backed by ParallelFor() for parallelization and pbrt's aggregates for ray intersection acceleration) and on the GPU (backed by GPUParallelFor() for parallelization and OptiX for ray intersection on NVIDIA GPUs.) Beyond generalizing the code, this refactor allows CPU-side debugging and testing of the wavefront integrator. Doing so allows further isolation of the GPU-specific code into a few source files, now just ~2.5k lines of code. This includes a bug fix in the wavefront medium code to resolve MixMaterials to one of their constituent materials before enqueuing material evaluation and shading work. Note that on the CPU, the wavefront integrator runs 5-10x more slowly than pbrt's regular CPU integrators, so it is not recommended for regular use... Co-authored-by: NWenzel Jakob <wenzel.jakob@epfl.ch>
-
- 13 2月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 08 2月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
This is @pierremoreau's suggested fix for issue #100. I can confirm everything still works on Linux with this fix, but have not checked the Windows+GPU build.
-
- 09 1月, 2021 1 次提交
-
-
由 Matt Pharr 提交于
-
- 25 11月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
-
- 24 11月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
-
- 19 11月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
Instead, just push those rays onto the ray queue for the next ray depth. This gives up to a 5% speed up for scenes with participating media.
-
- 18 11月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
No functionality changes. Cleaned up some of the GPU *WorkItem definitions.
-
- 17 11月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
-
- 15 11月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
-
- 01 9月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
This lets the Windows GPU build run efficiently, without the hack of synchronizing after each kernel. There, the GPUPathIntegrator is now stored in CPU memory; in turn, the GPU kernels capture *this by value so that they can access the values of members.
-
- 23 8月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
Resolve MixMaterials immediately in the closest hit shader. Among other things, this fixes bump mapping with them. Also, issue error messages for MixMaterial cases not handled on the GPU path.
-
- 22 8月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
-
- 18 8月, 2020 1 次提交
-
-
由 Matt Pharr 提交于
-