bugs: Propose performing flattening in client code at the outset, for easier
[libale.git] / bugs / issue-76aa36a03fb8d5ab1fdfc54a23caeed859c97da1.yaml
blob94dd0076cc1beb1ed90cdc6f3d8f3b3d0e26a631
1 --- !ditz.rubyforge.org,2008-03-06/issue 
2 title: Handle resident_size context property.
3 desc: Libale currently has no handling for resident size.  This should probably be fixed eventually.
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-10 06:01:14.995003 Z
11 references: []
13 id: 76aa36a03fb8d5ab1fdfc54a23caeed859c97da1
14 log_events: 
15 - - 2009-01-10 06:01:26.950928 Z
16   - David Hilvert <dhilvert@auricle.dyndns.org>
17   - created
18   - ""
19 - - 2009-02-13 22:37:42.709795 Z
20   - David Hilvert <dhilvert@auricle.dyndns.org>
21   - commented
22   - |-
23     This could perhaps be addressed from within the OpenCL abstraction, as a
24     special OpenCL device or otherwise.
25 - - 2009-02-13 22:42:56.622663 Z
26   - David Hilvert <dhilvert@auricle.dyndns.org>
27   - commented
28   - |-
29     As an alternative to addressing implementation for this parameter from within
30     the OpenCL abstraction, libale images could be stored as arrays of OpenCL
31     buffers, with an OpenCL-language function or macro used for iterating the
32     necessary combinations of input and output image segments.
33 - - 2009-02-13 23:00:08.793123 Z
34   - David Hilvert <dhilvert@auricle.dyndns.org>
35   - commented
36   - |-
37     In the case that libale handles segments to satisfy resident_size, note that
38     such segments could be generated internally to the library (e.g., splitting any
39     larger buffers passed from client code).
40 - - 2009-02-14 10:38:56.911441 Z
41   - David Hilvert <dhilvert@auricle.dyndns.org>
42   - commented
43   - |-
44     Note that segmentation of images could occur internally to the image type, and
45     that this is probably the most natural approach to take.
46 - - 2009-02-14 10:50:53.339543 Z
47   - David Hilvert <dhilvert@auricle.dyndns.org>
48   - commented
49   - |-
50     Note that, if segmentation occurs within the image type, such type could return
51     an error value (e.g., ((cl_mem) 0)) from the standard return function, indicating
52     that a special return function be used that is capable of returning arrays of
53     OpenCL buffers.  Further, it might be acceptable, and perhaps appropriate, for
54     images to accept client-specified buffers of arbitrary size, perhaps segmenting
55     these, if such is desired, as well as to accept segmented buffers from the
56     client.
57 - - 2009-02-25 11:33:40.355151 Z
58   - David Hilvert <dhilvert@auricle.dyndns.org>
59   - commented
60   - |-
61     Note (cf. {issue cd8cda126db604feda8a481b2022490311624cb9}) that multiple properties resident_size should probably be
62     tracked, in order to support a multi-level hierarchy of memories, likely
63     including (at least) files, host memory, and device memory.  In particular, the
64     following properties might be stored:
65     
66     host_resident_size
67     
68     compute_resident_size
69 - - 2009-02-28 17:25:35.863961 Z
70   - David Hilvert <dhilvert@auricle.dyndns.org>
71   - commented
72   - |-
73     Note, in addition to other properties already noted, that it might be
74     worthwhile to also recognize file_resident_size, limiting the size of
75     file-resident data.
76 - - 2009-03-04 12:39:37.741453 Z
77   - David Hilvert <dhilvert@auricle.dyndns.org>
78   - commented
79   - "{file_,host_,compute_}resident_size properties implemented."
80 git_branch: