2010 NAMIC Project week:Inventory of Volume Rendering Functionality
Sample rendering using NCI volume renderer in Slicer
Key Investigators
- MIT Media Lab: Jim Barabas
- BWH: Noby Hata
Objective
- Review volume rendering support in slicer3.6.
- Test current capabilities and performance.
- Develop plan for extending rendering capabilities. (This work is towards longer-term goal of developing an image-based photorealistic volume renderer).
Approach, Plan
- Examine code for current volume rendering support.
- Benchmark on available GPU architectures.
- Develop and test extensions to current volume shaders.
Progress
- Read through code and shaders for the GPU-based volume renderers.
- Examined and found quick reproduction steps for bug in Apple/Nvidia shader compiler that prevents ITK volume renderer from working on recent Mac OS X releases.
- Possible fix identified: Concatenate sources (with redundant global variables removed) into single shader source file instead of linking several separate files.
Delivery Mechanism
notes delivered to the NA-MIC Kit as a information on this wiki page.
Findings
Compared GPU shader architectures in Slicer 3.6:
- NCI renderer concatenates strings to assemble shader source, depending on settings chosen. This method is less fragile, but harder to debug/profile shader using external tools.
- VTK renderer links several individual shader sources, generated from .glsl files.
- NCI renderer supports multiple volumes rendered in a single pass
- NCI renderer contains a mode for adaptive transfer-function generation.
- NCI renderer pre-computes gradient volume in CPU, which can be slow initially, but may save time rendering.
Comments on current volume rendering capabilities:
- Could benefit from better defaults for renderer transfer functions. VirtualPlace renderer has row of clickable defaults that let users get nice appearance quickly.
- Transfer function editor is capable, could be easier to use if it was possible to translate whole function.
Notes
Other pages on volume rendering in Slicer
We had a breakout session with demos of the Slicer renderers, as well as the VirtualPlace renderer, and the Microsoft Research client-server CUDA renderer. 2010 Summer Project Week Breakout Session: Volume Rendering
Traced shaders using 2010 Macbook Pro. Set breakpoints for gl*Shader* and gl*Program* functions using OpenGL Profiler and observed openGL state.
Tracing using OpenGL profiler: get it to break on glCreateShaderObjectARB and glGetShaderInfoLog, glCreateProgramObjectARB
Attempts to use profiler cause slicer to balloon in memory (~11G and counting) Spiraling in:
1115 vtkRenderer::UpdateGeometry() 1115 vtkVolume::RenderVolumetricGeometry(vtkViewport*) 1115 vtkGPUVolumeRayCastMapper::Render(vtkRenderer*, vtkVolume*) 1115 vtkOpenGLGPUVolumeRayCastMapper::GPURender(vtkRenderer*, vtkVolume*) 1115 vtkOpenGLGPUVolumeRayCastMapper::PreRender(vtkRenderer*, vtkVolume*, double*, double*, int, unsigned int) 1115 vtkShaderProgram2::Use() 1115 vtkShaderProgram2::Build() 1115 glCreateProgram 1115 gloGetCGLDispatch 1115 0x139fee7b5 1115 _pthread_cond_wait 1115 __semwait_signal
Using nvidia graphics, get:
6/23/10 2:23:48 PM [0x0-0x65065].com.apple.ShaderBuilder[2220] (0) : fatal error C9999: Nested functions, aborting! 6/23/10 2:23:48 PM [0x0-0x65065].com.apple.ShaderBuilder[2220] Cg compiler terminated due to fatal error 6/23/10 2:23:48 PM com.apple.launchd.peruser.501[812] ([0x0-0x65065].com.apple.ShaderBuilder[2220]) Exited with exit code: 15
Using intel graphics, get:
6/23/10 2:46:45 PM com.apple.launchd.peruser.501[812] (com.apple.cvmsCompAgent_x86_64[2365]) Job appears to have crashed: Segmentation fault 6/23/10 2:46:45 PM com.apple.ReportCrash.Root[2369] 2010-06-23 14:46:45.366 ReportCrash[2369:2a03] Saved crash report for cvmsComp_x86_64[2365] version ??? (???) to /Library/Logs/DiagnosticReports/cvmsComp_x86_64_2010-06-23-144645_localhost.crash
Possible location of failing source:
(located in Slicer3-lib/VTK/VolumeRendering/)
vtkGPUVolumeRayCastMapper_HeaderFS.glsl vtkGPUVolumeRayCastMapper_ParallelProjectionFS.glsl vtkGPUVolumeRayCastMapper_CompositeFS.glsl vtkGPUVolumeRayCastMapper_CompositeNoCroppingFS.glsl vtkGPUVolumeRayCastMapper_OneComponentFS.glsl vtkGPUVolumeRayCastMapper_NoShadeFS.glsl
Bug appears to crash compiler when scalarFromValue() called inside trace(). Using intel graphics card causes recoverable crash. Nvidia crashes hard and kills ShaderBuilder.
So functions that implement scalarFromValue are:
vtkGPUVolumeRayCastMapper_FourComponentsFS.glsl
vtkGPUVolumeRayCastMapper_OneComponentFS.glsl
get called by: vtkGPUVolumeRayCastMapper_CompositeFS.glsl vtkGPUVolumeRayCastMapper_CompositeMaskFS.glsl
Looking to VTK docs (Looks like Slicer using vers 5.6.0
__________
Volume Rendering code overview:
VTK renderer lives in: Slicer3-lib/VTK/VolumeRendering/*.glsl Series of glsl fragment shaders are linked together to form single fragment program. Different .glsl files are linked depending on options chosen. This approach is nice and modular, but seems to expose a bug in the Apple/Nvidia shader compiler.
NCI renderer lives in: Modules/VolumeRendering/VolumeRenderingReplacements/vtkSlicerGPURayCastVolumeMapper.cxx
