Better control on what CellSet control tags loads onto the execution side
When writing the PointGradient
worklet we noticed that we need a way to access the entire CellSet while at the same time running a Cell->Point algorithm. The initial solution was adding WholeCellSetIn
, which solves the problem when you dispatch given known types. This solution is great not only because it solves the PointGradient
problem, but it also people to write cellset to cellset mapping algorithms.
Now here are the problems that WholeCellSetIn
has introduced:
-
Without out very careful worklet writing, you lose the fast paths when using
WholeCellSetIn
, mainly all the math computations that are related to structured cellsets. To solve this problem we should either make it easier to usevtkm::exec::arg::Fetch
classes in worklets, or provide a fatter API on theWholeCellSetIn
exec object. -
When you dispatch use a dynamic
CellSet
it causes the dispatcher to deduce theCellSet
type twice causing a 5x increase in the number of symbols.
My initial reaction is that we should allow CellSetIn
tag to have options so that worklets can request not just the primary local
information ( the point->cell mapping or cell->point mapping ) but also other arbitrary information ( just as the entire reverse mapping, or the entire current mapping ). My idea is to add the following exec
tags:
ReverseCellSetMapping
CellSetMapping
Which would allow the following:
typedef void ControlSignature(CellSetIn, WholeCellSetIn<Point,Cell>, WholeArrayIn<Vec3> pointCoordinates);
typedef void ExecutionSignature(CellCount, CellIndices, WorkIndex, _2, _3);
to be:
typedef void ControlSignature(CellSetIn, WholeArrayIn<Vec3> pointCoordinates);
typedef void ExecutionSignature(CellCount, CellIndices, WorkIndex, ReverseCellSetMapping, _2);