Editing User:Vasco.costa/GSoC15/logs
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 18: | Line 18: | ||
|M1||ELL and ARB8 shot routines in OCL.||#370||'''TRUNK''' | |M1||ELL and ARB8 shot routines in OCL.||#370||'''TRUNK''' | ||
|- | |- | ||
− | |M2||<s>refactor dispatcher, shoot, optical renderer to process many rays in parallel in C when rendering an image or block.</s>|||| | + | |M2||<s>refactor dispatcher, shoot, optical renderer to process many rays in parallel in C when rendering an image or block.</s>||||see M5 |
|- | |- | ||
− | |M3.0||<s>grid spatial partitioning in C.</s>||#379|| | + | |M3.0||<s>grid spatial partitioning in C.</s>||#379||see M3.2 |
|- | |- | ||
− | |M3.1||<s>grid spatial partitioning in OCL.</s>||#379|| | + | |M3.1||<s>grid spatial partitioning in OCL.</s>||#379||see M3.2 |
|- | |- | ||
|M3.2||HLBVH object partitioning builder in C. traversal in OCL.||||'''TRUNK''' | |M3.2||HLBVH object partitioning builder in C. traversal in OCL.||||'''TRUNK''' | ||
Line 33: | Line 33: | ||
|- | |- | ||
|M5.2||OCL rasterizer that does the pixel pushing for a whole frame.||||'''TRUNK''' | |M5.2||OCL rasterizer that does the pixel pushing for a whole frame.||||'''TRUNK''' | ||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
|M6||TOR and TGC shot routines in OCL.||#393||'''TRUNK''' | |M6||TOR and TGC shot routines in OCL.||#393||'''TRUNK''' | ||
Line 42: | Line 38: | ||
|M6.1||REC shot routine in OCL.||||'''TRUNK''' | |M6.1||REC shot routine in OCL.||||'''TRUNK''' | ||
|- | |- | ||
− | |M6.2||Surface normal routines for | + | |M6.2||Surface normal routines for OCL implemented primitives.||||'''TRUNK''' |
|- | |- | ||
− | |M7||BOT shot routine in OCL.||||- | + | |M7||<s>BOT shot routine in OCL.</s>||||- |
− | |||
− | |||
− | |||
− | |||
|} | |} | ||
<!-- | <!-- | ||
Line 59: | Line 51: | ||
--> | --> | ||
− | The ARB8 | + | The ARB8, EHY, ELL, SPH, REC, TOR, TGC, shot routines are in SVN trunk. |
− | SVN trunk also contains solid database device storage and a render function which given a view2model matrix, width, height, can generate an RGB8 bitmap. Diffuse and Surface Normal light models are supported. The renderer does | + | SVN trunk also contains solid database device storage and a render function which given a view2model matrix, width, height, can generate an RGB8 bitmap. Diffuse and Surface Normal light models are supported. The renderer does brute force first-hit ray tracing and ignores the CSG operators. |
=Development Phase= | =Development Phase= | ||
Line 216: | Line 208: | ||
* ''M2 commited to opencl branch: kludge up a simple rendering pipeline with grid spatial partitioning traversal acceleration.'' | * ''M2 commited to opencl branch: kludge up a simple rendering pipeline with grid spatial partitioning traversal acceleration.'' | ||
− | : The simple ANSI C rendering pipeline only supports Lambertian reflection with a stock grey material to make things simpler. | + | : The simple ANSI C rendering pipeline only supports Lambertian reflection with a stock grey material to make things simpler. Example output for ''goliath.g'': |
+ | |||
+ | :[[File:Cl_goliath.png|256px]] | ||
+ | |||
<blockquote> | <blockquote> | ||
{| | {| | ||
Line 283: | Line 278: | ||
* Retrofit HLBVH tree builder from pbrtv3 source into opencl branch. | * Retrofit HLBVH tree builder from pbrtv3 source into opencl branch. | ||
* OCL BVH traversal in branch. | * OCL BVH traversal in branch. | ||
− | : For reference the OCL BVH can render the Havoc scene, as seen above, at elapsed time: | + | : For reference the OCL BVH can render the Havoc scene, as seen above, at elapsed time: 0.09 sec vs the 4.20 sec it took with the brute force code. i.e. it is around 45x faster for this scene. The advantage should increase for scenes with more solids. |
* The HLBVH code has stabilized enough that I replaced the grids code with it. | * The HLBVH code has stabilized enough that I replaced the grids code with it. | ||
Line 293: | Line 288: | ||
===Week 13 : 17 Aug-23 Aug=== | ===Week 13 : 17 Aug-23 Aug=== | ||
− | * Do heavy duty pixel pushing with the GPU. This speeds up rendering of Havok around | + | * Do heavy duty pixel pushing with the GPU. This speeds up rendering of Havok around 3x on my system. It should make even more of a difference in simpler scenes which are more fillrate than geometry performance limited. I figured out a way to do the code for this without actually breaking the API. I used a callback to get the framebuffer pointer. |
* I redid the accuracy tests after reimplementing the raster parts of the code in OCL to check the accuracy. I got the same accuracy in surface normals mode as when we only computed the hit results in OCL with one kernel invocation per ray-solid intersection. | * I redid the accuracy tests after reimplementing the raster parts of the code in OCL to check the accuracy. I got the same accuracy in surface normals mode as when we only computed the hit results in OCL with one kernel invocation per ray-solid intersection. | ||
Line 299: | Line 294: | ||
<blockquote> | <blockquote> | ||
{| | {| | ||
− | !'''RT | + | !'''RT (EHY)'''!!'''OCL (EHY)'''!!'''PIXDIFF (EHY)''' |
|- | |- | ||
|[[File:Rt_ehyn.png|256px]]||[[File:Cl_ehyn.png|256px]]||[[File:Diff_ehyn.png|256px]] | |[[File:Rt_ehyn.png|256px]]||[[File:Cl_ehyn.png|256px]]||[[File:Diff_ehyn.png|256px]] | ||
− | |||
− | |||
|} | |} | ||
</blockquote> | </blockquote> | ||
:This was the one primitive which had the most differences last time so I ran the test again. <code>ehy: pixdiff bytes: 760757 matching, 25663 off by 1, 12 off by many</code>. I got similar results. So the pixel engine shouldn't be more innacurate than the regular one. What I did find out in surface normals mode was that the CPU code actually is showing hits with the side of the hyperboloid (see the blue dots in the figure at the left). Despite this view being top down. So maybe the GPU version is actually ''more'' accurate? The differences show a nice noisy pattern without obvious banding or moire so there don't seem to be any major issues with the hits, normals, and raster. | :This was the one primitive which had the most differences last time so I ran the test again. <code>ehy: pixdiff bytes: 760757 matching, 25663 off by 1, 12 off by many</code>. I got similar results. So the pixel engine shouldn't be more innacurate than the regular one. What I did find out in surface normals mode was that the CPU code actually is showing hits with the side of the hyperboloid (see the blue dots in the figure at the left). Despite this view being top down. So maybe the GPU version is actually ''more'' accurate? The differences show a nice noisy pattern without obvious banding or moire so there don't seem to be any major issues with the hits, normals, and raster. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |