CP013: Allow constructing an execution context from a range of execution resources

[AerialMantis]

It was raised that the current design limits the creation of an execution_context to a single execution_resource therefore enforcing that the execution_context represent all member execution_resources. This excludes the case where you may want to, for example, create an execution_context from half the threads of a core. In this case, you would want to list the execution_resources you want the execution_context to represent.

For this we need to add an additional constructor to the execution_context or alter the existing constructor to allow it to take a set of execution_resources. Perhaps we could do this by providing partitioning algorithms which can partition an execution_resource in a particular way and return a new iterable which could then be passed to the execution_context constructor.

[hcedwar]

Need to be able to query the context for a (single) resource object. Leading to having a resource object that is a specified subset of another resource. Leading to a constructor or member function that takes a selection-specification (e.g., array of ints) and gives back a resource handle. Leads to multiple resource objects referencing the same resource, which is OK because ownership is not implied. I'd go with constructor taking an existing resource and a selection-spec.

[AerialMantis]

That's a good point, if we allow constructing an execution_context from a set of execution_resources that could complicate the mapping of execution_contexts to execution_resources.

If I understand correctly you're proposing that the execution_context be constructed with an execution_resource and some form of array of indices, which specifies which member resources the context will manage? Something like:

execution_context partitionedContext(execRes, {0, 1, 2, 3});

We could make the default set be all member resources.

This would mean that you couldn't have an execution_context with execution_resources at different levels, though perhaps this is a reasonable restriction.

[Ruyk]

Seems like a reasonable restriction to me.
My concern is that we cannot assume all implementations of execution resource / context would allow for this fine-grained selection of resources.

1. What will be the behaviour in the case of trying to fine-grain select on a platform where this is not supported? (e.g., imagine trying to select individual work-items on a work-group for an OpenCL backend)
2. How can we query if a given resource can be "fine-grain selected" (for a lack of a better term at this point)? This is particularly important if we expect execution context and resources to be used in generic programming (e.g, nested parallel algorithms).

[AerialMantis]

Yes, I think this would have to be an optional feature as not all resources will be able to support this. The way I'd imagine this working is that an execution_resource would have a certain level of concurrency, but also have a certain level of partition-ability, being essentially the number of member resources which can be iterated over. So, for example, you could have a CPU core resource which has 8 concurrency and 8 partition-ability so you would be able to partition each of the resources individually, and then you could have a GPU work group resource which has 64 concurrency but 0 partition-ability, so you can execute work on it but not partition it further.