Editing OpenCL GPGPU Spatial Partitioning Raytracing
From BRL-CAD
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 2: | Line 2: | ||
BRL-CAD has one of the oldest and fastest parallel ray tracing implementations around but we don't currently leverage the GPU. With implicit geometry and constructive solid geometry (CSG) Boolean operations, we also have a very different approach to ray tracing that has its own set of academic challenges. | BRL-CAD has one of the oldest and fastest parallel ray tracing implementations around but we don't currently leverage the GPU. With implicit geometry and constructive solid geometry (CSG) Boolean operations, we also have a very different approach to ray tracing that has its own set of academic challenges. | ||
+ | |||
+ | Your project is to help us introduce a GPGPU pipeline into BRL-CAD using OpenCL. You're welcome to use a library that encapsulates OpenCL. | ||
Currently we use a [[wikipedia:Bounding volume hierarchy|Bounding Volume Hierarchy]] (BVH), an object partitioning scheme, to reduce the amount of intersections that we need to compute on the OpenCL librt. The advantage of the BVH is that it does not compute duplicate intersections, which is typically an issue with spatial partitioning schemes. This allows us to use less per thread memory since we do not require the use of mailboxing . But an issue with the BVH is that it requires computing all the primitive intersections along the ray path. This is an issue in scenes with high depth complexity like Goliath or architectural scenes. | Currently we use a [[wikipedia:Bounding volume hierarchy|Bounding Volume Hierarchy]] (BVH), an object partitioning scheme, to reduce the amount of intersections that we need to compute on the OpenCL librt. The advantage of the BVH is that it does not compute duplicate intersections, which is typically an issue with spatial partitioning schemes. This allows us to use less per thread memory since we do not require the use of mailboxing . But an issue with the BVH is that it requires computing all the primitive intersections along the ray path. This is an issue in scenes with high depth complexity like Goliath or architectural scenes. | ||
− | This task requires you to write an ANSI C prototype of a new spatial partitioning acceleration structure for BRL-CAD and to port this prototype | + | This task requires you to write an ANSI C prototype of a new spatial partitioning acceleration structure for BRL-CAD and to port this prototype to OpenCL. |
− | The ANSI C librt uses a BSP tree (really a [[wikipedia:k-d tree|Kd-tree]]) so that can be used an initial example. You can also use the PBRT Kd-tree source code as an initial example. Since we do not want to have duplicate intersections (we have complex primitives which can take a long time to intersect, also duplicates would needlessly complicate CSG processing), you would need to use some kind of Kd-tree hybrid in order to prevent the need for mailboxing. The issue with mailboxing is that it uses one bit per primitive in the model | + | The ANSI C librt uses a BSP tree (really a [[wikipedia:k-d tree|Kd-tree]]) so that can be used an initial example. You can also use the PBRT Kd-tree source code as an initial example. Since we do not want to have duplicate intersections (we have complex primitives which can take a long time to intersect, also duplicates would needlessly complicate CSG processing), you would need to use some kind of Kd-tree hybrid in order to prevent the need for mailboxing. The issue with mailboxing is that it uses one bit per primitive in the model. Imagine you have a model with a million primitives. This would reduce the amount of threads you can have in-flight (i.e. which can run simultaneously) because of the reduced cache memory available on a platform like a GPU. |
− | A suitable Kd-tree hybrid which does not compute duplicate intersections would be either the [[wikipedia:Bounding interval hierarchy|Bounding Interval Hierarchy]] (BIH), or a Kd-tree which stores the larger primitives in the inner nodes, instead of only storing primitives at the leaf nodes | + | A suitable Kd-tree hybrid which does not compute duplicate intersections would be either the [[wikipedia:Bounding interval hierarchy|Bounding Interval Hierarchy]] (BIH), or a Kd-tree which stores the larger primitives in the inner nodes, instead of only storing primitives at the leaf nodes. |
− | * https://github.com/mmp/pbrt-v3/tree/master/src/accelerators | + | * https://github.com/mmp/pbrt-v3/tree/master/src/accelerators |
− | |||
− | |||
Difficulty: Hard | Difficulty: Hard | ||
Languages: C and OpenCL (or other GPGPU API) | Languages: C and OpenCL (or other GPGPU API) |