Preallocated buffers.

[S-o-T]

If one have an estimate on upper bounds of pipeline's input\output sizes, it should be possible to avoid memory (de)allocation during the execution of pipeline, by (re)using the buffers provided as part of input\output data, structure (and, optionally,(de)allocation procedures) of which should be codegened as part of pipeline interface. Does Halide already have an implemention of such functionality and, if not, are there any plans to introduce such functionality?

[zvookin]

I call the generalization of this "Allocation Plans." The idea is there should be a way to hoist scoped resource allocation/deallocation to higher scopes, or orthogonally change the allocation method to use an LRU cache or suballocate from a larger block, etc. This is a research project, but very much in keeping with Halide's notion of scheduling and having a lot more information about what is happening.

The name "allocation plans" includes allocating things like GPU contexts, shader compilations, threadpool spinups, etc. Ideally I'd like all resources a Halide generated pipeline uses to be enumerable and controllable. If nothing else, this would give insight into what resources are being used.

My first thoughts on this were to try generating a name for every resource and then to allow using the name in the schedule or as a parameter to runtime calls to control how the resource is allocated and deallocated. E.g. if the compiler knows the resource is scoped at filter call level, one could schedule that name to a slot in a passed in structure. The issue is that generating the names quickly runs into problems of having them be unique enough to not introduce new aliases (overlaps) of things that are used at the same time, but also name all the uses that are actually shared. (Consider an intermediate allocation used in a loop. It is one name if the loop is serial and one per thread if it is parallel. It gets more interesting from there...)