Dax TCon 2012-05-24

From Daxtoolkit
Jump to: navigation, search

Signatures for Worklet Glue Code

Brad King talked about some introductory redesign of how worklets are specified and the "glue code," the code that is called from the control environment to invoke the worklets, is generated. The basic idea is that worklets become functors that inherent from the work objects. Then some template meta-programming concepts automatically construct the glue code based on the signature of the functor operation. This is done with generic functions that take as parameters the functor/worklet/work object and arrays as arguments and invoke the appropriate jobs.

Here are some examples of how it might look.

template <typename FieldType>
struct Sine: public WorkMapField
{
 typedef FieldType Signature(FieldType); // optional?
 FieldType operator()(FieldType v) const
   { return sin(v); }
};
template <typename FieldType>
struct PlusEqual: public WorkMapField
{
 typedef void Signature(FieldType& (dax::sig::Field, dax::sig::InOut),
                        FieldType); // (dax::sig::Field) implicit?
 void operator()(FieldType& l, FieldType r) const
   { l += r; }
};
template<typename CellType, typename FieldType>
struct ThresholdClassify: public WorkMapCell<CellType>
{
 FieldType const Min;
 FieldType const Max;
 ThresholdClassify(FieldType min, FieldType max): Min(min),Max(max) {}
 typedef dax::Id Signature(
   dax::Tuple<FieldType,CellType::NUM_POINTS> (dax::sig::FieldPoint)
   );
 dax::Id operator()(dax::Tuple<FieldType,CellType::NUM_POINTS>) const;
};
template <class FieldType>
struct DivMod: public WorkMapField
{
 FieldType Divisor;
 DivMod(FieldType d): Divisor(d) {}
 typedef void Signature(FieldType  (dax::sig::Field),
                        FieldType& (dax::sig::Field, dax::sig::Out),
                        FieldType& (dax::sig::Field, dax::sig::Out));
 void operator()(FieldType value, FieldType& res, FieldType& rem) const
   {
   res = value / Divisor;
   rem = value % Divisor;
   }
};

VectorReduce template

Brad notes that technically a reduce operation should take a base value. Using a base value would also clean up the implementation a bit.

Device/Execution Pointer Wrapper

Brad notes that one shortcoming of CUDA is that it does not distinguish device pointers from host pointers. Thus it is easy to use a pointer in the wrong environment. We could add some safety to Dax by creating our own device pointer wrapper. This would be like a "smart pointer" that ensured that the pointer is used in the correct environment.

Iterators Must Go

Brad suggests Ken watches the boost "Iterators Must Go!" presentation. This presentation suggests that STL is stupid, and that rather than iterators we should be using ranges. Ranges would probably clean up many sections of Dax code that is currently relying on iterators. The presentation can be found here:

http://www.scribd.com/doc/32685401/Iterators-Must-Go

Marching Cubes

Nikhil Shetty is currently working on a marching cubes implementation.

Dax + VTK

Robert Maynard is working on integrating Dax with VTK. There are current holes where changes in the ArrayHandle effect the work.

New version of ArrayHandle

Ken Moreland has almost completed the work on the new version of ArrayHandle. The ArrayHandlePartDeux topic branch contains what seems to be a working version of the new ArrayHandle for OpenMP.