TemplateExecutive

From Daxtoolkit
Jump to: navigation, search

My Goal

Create a very simplistic pipeline syntax that would hide the complexities of the execution of worklets while at the same time enforcing correct pipeline connections at compile time rather than runtime.

My work on this can be found on the TemplateExecutive branch which is based on Ken template branch. You can test out this work by running the ExecutiveConcept binary, or by looking at TestExecutive.cu in the Testing/cuda folder.

Current Design

The design using templated classes to enforce filter connection correctness at compile time. The pipeline has two classes and one function which contain all the components needed to move data from host to device, execute worklets and return the desired results to the host.

template<typename T>
void ExecutePipeline(T data)
{
  using namespace dax::modules;
  using namespace dax::exec;
  
  std::vector<GradientM::OutputDataType> results;
  Source<T> s(data);
  Filter< ElevationM > elevFilter(s);
  Filter< GradientM > gradientFilter(s,elevFilter);
  Sink(gradientFilter,results);
}

int main(int argc, char* argv[])
{
  dax::internal::StructureUniformGrid grid = CreateInputStructure(32);
  ExecutePipeline(grid);
  return 1;
}

What is a Source?

Currently the source is a light weight class that holds onto the data object and stores the data objects type.

What is a Filter?

Filter is class that is defined by the module type (EleveationM, Gradient M). It enforces the restrictions of the modules requirement onto the filters construction parameters, allowing the compile time checks for a valid pipeline. It also is the object that calls the worklet that is defined by the module type.

A filter uses lazy evaluation to delay computation. It will only call its worklet when it is passed to the sink function, or something downstream of it is 'sunked'.

What is a Module?

ElevationM and GradientM are specilalized modules that define the input and output data type of the worklet, and the function call to the worklet.

  typedef MapFieldModule <dax::internal::StructureUniformGrid,dax::Scalar,cudaExecution::ElevationWorklet> ElevationM;

Each worklet that the user writes is just a typedef of the generic module of the right work type. Modules don’t have to be only for cuda worklets, that can be cpu operations by simple changing the function call. The input and output type could be anything we could write a Module that accepted a data structure as input and generated a vector of data structures as output.

Modules in the future could easily support cuda streaming which would allow us to dynamically send chunks of the dataset to the function, allowing operations to be done on a dataset that doesn’t fit in GPU memory but does fit in virtual memory.

Modules have the concept of lazy execution and will only execute once per instance. Once computed it will only store its results and will not re-execute currently.

What is a Sink?

The Sink function is to return the desired result from the pipeline to the host machine. It activates the actual computation of the filters which means that filters downstream of the desired result will be ignored and not executed.


MapReduce Concept

As we move forward I expect that we are going to need to

void ExecutePipeline(T data)
{
  using namespace dax::modules;
  using namespace dax::exec;
  std::vector<ReduceModule::OutputDataType> results;

  Source<T> s(data);
  Map< MapModule > map(s);
  Reduce< ReduceModule > reduce(mapFilter);
  Sink(reuce,results);
}

or

void ExecutePipeline(T data)
{
  using namespace dax::modules;
  using namespace dax::exec;
  std::vector<ReduceModule::OutputDataType> results;

  Source<T> s(data);
  Filter< MapReduce<MapModule,ReduceModule> > filter(s);
  Sink(filter,results);
}


Limitations

  • Currently the filters hold onto managed device arrays which store the results of the worklet.
  • Filter definition requires number and type of input and output ports at compile time
    • Iterators or collections as input/output types can be used to work around this in the future
  • Filter definitions currently have to be manually written

Investigate