[Paraview-developers] piston in 3.98

Biddiscombe, John A. biddisco at cscs.ch
Fri Jan 18 06:23:27 EST 2013


Please ignore previous request. Problem mostly solved. Sorry for the noise.

JB

Fixed the compilation problem flag for a plugin by creating a dummy module file modelled after the piston one

vtk_module(vtkBBPModule
  DEPENDS
    vtkCommonCore
    vtkCommonDataModel
    vtkCommonExecutionModel
    vtkRenderingCore
    vtkRenderingOpenGL
    vtkIOImage
    vtkImagingHybrid
    vtkAcceleratorsPiston
  EXCLUDE_FROM_ALL
  )

Then using the following to remove the #defines and shorten the include directory list

# set this, otherwise C_SOURCES is empty in VS
set(CUDA_ATTACH_VS_BUILD_RULE_TO_CUDA_FILE OFF)
# generate the list of dependencies based on our module definition file
vtk_module_impl()
# remove a bunch of cruft that VTK adds in here about modules autoinit
set_directory_properties(PROPERTIES COMPILE_DEFINITIONS "")
# shorten the include dirs so nvcc doesn't crumble under the entire VTK/ParaView/Qt path
# first get the old setting and store it
get_directory_property(TEMPBBP_INCLUDE_DIRECTORIES INCLUDE_DIRECTORIES)
# now set our shorter include dirs list
set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES "${${vtk-module}_DEPENDS_INCLUDE_DIRS};${PISTON_INCLUDE}")
# call the cuda wrapper
cuda_compile(BBP_CUDA_C_SRCS ${BBP_CUDA_SRCS} ${GPGPU_BUILD_TYPE})
# put the include dirs back to what they were
set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES "${TEMPBBP_INCLUDE_DIRECTORIES}")

NB. Will probably have to put code in piston anyway, since exporting symbols from shared libs gives, link problems




From: paraview-developers-bounces at paraview.org [mailto:paraview-developers-bounces at paraview.org] On Behalf Of Biddiscombe, John A.
Sent: 18 January 2013 10:58
To: David E DeMarle
Cc: paraview-developers at paraview.org; Li-Ta Lo; Sewell, Christopher Meyer; Kenneth Moreland
Subject: Re: [Paraview-developers] piston in 3.98


When I compile paraview, I see that (for example) the vtkPistonSort.cu file gets the nvcc build rule setup with



set(nvcc_flags -m64;-D_CRT_SECURE_NO_DEPRECATE;-D_CRT_NONSTDC_NO_DEPRECATE;-D_CRT_SECURE_NO_WARNINGS;-D_SCL_SECURE_NO_DEPRECATE;-D_SCL_SECURE_NO_WARNINGS;-DVTK_IN_VTK;-DMPICH_IGNORE_CXX_SEEK;-DMPICH_IGNORE_CXX_SEEK;-Dcuda_compile_EXPORTS) # list



but when my plugin declares vtkBBPPistonSort.cu it gets the rules generated with



set(nvcc_flags -m64;-DvtkFiltersFlowPaths_AUTOINIT=1(vtkFiltersParallelFlowPaths);-DvtkIOExodus_AUTOINIT=1(vtkIOParallelExodus);-DvtkIOImage_AUTOINIT=1(vtkIOMPIImage);-DvtkRenderingCore_INCLUDE="D:/build/plugins-vs10/CMakeFiles/vtkRenderingCore_AUTOINIT_vtkInteractionStyle_vtkRenderingFreeType_vtkRenderingFreeTypeOpenGL_vtkRenderingOpenGL.h";-DvtkRenderingVolume_AUTOINIT=1(vtkRenderingVolumeOpenGL);-DQT_DLL;-DQT_GUI_LIB;-DQT_CORE_LIB;-DZOLTAN_SUPPORT;-Dcuda_compile_EXPORTS) # list



Does anyone know how to make the AUTOINIT=1 (vtkBlahBlah) stuff go away. Cmake seems to be inserting some info/messages here which mess up the nvcc compilation. Is there a flag in the vtk module support anywhere which disables the autoinit generation?



I've tried as hard as possible to mimic the cmake from the piston build, but something is being 'added' for the plugins. Any idea how to make it go away?



Thanks



JB





-----Original Message-----
From: David E DeMarle [mailto:dave.demarle at kitware.com]
Sent: 17 January 2013 17:38
To: Biddiscombe, John A.
Cc: paraview-developers at paraview.org<mailto:paraview-developers at paraview.org>; Sewell, Christopher Meyer; Li-Ta Lo; Kenneth Moreland; Utkarsh Ayachit
Subject: Re: [Paraview-developers] piston in 3.98



I think b. Getting the lists into and out of the vtkPainter parts are the only thing I'm leary of, but that's because I haven't touched them often.



Ollie, Chris, Ken and Utkarsh know the relevant pieces of code better than I, so I've cc'd them specifically.



David E DeMarle

Kitware, Inc.

R&D Engineer

21 Corporate Drive

Clifton Park, NY 12065-8662

Phone: 518-881-4909





