| 01:48.21 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 02:41.57 | Notify | 03BRL-CAD:starseeker * 70018 (brlcad/trunk/src/other/openscenegraph/CMakeLists.txt brlcad/trunk/src/other/openscenegraph/CMakeModules/UtilityMacros.cmake): We don't appear to actually be using the LOCATION property for anything in our build of osg |
| 03:15.38 | Notify | 03BRL-CAD:starseeker * 70019 brlcad/trunk/src/other/PoissonRecon/CMakeLists.txt: Doesn't seem to be any reason in this file for 0053 to be set to old |
| 03:26.06 | Notify | 03BRL-CAD:starseeker * 70020 (brlcad/trunk/CMakeLists.txt brlcad/trunk/misc/svn2git/svn2git/CMakeLists.txt and 29 others): Bump to 3.0.2 across the board, remove older policy logic. Looks like the only remaining dependency on any OLD policy setting is a test in Tcl that needs 0053 set to old (quoting rules). This sets the stage for doing some experiments with the new TARGET build-time evaluation expressions, which |
| 03:26.08 | Notify | may (not sure yet) have the potential to simplify some of the build logic. |
| 03:26.10 | Notify | ... |
| 03:42.28 | Notify | 03BRL-CAD:starseeker * 70021 brlcad/trunk/src/other/tcl/CMakeLists.txt: update quoting for strstr test |
| 04:41.11 | *** join/#brlcad deep-book-gk_ (~1wm_su@159.122.132.44) |
| 04:42.00 | *** part/#brlcad deep-book-gk_ (~1wm_su@159.122.132.44) |
| 07:02.34 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) |
| 15:20.49 | *** join/#brlcad yorik (~yorik@2804:431:f720:4929:290:f5ff:fedc:3bb2) |
| 18:12.54 | brlcad | starseeker: answering your question from a while back, yes https://sourceforge.net/p/brlcad/code/HEAD/tree/rt%5E3/trunk/src/g3d/ has mafm's camera code |
| 18:12.55 | i5o | [ BRL-CAD / Code / [r70024] /rt^3/trunk/src/g3d ] |
| 18:14.52 | brlcad | starseeker: and looking through, it does look like it was a custom safe-to-use implementation -- coupled to ogre 3d types, but trivial to switch that to vmath types |
| 18:15.07 | brlcad | forgot how nice that all was, lots of good app structure... |
| 18:52.44 | *** topic/#brlcad by brlcad -> This channel is for BRL-CAD and open source CAx discussion! Logs @ http://infobot.rikers.org/%23brlcad/ |
| 19:31.39 | *** join/#brlcad KimK (~Kim__@2600:8803:7a81:7400:68cc:f967:6b4c:bb5f) |
| 20:21.20 | *** join/#brlcad Notify (~notify@104.225.5.10) |
| 20:21.26 | Notify | 03BRL-CAD:starseeker * 70022 brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Simplify the IS_SUBPATH function logic using SUBSTRING. Not actually a significant performance improvement, but fewer lines and easier to follow. |
| 20:21.28 | Notify | 03BRL-CAD:starseeker * 70023 NIL: delete empty directories |
| 20:21.30 | Notify | 03BRL-CAD:starseeker * 70024 brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Do some refactoring of CMAKEFLAGS tracking function |
| 20:22.05 | Notify | 03BRL-CAD:starseeker * 70025 brlcad/trunk/src/tclscripts/checker/CMakeLists.txt: Add TODO to CMAKEFILES list |
| 20:22.07 | Notify | 03BRL-CAD:starseeker * 70026 (brlcad/trunk/db/CMakeLists.txt brlcad/trunk/db/nist/CMakeLists.txt and 56 others): Start preparing the ground work for a distcheck introspection that is based entirely on files - no specification of directories. This will be both to simplify the logic and to increase robustness for the non-svn distcheck case - if we have all files listed explicitly, svn is not strictly needed to do a |
| 20:22.09 | Notify | full source repo verification. For the moment this will break distcheck, but need to checkpoint before the next stage. |
| 20:22.11 | Notify | ... |
| 20:22.16 | Notify | 03BRL-CAD Wiki:Mariomeissner * 10145 /wiki/User:Mariomeissner/logs: |
| 20:22.18 | Notify | 03BRL-CAD Wiki:Mariomeissner * 10146 /wiki/User:Mariomeissner/logs: |
| 20:53.22 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 21:03.41 | Notify | 03BRL-CAD:starseeker * 70027 (brlcad/trunk/misc/CMake/BRLCAD_Util.cmake brlcad/trunk/misc/CMake/source_archive_setup.cmake.in): This may get distcheck running again... needs more testing |
| 23:11.15 | brlcad | super relevant paper .. I love the architecture simplicity: http://tabellion.org/et/paper17/MoonRay.pdf |
| 23:11.57 | brlcad | vectorized a production tracer just like rt, from DFT to BFT |
| 23:17.01 | Stragus | When I tried making coherent ray queues on GPUs, to trace coherent bundles, I hit a wall on global memory bandwidth. And the on-chip shared memory wasn't large enough to store much |
| 23:17.22 | Stragus | Perhaps the L2 cache of CPUs can manage something better |
| 23:18.12 | brlcad | paper utilized 4-way simd, cpu |
| 23:18.32 | brlcad | well, n-way, but the intel box they were using was 4-way |
| 23:19.08 | Stragus | Right. And cache misses are far more catastrophical on CPUs than GPUs |
| 23:19.09 | brlcad | it was a production rendering system, so for them, most of the time was in the shading/texturing phase -- there is where they got the largest gains |
| 23:19.57 | Stragus | Ah yes, of course! So the performance bottleneck wasn't coherent tracing in the scene, it was the texture memory access in the ray hit callback |
| 23:20.24 | Stragus | It makes sense then. Because my experiments with coherent tracing were inconclusive regarding the performance of ray tracing itself |
| 23:22.58 | Stragus | ("coherent tracing" as in continuously rebuilding coherent bundles from incoherent rays, not primary coherent rays) |
| 23:23.03 | brlcad | yeah, their engine used embree under the hood for intersection |
| 23:24.12 | Stragus | Your bullet rays tend to be highly coherent anyway. :) For stuff like radio wave propagation, not so much |
| 23:27.52 | brlcad | just heard a fantastic talk yesterday focused on incoherent rays, completely different approach |
| 23:29.06 | Stragus | Ah? Different from buffering them and making coherent bundles? |
| 23:30.15 | brlcad | yes, because he wanted performance all the way down to single rays too (actually the focus) |
| 23:30.48 | brlcad | making a single ray trace as fast as possible |
| 23:31.26 | Stragus | When I did ambient occlusion or global illumination, I just _made_ the secondary rays coherent. Neighbor primary rays generate secondary rays with coherent vectors, with an appropriate probability "weight" |
| 23:31.41 | Stragus | So what's different about that? |
| 23:32.18 | brlcad | because with a single ray, there's no other rays to make it (more) coherent |
| 23:32.49 | brlcad | except for making it internally do things you might not think to otherwise |
| 23:33.51 | Stragus | Like testing bundles of 8 triangles in paralle, instead of 8 rays against one triangle? |
| 23:34.06 | Stragus | One ray against bundles of 8 triangles, that is |
| 23:34.24 | brlcad | sort of |
| 23:34.53 | brlcad | more like one ray, bundling the traversal(s), against triangles |
| 23:35.06 | brlcad | he used compression tricks, simd, and branchless coding |
| 23:35.30 | brlcad | very nice speedups |
| 23:35.43 | Stragus | Well, I'm both curious and skeptical |
| 23:36.12 | Stragus | Testing bundles of 8 triangles is obviously good for incoherent rays (been there, done that). But... compression? |
| 23:36.35 | brlcad | compression of the traversal |
| 23:36.36 | Stragus | Besides shifted 16 bits traversal offsets between nodes of the acceleration structure (done that too) |
| 23:36.41 | brlcad | I'll see if I can get the presentation |
| 23:37.25 | Stragus | I order the content of my raytracing graphs so that you can jump between sectors and nodes with a 16 bits << 4 offset |
| 23:37.35 | Stragus | I guess that counts as compression |
| 23:39.29 | brlcad | so instead of jumping between sectors, I think it would be kind of like evaluating multiple sectors simultaneously |
| 23:39.49 | brlcad | no way I can describe it with justice, still haven't read the paper, but the talk was very compelling, interesting |
| 23:40.51 | brlcad | branch-free traversal was a big point, no conditionals so the ray evaluates everything along the path (faster than evaluating and terminating conditionally) |
| 23:42.17 | Stragus | Hrm. You end up fetching a _lot_ of pointless memory if the ray keeps going when it could just stop |
| 23:43.03 | Stragus | Unless you mean branchless testing of the triangles from a single sector. That's all right, it's already pulled into cache |
| 23:43.33 | brlcad | no, branchless traversal (don't recall if triangle testing was also branchless) |
| 23:44.07 | Stragus | I am totally unconvinced by that |
| 23:44.42 | Stragus | If I'm looking at a wall, I want my rays to stop there. Not continue to fetch geometry from the street outside |
| 23:45.35 | brlcad | that was the trick, though -- I don't think he fetched the geometry unnecessarily, at least not beyond a "traversal bundle" which might have been a bit past |
| 23:46.11 | Stragus | Sounds like branchless testing of all triangles into a sector, or something similar |
| 23:47.57 | Stragus | I remember trying branchless triangle testing many years ago... It was slower everywhere, except on the Pentium 4 due their absurd branch misprediction penalty |
| 23:49.05 | Stragus | Although if you are testing bundles of 8 triangles for a ray, rather than 8 rays for a triangle, then you definitely want branchless |
| 23:54.29 | Stragus | It is an intereting thought to have a whole CUDA warp test 32 triangles for a single ray. The graph evaluation cost function would have to be adjusted (fatter sectors, less sectors, lower memory consumption) |
| 23:55.16 | *** join/#brlcad djkonro (~djkonro@129.0.42.239) |
| 23:55.45 | Stragus | Sounds like a waste of processing potential during traversal though (not geometry intersection) |
| 23:56.04 | *** join/#brlcad Notify (~notify@104.225.5.10) |