-
Notifications
You must be signed in to change notification settings - Fork 6
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
calculate each reflection separately
This is a test to see if we can split the calculation of a sample point into multiple kernel-calls (one per reflection slice). The reason is, that our current code computes all reflection slices in a single huge array. This old style had several disadvantages that could be fixed: - the array `numberOfReflectionSlices` is **huge**. As big as indicesOfPrisms, and so it is part of the bottleneck for the number of rays. - removing this array cuts our memory requirements almost by 50% (for really high ray numbers) - the kernel does not have to do the memory lookup to find the correct reflection_i (all reflections are in the same plane anyway) - the arrays `numberOfReflectionSlices` and `raysPerPrism` are actually linearized 2D arrays that contain all the reflection planes. This leads to more difficult code while we do the `mapRaysToPrisms`. - if there is only one reflection plane at a time, this makes it much easier to split the numbers of rays even further to allow more rays in total (see #2). - the resulting code is more maintainable This is nice and all, but splitting the reflections might introduce some problems: - if there are reflections, we will do a lot more kernel calls and each of those might be quite small. So maybe the GPU is not utilized as much. Previously, everything was done in 1 huge kernel call. - since we don't know how many rays there are in each plane, we have to call thrust::reduce in each iteration. - since we need multiple ray schedules (one for each reflection plane), we also need to call the mapRaysToPrisms in each iteration. All in all, the performance implications need to be tested. I believe that this commit can improve long-term code quality and will directly enable #2. But if the performance suffers, we might need to code some workaround (maybe use the split functionality only for really high ray numbers where the tradeoff is not so bad and we really NEED it).
- Loading branch information
Showing
5 changed files
with
86 additions
and
106 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters