bugs/issue-cd8cda126db604feda8a481b2022490311624cb9.yaml

   1 --- !ditz.rubyforge.org,2008-03-06/issue
   2 title: Consider an appropriate API and implementation for backing store (--resident).
   3 desc: ""
   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-02-21 19:42:45.100645 Z
  11 references: []
  12
  13 id: cd8cda126db604feda8a481b2022490311624cb9
  14 log_events:
  15 - - 2009-02-21 19:42:46.053124 Z
  16   - David Hilvert <dhilvert@auricle.dyndns.org>
  17   - created
  18   - ""
  19 - - 2009-02-21 19:57:42.252638 Z
  20   - David Hilvert <dhilvert@auricle.dyndns.org>
  21   - commented
  22   - |-
  23     Reasonable approaches might involve either passing a file (FILE *) from client
  24     code or passing a function pointer for generation of temporary files (e.g.,
  25     satisfied by tmpfile() or similar).
  26 - - 2009-02-21 20:17:15.752238 Z
  27   - David Hilvert <dhilvert@auricle.dyndns.org>
  28   - commented
  29   - |-
  30     In particular, passing a file (FILE *) might be most appropriate for data
  31     received from client code (e.g., frames), while using a temporary file
  32     generator (perhaps specified in client code, or otherwise defaulting to
  33     something like tmpfile()) might be most appropriate for images generated by the
  34     library.
  35
  36     Note also that file specifications might include byte or word offsets (so that,
  37     e.g., PPM binary formats can be passed without copying or otherwise shuffling
  38     data).
  39 - - 2009-02-21 20:38:02.649102 Z
  40   - David Hilvert <dhilvert@auricle.dyndns.org>
  41   - commented
  42   - |-
  43     Any variable pointing to a temporary file generator should probably be
  44     contained within a client-associated object (e.g., an ale_context).
  45 - - 2009-02-21 22:39:36.712462 Z
  46   - David Hilvert <dhilvert@auricle.dyndns.org>
  47   - commented
  48   - |-
  49     Note that transfers between backing store files and compute device memories
  50     will probably occur largely within rendering code (and perhaps on load, in
  51     cases where a loaded compute memory object is larger than resident_size).
  52
  53     In particular, renderers will probably be able to determine what patterns
  54     of loading are necessary.
  55 - - 2009-02-22 05:35:27.011928 Z
  56   - David Hilvert <dhilvert@auricle.dyndns.org>
  57   - commented
  58   - |-
  59     Consider that it might be worthwhile to have separate concepts of objects
  60     resident in host memory and device memory, and also that it might be worthwhile
  61     to have separate limits for sizes in these areas (perhaps also with limits per
  62     device, in the case of multiple devices).
  63 - - 2009-02-22 06:12:15.268113 Z
  64   - David Hilvert <dhilvert@auricle.dyndns.org>
  65   - commented
  66   - |-
  67     Note that various patterns of pixels could be used for loading and storage
  68     (e.g., block-contiguous, arranged in a grid, or row-contiguous, arranged by
  69     rows), and that the choice of pattern may be relevant for reducing explicit
  70     load counts, as well as for cache behavior (and that such considerations extend
  71     also to the current ALE code).
  72 - - 2009-02-23 12:10:12.750096 Z
  73   - David Hilvert <dhilvert@auricle.dyndns.org>
  74   - commented
  75   - |-
  76     For the case of a memory hierarchy from files to host memory to device memory,
  77     it might be appropriate to have (at least) three API functions, such as --
  78
  79     ale_image_set_cl(..., cl_mem)
  80
  81     ale_image_set_file(..., FILE *)
  82
  83     ale_image_set_host(..., void *)
  84 - - 2009-02-25 12:02:50.223765 Z
  85   - David Hilvert <dhilvert@auricle.dyndns.org>
  86   - commented
  87   - |-
  88     A property could be added for determining what sort of backing should be used
  89     for host memory.  In particular, an option could be added for backing host
  90     memory with a memory-mapped file (instead of backing it with swap).  On the
  91     other hand, it seems that explicit loads and stores from files will be
  92     necessary, if swap performance in ALE is any indication, so that perhaps
  93     implicit copied (as opposed to explicitly copied) backing for host memory is
  94     not an especially pressing concern.
  95 - - 2009-02-25 12:16:49.269339 Z
  96   - David Hilvert <dhilvert@auricle.dyndns.org>
  97   - commented
  98   - |-
  99     Analogously with ale_image_set_*, there should probably be multiple varieties
 100     of return functions, such as:
 101
 102     ale_return_cl(...)
 103
 104     ale_return_file(...)
 105
 106     ale_return_host(...)
 107
 108     Or perhaps better:
 109
 110     ale_image_return_cl(...)
 111
 112     ale_image_return_file(...)
 113
 114     ale_image_return_host(...)
 115 - - 2009-02-25 12:44:31.536957 Z
 116   - David Hilvert <dhilvert@auricle.dyndns.org>
 117   - commented
 118   - |-
 119     Rather than separate (_cl, _file, _host), returns could be handled via a
 120     structure and union similar to:
 121
 122     typedef struct {
 123         int memory_type;
 124         union {
 125                 FILE *file_value;
 126                 void *host_value;
 127                 cl_mem cl_value;
 128         }
 129     } ale_mem;
 130
 131     Giving:
 132
 133     ale_mem foo = ale_return(...);
 134
 135     Similarly, such a carrier could be used for initialization, as:
 136
 137     ale_image_set(..., ale_mem);
 138
 139     Helper functions (or macros) could also be devised, as
 140
 141     ale_mem am = host_to_ale(void *)
 142
 143     void *hm = ale_to_host(void *)
 144
 145     ...
 146
 147     Et cetera.
 148
 149     Of course, since such bundling and unbundling of assignments would be primarily
 150     associated with the ale_image type, such operations could instead be directly
 151     included within the type itself, so that no additional carrier structure would
 152     be necessary.
 153 - - 2009-02-25 12:57:51.415584 Z
 154   - David Hilvert <dhilvert@auricle.dyndns.org>
 155   - commented
 156   - |-
 157     In the case that return_*() functions are used, there should probably also be a
 158     return_type() function, indicating what type of return is appropriate.  I.e.,
 159
 160     ale_return_type(...)
 161
 162     Or perhaps:
 163
 164     ale_image_return_type(...)
 165 - - 2009-02-27 16:43:09.761662 Z
 166   - David Hilvert <dhilvert@auricle.dyndns.org>
 167   - commented
 168   - |-
 169     Note that one advantage to using a return_type function in combination with
 170     separate return_*() functions is that it allows determination of the return
 171     type without involving any reference counting operations.
 172 - - 2009-03-04 13:25:55.042007 Z
 173   - David Hilvert <dhilvert@auricle.dyndns.org>
 174   - commented
 175   - Modified API for ale_return_* and ale_image_set_*, with accompanying ale_image_buffer_type().
 176 git_branch: