User:Vasco.costa/GSoC15/logs

From BRL-CAD
< User:Vasco.costa
Revision as of 17:16, 2 August 2015 by 85.245.164.163 (talk) (→‎Development Phase)

Community Bonding Period

I made two patches for OpenCL (OCL) shot code. One patch refactors the existing SPH (Sphere) shot code, and the another patch implements EHY (Elliptical Hyperboloid) shot code.

Background Research

Development Status

Milestone Description Patch Status
M0.1 fix OCL SPH shot routine compilation errors. #341 DONE
M0.2 EHY shot routine in OCL. #346 DONE
M1 ELL and ARB8 shot routines in OCL. #370 DONE
M2 refactor dispatcher, shoot, optical renderer to process many rays in parallel in C when rendering an image or block. INCOMPLETE
M3 grid spatial partitioning in OCL. #379 DONE
M4 GPU side database storage of OCL implemented primitives SPH. EHY, ELL, ARB8 . #392 DONE
M5 port compute intensive or critical parts of the dispatcher, boolean evaluation, optical renderer to OCL. ?
M6 TOR and TGC shot routines in OCL. #393 DONE
M7 BOT shot routine in OCL. CANCELLED

In case you are interested I suggest you apply the patches in this order:

  • #341: fixes SVN HEAD OCL compilation bug.
  • #393: adds TOR, TGC shot routines and basic infrastructure.
  • #346: adds EHY shot routine.
  • #370: adds ELL, ARB8 shot routines.

The other patches have change collisions and should require modifications to apply cleanly.

Development Phase

Week 1 : 25-31 May

  • Created some example .g files in mged for the primitives to be implemented this week. The Quick Reference Card proved to be quite useful.
  • Do the matrix ops for EHY (Elliptical Hyperboloid) in the OCL side.
  • Tried out a bunch of code browsing tools (cscope, LXR, doxygen, etc). The NetBeans IDE seems the most promising.

Week 2 : 1-7 Jun

  • Read code to better understand the main rendering loop. It seems to be something like this:
do_frame() → do_run() → worker()* → do_pixel()* → rt_shootray()* → rt_*_shot()
The code is recursive (which is problematic for OCL). I'll work on a simplified version of the rendering loop which only does the primary rays in C as a first approach. After I get the non-recursive parallel friendly C code I'll work on the OCL port.
  • Updated project proposal on Google Melange.
  • Upgraded Ubuntu and GCC.
  • Made simple ray generation code in C.
  • Made simple frame buffer write code in C.
  • Made simple diffuse shading code in C.

Week 3 : 8-14 Jun

  • Added the main boolean weaving code to our minimal renderer.
  • Eliminated some gotos and made the code more thread safe.
  • The simple renderer patches are in the mailing-list.

Week 4 : 15-21 Jun

  • Added OpenMP compile support. Use OpenMP constructs to launch the rendering threads. This work still has some bugs in it.
  • Alpha M2 patch. in mailing-list.
  • Read code to better understand the main spatial partition construction routines. They seem to be something like this:
rt_prep_parallel() → rt_cut_it() → rt_nugrid_cut()
We need something less complex that is more amenable to porting to OCL. So I will be implementing the Lagae & Dutré compact grid construction algorithm published at EGSR. First I will program in ANSI C then I will port the code to OpenCL.
  • Started work on M3: grid spatial partitioning in OCL.
  • ANSI C Lagae & Dutré grid construction code.

Week 5 : 22-28 Jun

  • Took time off from the project to go to the CGI'15 conference.

Week 6 : 29 Jun-5 Jul

  • GSoC Midterm Evaluations.

Weeks 7-8 : 6 Jul-12 Jul, 13 Jul-19 Jul

  • Evaluating algorithms for grid construction.
  • Selecting OCL kernels we can use to support grid construction. It seems PyOpenCL has some kernels we could use. Now the question is how to extricate the OpenCL/C from the Python...

Weeks 9-10 : 20 Jul-26 Jul, 27 Jul-2 Aug

  • Implemented GPU side solid database storage infrastructure.
  • The OCL EHY shot code now uses the GPU solid database instead of creating the input buffers on every call.
The code allows the primitive to decide how it is stored without imposing a convention. So one can use SoA, AoS, or whatever to store the data.
  • Implemented GPU side solid database storage for SPH, ELL, ARB8.
  • Extracted out some duplicated OCL code.
  • OCL TOR (Torus) shot routine. Includes the higher order equation solver code.
  • OCL TGC (Truncated General Cone) shot routine.
  • Put equation solver in separate .cl file.
  • General overhaul and cleanup of the OCL shot patches.
  • Upgraded NVIDIA OpenCL drivers on my computer to CUDA 7.0.
  • I drew up a tentative algorithm for the CSG raytrace:
# GPU execution
GEN_RAYS(args)
lengths = COMPUTE_LEN_SEGMENTS(rays, db)
segs = ALLOC_SEGMENTS(lengths)
segs = COMPUTE_SEGMENTS(rays, db, segs)

# CPU execution
waiting_segs = READ_SEGMENTS(segs)
# merge with CPU computed segments for non-accelerated primitives
finished_segs = RT_BOOL_WEAVE(waiting_segs)
partitions = RT_BOOL_FINAL(finished_segs)
pixels = VIEWSHADE(rays, db, partitions)
This allows us to ultimately reuse the CPU code for boolean weaving, primitive normals, shaders, to have a 100% pixel accurate result. At the expense of a lot of memory traffic and CPU-side computation of some fairly maths intensive parts like the normal compute and shade. However I presently see no other way of having a 100% accurate result in the time we have available.
  • Ran tests on OCL shot code to check for accuracy vs existing code:
# e.g. test for tgc
make tgc tgc
e tgc ; rt -o rt_tgc.pix # OR e tgc ; rt -o cl_tgc.pix
pixdiff rt_tgc.pix cl_tgc.pix | pix-fb 

# test results:
arb8: pixdiff bytes:  777500 matching,    8932 off by 1,       0 off by many
ehy:  pixdiff bytes:  760777 matching,   25643 off by 1,      12 off by many
ell:  pixdiff bytes:  764531 matching,   21901 off by 1,       0 off by many
sph:  pixdiff bytes:  736942 matching,   49490 off by 1,       0 off by many
tgc:  pixdiff bytes:  783191 matching,    3241 off by 1,       0 off by many
tor:  pixdiff bytes:  774138 matching,   12294 off by 1,       0 off by many
Retrieved from "https://brlcad.org/w/index.php?title=User:Vasco.costa/GSoC15/logs&oldid=9195"