On Thu, Jan 17, 2013 at 11:27 AM, Biddiscombe, John A. <biddisco at cscs.ch<mailto:biddisco at cscs.ch>> wrote:

> Dave

>

> Nice. It is working. Thanks.

>

> I'm very impressed. I wouldn't have thought of it being done like this, but the framework looks rather clever.

>

> Here's a harder question if you have a moment.

> My idea is to

> 1) insert a painter in my chain which passes vertices (normal 3d) to cuda using the piston framework and also pass a IdType equivalent list of polygon vertex indices.

> 2 )within the cuda code, generate a depth list of polygons based on one vertex from each, and sort that list. Then regenerate the vertex Idlist based on the sorted order.

> 3) replace the painter that draws the actual primitives with a new one which uses the interop array of vertex Ids so we can do the depth sort witout retransferring stuff to and fro every frame.

>

> The painter chain is already setup to do depth sort on the CPU, so I'd only need to add a cuda version with the interop setup and then add a new primitive painter (or some kind of painter that does the final draw instead of the existing one - might need to send the colours+opacities via interop too to avoid trouble retrieving them in the custom painter).

>

> Can you tell me based on your knowledge of how the piston stuff works

> if what I propose is essentially

> a) ridiculous (I'll do something else productive)

> b) doable

>

> + any hints which will get me there quicker.

>

> Many thanks again

>

> JB

>

>

> -----Original Message-----

> From: David E DeMarle [mailto:dave.demarle at kitware.com]

> Sent: 17 January 2013 17:05

> To: Biddiscombe, John A.

> Cc: paraview-developers at paraview.org<mailto:paraview-developers at paraview.org>

> Subject: Re: [Paraview-developers] piston in 3.98

>

> Start paraview with --use-cuda-interop

>

> David E DeMarle

> Kitware, Inc.

> R&D Engineer

> 21 Corporate Drive

> Clifton Park, NY 12065-8662

> Phone: 518-881-4909

>

>

> On Thu, Jan 17, 2013 at 11:00 AM, Biddiscombe, John A. <biddisco at cscs.ch<mailto:biddisco at cscs.ch>> wrote:

>> The piston plugin appears to be working, and I'm able to select a dataset, "send to piston', and then "get from piston', however when I put a breakpoint in the piston mapper and check the rendering, it always stops in RenderOnCPU.

>>

>> I'd like to see the RenderOnGPU working. I poked around to see if there's an option in PistonRepresentation, (or even a PistonView) which might be activated which would trigger the GPU rendering activity, but couldn't find a way to do it (without experimenting with code changes).

>>

>> Is there a combination of actions which displays using the GPU buffer objects.

>>

>> NB. PistonContour produces an output, slice and threshold produce empty results (so far).

>> NB. Test machine has very old cuda support, will experiment on newer one if GPU render is possible.

>>

>> Thanks again

>>

>> JB

>>

>> -----Original Message-----

>> From: David E DeMarle [mailto:dave.demarle at kitware.com]

>> Sent: 16 January 2013 19:49

>> To: Biddiscombe, John A.

>> Cc: paraview-developers at paraview.org<mailto:paraview-developers at paraview.org>

>> Subject: Re: [Paraview-developers] piston in 3.98

>>

>> Use piston sha 2913c77 for 3.98.

>> Use piston sha b50cf296 for current master.

>>

>> David E DeMarle

>> Kitware, Inc.

>> R&D Engineer

>> 21 Corporate Drive

>> Clifton Park, NY 12065-8662

>> Phone: 518-881-4909

>>

>>

>> On Wed, Jan 16, 2013 at 1:06 PM, Biddiscombe, John A. <biddisco at cscs.ch<mailto:biddisco at cscs.ch>> wrote:

>>> I wanted to try a cuda based (depth) sort, then using interop, draw

>>> polygons using opengl in a custom painter - this would save a

>>> transfer from cpu-gpu on every frame.

>>>

>>>

>>>

>>> Piston seems to have some interop facilities embedded, but I

>>> couldn't build the vtkAcceleratorsPiston using the (piston) version from github.

>>>

>>>

>>>

>>> Is piston working in 3.98? and if so, should I use a different

>>> version than the github one.

>>>

>>>

>>>

>>> Thanks for any info.

>>>

>>>

>>>

>>> JB

>>>

>>>

>>>

>>>

>>>

>>> --

>>>

>>> John Biddiscombe,                        email:biddisco @.at.@ cscs.ch

>>>

>>> http://www.cscs.ch/

>>>

>>> CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91)

>>> 610.82.07

>>>

>>> Via Trevano 131, 6900 Lugano, Switzerland   | Fax:  +41 (91) 610.82.82

>>>

>>>

>>>

>>>

>>> _______________________________________________

>>> Paraview-developers mailing list

>>> Paraview-developers at paraview.org<mailto:Paraview-developers at paraview.org>

>>> http://public.kitware.com/mailman/listinfo/paraview-developers

>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20130118/0dac8a18/attachment-0001.htm>


More information about the Paraview-developers mailing list