bugs: Don't require client knowledge of flattened representations.
[libale.git] / bugs / issue-091887e5b8deb698b1e390e6fdeaae0597334225.yaml
blobfb8449bdb9098f85b5c039b10cc542ad6790a5da
1 --- !ditz.rubyforge.org,2008-03-06/issue 
2 title: Parallelize alignment
3 desc: Alignment should be parallelized for OpenCL.
4 type: :task
5 component: libale
6 release: 
7 reporter: David Hilvert <dhilvert@auricle.dyndns.org>
8 status: :unstarted
9 disposition: 
10 creation_time: 2009-01-12 06:38:19.968512 Z
11 references: []
13 id: 091887e5b8deb698b1e390e6fdeaae0597334225
14 log_events: 
15 - - 2009-01-12 06:40:02.443275 Z
16   - David Hilvert <dhilvert@auricle.dyndns.org>
17   - created
18   - ""
19 - - 2009-01-12 06:45:02.003891 Z
20   - David Hilvert <dhilvert@auricle.dyndns.org>
21   - commented
22   - |-
23     One reasonable approach to parallelization of alignment might be to perform
24     only measurement of error metrics on the compute device, but to perform many of
25     these measurements in parallel (with one measurement for each element having
26     remaining candidate transformations for measurement).
27     
28     The host side would then perform the task of determining candidate
29     transformations for the next compute run and queueing these for execution.
30 - - 2009-01-12 07:32:23.000454 Z
31   - David Hilvert <dhilvert@auricle.dyndns.org>
32   - commented
33   - |-
34     As an alternative to processing a single match value (alignment error) at a
35     time on the compute device, a set of errors could be computed (e.g., from a
36     candidate set).  Such a set could perhaps be processed for each work item,
37     where a work item would correspond to a particular point in the approximation
38     image space, or could occur across different work items, where each work item
39     would correspond to an (approximation point, candidate alignment) pair.