Open steven-johnson opened 5 years ago
Can they use the device field for this?
Hmm... is that safe to use for arbitrary stuff? I was under the impression that it should be treated as a Magic Cookie field, for use by the device-interface code.
One needs an accompanying halide_device_interface_t
to accomplish certain functions, but otherwise the device
field can be used for this. E.g. an ION allocation. Arguably we could provide an ION allocator device interface ourselves as a useful service.
An external commenter asks: "Is there a field on Halide::Runtime::Buffer where I can embed a uint32? The tl;dr is that the halide buffer is backed by an ION allocation and other parts of our codebase require the ION fd as well as the host pointer to work. Due to the many layers in our stack, changing this around for an Android specific case would require a lot of overhead."
Adding this to halide_buffer_t is probably infeasible in the short term. Adding support for it to Halide::Runtime::Buffer might be tractable with some care. Alternately, I suspect they (or we) could add a DeviceInterface that could address this, but that might be delicate.